线程安全性

1 线程安全性

当多个线程访问某个类时,不管运行时环境采用何种调度方式或者这些进程将如何交替执行,并且在主调代码中不需要额外的同步和协同,这个类都能表现出正确的行为
线程安全性主要体现在以下三个方面:

  • 原子性:提供了互斥访问,同一时刻只能有一个线程来对它进行操作。
  • 可见性:一个线程对主内存的修改可以及时的被其它线程观察到。
  • 有序性:一个线程观察其他线程中的指令执行顺序,由于指令重排序的存在,该观察结果一般杂乱无序。
1.1 原子性

由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write,我们大致可以认为基本数据类型的访问读写是具备原子性的(例外就是long和double的非原子协定,读者只要知道这件事就可以了,无须太过于在意这些几乎不会发生的例外情况)。
如果应用场景需要一个更大范围的原子性保证,Java内存模型还提供了lock和unlock操作来满足这种需求,尽管虚拟机未把lock和unlcok操作直接开放给用户使用,但是却提供了更高层次的字节码指令monitorentermonitorexit来隐式使用这两个操作。这两个字节码指令反映到Java代码中就是同步块 - synchronized。

1.1.1 Atomic原子性实现

Atomic的包名为java.util.concurrent.atomic。这个包里面提供了一组原子变量的操作类,这些类可以保证在多线程环境下,当某个线程在执行atomic的方法时,不会被其他线程打断,而别的线程就像自旋锁一样,一直等到该方法执行完成,才由JVM从等待队列中选择一个线程执行。


Atomic家族成员.png

Atomic包的实现主要基于CAS(Compare And Set)操作,我们开篇提供了一个计数器的功能,发现每次执行结果没有达到预期,在之前版本做稍许改动

@Slf4j
@ThreadSafe
public class AtomicExample1 {
    // 请求总数
    public static int clientTotal = 5000;
    // 同时并发执行的线程数
    public static int threadTotal = 200;
    public static AtomicInteger count = new AtomicInteger(0);
    public static void main(String[] args) throws Exception {
        ExecutorService executorService = Executors.newCachedThreadPool();
        final Semaphore semaphore = new Semaphore(threadTotal);
        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
        for (int i = 0; i < clientTotal ; i++) {
            executorService.execute(() -> {
                try {
                    semaphore.acquire();
                    add();
                    semaphore.release();
                } catch (Exception e) {
                    log.error("exception", e);
                }
                countDownLatch.countDown();
            });
        }
        countDownLatch.await();
        executorService.shutdown();
        log.info("count:{}", count.get());
    }
    private static void add() {
        count.incrementAndGet();
        // count.getAndIncrement();
    }
}
//每次能达到预期效果

我们一起看看AtomicInteger的incrementAndGet的内部实现,其余几个方法的原理跟这个相同,在此不再过多的解释

    /**
     * 当前值自增1
     */
    public final int incrementAndGet() {
        //Unsafe是JDK内部用的工具类。它通过暴露一些Java意义上说“不安全”的功能给Java层代码
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }

    /**
     * AtomicInteger 中的CAS操作就是compareAndSet(),其作用是每次从内存中  
     *根据内存偏移量(valueOffset)取出数据,将取出的值跟expect 比较,如果数据一致就把内存中的值改为update。这样使用CAS就保证了原子操作
     * @param expect the expected value
     * @param update the new value
     * @return {@code true} if successful. False return indicates that
     * the actual value was not equal to the expected value.
     */
    public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }
  

关于Atomic我们说最后一点,CAS的ABA问题,如count=1,A线程在获取值的时候,count值可能被其它线程改变但最终改回成了1。导致与实现思想有偏差,为了解决这个请参考AtomicStampedReference的实现,修改对应一个版本号

    public boolean compareAndSet(V   expectedReference,
                                 V   newReference,
                                 int expectedStamp,
                                 int newStamp) {
        Pair<V> current = pair;
        return
            //在之前CAS操作的基础上添加了版本号的比较
            expectedReference == current.reference &&
            expectedStamp == current.stamp &&
            ((newReference == current.reference &&
              newStamp == current.stamp) ||
             casPair(current, Pair.of(newReference, newStamp)));
    }
1.1.2 Synchronized原子性实现
  • 修饰代码块:大括号括起来的代码,作用于调用对象。
  • 修饰方法:整个方法,作用于调用对象。
  • 修饰静态方法:整个静态方法,作用于所有对象。
  • 修饰类:括号括起来的部分,作用于所有对象。
//修饰代码块
 synchronized (this) { ... }
//修饰方法
public synchronized void test(int j) { ... }
//修饰静态方法
 public static synchronized void test2(int j){ ... }
//修饰类
synchronized (SynchronizedExample2.class) { ... }

1.1.3 原子性-对比

-Synchronized:不可中断锁,适合竞争不激烈,可读性好。
-Lock:可中断锁,多样化同步,竞争激烈时能维持常态。
-Atomic:竞争激烈时能维持常态,比Lock性能好;只能同步一个值。

1.2 可见性

Java内存模型中,允许编译器和处理器指令进行重排序,重排序并不会影响到单线程的执行,却会影响到多线程的执行。
可见性是指当一个线程修改了共享变量的值,其它线程能够立即得知这个修改。从前面https://www.jianshu.com/p/9005b30c0fe2章节我们了解到Java内存模型是通过在变量修改后将新值同步回主存,在变量读取前从主内存刷新变量值这种依赖主存作为传递媒介的方式来实现可见性的。
导致共享变量在线程间不可见的原因:

  • 线程交叉执行
  • 重排序结合线程交叉执行
  • 共享变量更新后的值没有在工作内存与主内存及时更新
1.2.1 Synchronized可见性实现

JMM关于synchronized的两条规定

  • 线程解锁前,必须把共享变量的最新值刷新到主内存。
  • 线程加锁时,将清空工作内存共享变量的值,从而使用共享变量时需要从主内存重新读取共享变量的值(加锁和解锁必须为同一把锁)
1.2.2 Volatile可见性实现

通过内存屏障禁止重排序优化来实现。

  • 对Volatile变量写操作时,会在写操作后加入一条store屏障指令,将本地内存中共享变量值刷新到主内存。
  • 对Volatile变量读操作时,会在读操作前加入一条load指令,从主内存读取共享变量的值。


    Volatile写.png
Volatile读.png

关于Volatile变量的可见性,经常会被开发人员误解,认为以下描述成立:"volatile变量对所有线程是立即可见的,对volatile变量所有的写操作都能立刻反应到其它线程中,换句话说,volatile变量在各个线程中是一致的,所以基于volatile变量的运算在并发下是安全的",这句话的论据没有错,但是论据并不能得出"基于volatile变量的运算在并发下是安全的",因为Java里面的运算并非原子操作,导致volatile变量的运算在并发下一样不安全,我们还是通过计数器的例子来说明原因。

@Slf4j
@NotThreadSafe
public class CountExample4 {
    // 请求总数
    public static int clientTotal = 5000;
    // 同时并发执行的线程数
    public static int threadTotal = 200;
    public static volatile int count = 0;
    public static void main(String[] args) throws Exception {
        ExecutorService executorService = Executors.newCachedThreadPool();
        final Semaphore semaphore = new Semaphore(threadTotal);
        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
        for (int i = 0; i < clientTotal ; i++) {
            executorService.execute(() -> {
                try {
                    semaphore.acquire();
                    add();
                    semaphore.release();
                } catch (Exception e) {
                    log.error("exception", e);
                }
                countDownLatch.countDown();
            });
        }
        countDownLatch.await();
        executorService.shutdown();
        log.info("count:{}", count);
    }
    private static void add() {
        count++;
        //可能在往主存回写的时候出现问题
        // 1、count
        // 2、+1
        // 3、count  
    }
}
1.3 有序性

如果在本线程内观察,所有的操作都是有序的;如果一个线程中观察另外一个线程,所有操作都是无序的。前半句是指"线程内表现为串行的语义",后半句是指"指令重排序"现象和"工作内存与主内存同步延迟"现象。

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性,volatile关键字本身就包含了禁止指令重排序的语义,而synchronized则是由"一个变量在同一时刻只允许一条线程对其进行lock操作"这条规则获得。

1.3.1 Happens-before原则

如果Java内存模型中所有的有序性都仅仅靠volatile和synchronized来完成,那么有一些操作将会变得很繁琐,但是我们在编写并发代码时并没有感觉到这一点,这是因为Java语言有一个"先行发生"(happens-before)的原则

//以下操作在线程A执行
i = 1;

//以下操作在线程B执行
j = i;

//以下操作在线程C执行
i = 2;

//假设线程A中的操作先行发生于线程B的操作,那么可以确定在线程B操作执行后,变量j的值一定等于1,得出结论依据有两个:一是根据先行发生原则,i=1的结果可以被观察到; 二是线程C还没有登场;假设A还是先行于B,但是线程C出现在A、B之间,但是线程C与B没有先行发生的关系,此时j的值就可能变得不确定了,1和2都有可能

下面是Java内存模型下一些"天然的"先行发生关系,这些先行发生关系无须任何同步器协助就存在。

  • 程序次序规则:在一个线程内,按照程序代码顺序,书写在前面的操作先行发生于书写在后面的操作。准确地说,应该是控制流顺序而不是代码顺序,因为要考虑分支、循环等结构。
  • 管程锁定规则:一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调是同一个锁,而"后面"是指时间上的先后顺序。
  • volatile变量规则:对一个volatile变量的写操作先行发生于后面对这个变量的读操作,这里的"后面"同样是值时间上的先后顺序。
  • 线程启动规则:Thread对象的start()方法先行发生于此线程的每一个动作。
  • 线程终止规则:线程中的所有操作都先行发生于对此线程的终止监测,我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
    -线程中断规则: 对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断时间的发生,可以通过Thread.interrupted()方法检测到是否有中断发生。
  • 对象终结规则::一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
    -传递性:如果操作A先行发生于操作B,操作B先行发生于操作C,那就可以得出操作A先行发生于操作C的结论。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容