关于java:Java线程安全JVM角度解析

文章已同步至 GitHub 开源我的项目: JVM 底层原理解析

线程平安

​ 当多个线程同时拜访一个对象，如果不必思考这些线程在运行环境下的调度和交替执行，也不须要思考额定的同步，或者在调用办法时进行一些其余的合作，调用这个对象的行为都能够取得正确的后果。那么就称这个对象是线程平安的。

​ 这个定义是谨严并且有可操作性的，他要求线程平安的代码都必须具备一个独特的个性。代码自身封装了所有必要的正确性保障伎俩（如互斥同步等）。令调用者无需关怀多线程下的调用问题。更无需本人实现任何措施来保障平安。

Java 中的线程平安

​ 在 Java 语言中，从 JVM 底层来看的话，线程平安并不是一个非黑即白的二元排他选项，依照 平安水平 来划分，咱们能够将 Java 中各种操作共享的数据分为五类: 不可变 、 相对线程平安 、 绝对线程平安 、 线程兼容 、 线程对抗

​ 接下来，咱们一一介绍。

• 不可变

  ​ 在 Java 中，不可变的对象肯定是平安的。比方用 final 润饰的变量。只有一个不可见的对象被创立进去，其内部的可见状态就不会扭转，永远不会看到它在多个线程中处于不统一的状态。在 Java 中，不可变带来的线程平安是最间接的，也是最纯正的。

  ​ 根本数据类型：在定义的时候用 final 润饰即可。

  ​ 援用数据类型：因为目前为止 Java 中还没有提供对应的反对，须要咱们本人封装，将共享数据封装为一个不可变的对象，具体来说，咱们能够把对象中的属性封装为 final 类型。这样在构造方法完结之后，他就是一个不可比变的值。

  ​ 比方 String，Integer,Number,Long,Double 等根本数据类型的包装类，都是将 value 局部润饰为 final。

  ​ String 的源码

  private final char value[];

  Integer 的源码

  private final int value;

  Double 的源码

  private final double value;

• 相对线程平安

  ​ 相对线程平安可能齐全满足线程平安的定义，然而在 Java 中标注本人是线程平安的类，并不一定是相对线程平安的类。

  ​ 比方 Vector 类，家喻户晓，它是一个线程安全类，罕用的办法都被 synchronized 润饰。然而，它并不是相对的线程平安，如果要做到相对线程平安，必须在外部保护一组一致性的快照拜访。每次对元素进行改变都要产生新的快照。然而付出的工夫和空间老本是微小的。

• 绝对线程平安

  ​ 绝对线程平安就是咱们通常意义上讲的线程平安，他须要保障对这个对象的单次操作是平安的。在 Java 中，大部分的申明为线程平安的类都是这个级别。比方 Vector,HashTable,Collections 中的 synchronizedCollection()办法包装的汇合等。

• 线程兼容

  ​ 线程兼容是指对象自身是非线程平安的，然而能够通过在调用端正确的应用同步伎俩（加锁）来保障在并发下是平安的。Java 中大部分的类都在此级别。比方 ArrayList,HashMap 等。

• 线程对抗

  ​ 线程对抗是指不论调用端如何进行同步加锁，都无奈保障并发下的线程平安。在 Java 中这品种是很少的，咱们要防止应用。比方 System.setIn(),System.setOut()等。

线程平安的实现计划

在 Java 中，实现线程平安，次要有三种计划, 互斥同步 、 非阻塞同步 、 无同步计划

互斥同步（乐观锁）

synchronized 的实现

​ 此关键字通过 javac 编译之后，会生成两条字节码指令.monitorenter和monitorexit。

比方以下代码

public synchronized void dosomething(){synchronized (SynchronizedTest.class){System.out.println("do something");
        }
    }

​ 反编译之后

0 ldc #2 <cn/shaoxiongdu/chapter6/SynchronizedTest>
 2 dup
 3 astore_1
 4 monitorenter
 5 aload_1
 6 monitorexit
 7 goto 15 (+8)
10 astore_2
11 aload_1
12 monitorexit
13 aload_2
14 athrow
15 return

​ 能够看到，在偏移址为 4 的中央，有一条字节码指令 monitorenter, 示意synchronized 开始的中央，也就是示意开启同步的地位，在偏移址为 12 的中央，有一条 monitorexit 示意同步完结的中央。

​ 这两个指令都须要一个援用类型的参数来指明须要锁住的对象。如果代码中指定了，则应用指定的对象锁，如果呈现在办法申明地位，那么虚构机会判断，如果是实例办法则锁实例对象，如果是静态方法则锁类对象。

​ 在执行 monitorenter 时，首先虚构机会尝试获取对象锁

• 如果获取到对象锁，或者以后线程曾经有了此对象锁

  • 则将对象锁中对象头地位的锁计数器 +1，
  • 在执行到 monitorexit 时，会将其 -1。一旦以后锁对象的锁计数器为 0，则以后线程就会开释对象的对象锁。
• 如果获取不到，则以后线程进入阻塞状态。直到对象锁的值变为 0。也就是持有对象锁的线程开释该锁。

特色：

• 可重入的，同一条线程进入同步块屡次也不会被锁死。
• 在同步块中执行的线程会无条件的阻塞其余线程的进入。这意味着无奈像解决数据库那样强制让已获取锁的线程开释锁，也无奈让正在的期待锁的过程退出。

从执行的老本来看，synchronized是一个重量级的操作。支流的 Java 虚拟机实现中，Java 的线程是映射到操作系统的内核线程中的，如果要唤醒或者阻塞一个线程，须要从用户态切换到内核态。这种转化是很耗时的。所以 synchronized 是一个重量级的操作。在有必要的状况下，再去应用其。

lock 的实现

​ 在 JDK1.5 之后，Java 类库中新提供了 java.util.concurrent 包，其中的 locks.Lock 接口便成为 Java 另外一种互斥同步的伎俩。

​ 该接口的定义如下

public interface Lock {

    // 获取锁。如果锁已被其余线程获取，则进行期待。void lock();

    // 如果线程正在期待获取锁，则这个线程可能响应中断，即中断线程的期待状态。void lockInterruptibly() throws InterruptedException;

    // 尝试获取锁，如果获取胜利，则返回 true 否则返回 false 立刻返回 不会和 lock 一样期待
    boolean tryLock();

    // 拿不到锁时会期待肯定的工夫，在工夫期限之内如果还拿不到锁，就返回 false。boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

    void unlock();

    Condition newCondition();}

​ 应用 Lock 接口的实现类，用户能够以 非块构造 来实现互斥同步，从而解脱了语言的解放，改为在类库层面去实现同步，这也为日后扩大出不同的调度算法，不同的个性，不同性能的各种锁提供了空间。

​ 重入锁（ReentrantLock）是 Lock 接口中最常见的一种实现形式。故名思意，他和 synchronized 一样是能够重入的。写法如下

public static void main(String[] args) {Lock lock = new ReentrantLock();
        
        lock.lock();
        try{// 解决工作}catch(Exception ex){ }finally{lock.unlock();  // 开释锁 不在 finally 处开释可能会产生死锁 
        }
    }

相比 synchronized，ReentrantLock 减少了如下的性能。

• 期待可中断

  ​ 当持有锁的线程长期不开释锁的时候，正在期待的线程能够抉择放弃期待。对于解决执行工夫比拟长的同步块很有帮忙

• 偏心锁

  ​ 当多个线程在期待同一个锁的时候，必须依照申请锁的程序来顺次取得锁。syn 是非偏心的，reentrantLock默认也是非偏心的，须要在构造函数中传入 true 指定应用偏心锁。（应用偏心锁会导致性能急剧下降）

• 锁绑定多个条件

  ​ 一个 ReentrantLock 对象能够同时绑定多个 Condition 对象。只须要屡次调用 newCondition 办法即可。

这种互斥同步的放计划次要问题是在线程阻塞和唤醒的时候会带来性能开销问题。从解决问题的形式上看，互斥同步（阻塞同步）属于一种乐观的并发策略，认为只有是别的线程过去，就肯定会批改数据。无论是否真的会批改，他都会进行加锁（此处探讨的是概念模型，理论虚构机会优化一些不必要的加锁）。这会导致用户态和内核态频繁切换，并且须要保护锁的计数器。比拟繁琐。

非阻塞同步（乐观锁）

​ 基于冲突检测的乐观并发策略。

​ 艰深的说，就是不论危险，先进行操作。如果数据没有被批改，则批改胜利。如果数据被批改，则一直重试。直到呈现没有竞争的共享数据为止。

​ 此种计划须要硬件的倒退，因为进行 检测是否批改 和最终写入 这两个操作必须保障原子性。如果这里用前边的互斥同步来解决，就没有什么意义了，所以须要硬件层面的反对。确保在语义上看起来有多个操作的行为只须要一条处理器指令就能够实现。常见的这种指令有

• 测试并设置 TestAndSet
• 获取并减少 FetchAndIncrement
• 替换 Swap

• 比拟和替换: CompareAndSwap

  在 Java 中实现乐观锁用的是 比拟和替换CAS 指令。

  CAS 指令须要有三个操作数，一个是旧的预期值 A，一个是内存地位 V，还有一个新值 B。

  ​ 当旧的预期值与内存中真正的值雷同的时候，就将旧值替换为新值。否则就不更新。

  在 JDK1.5 之后，Java 类库中才开始应用 CAS 操作，该操作由 sun.misc.Unsafe类中的办法包装提供。虚构机会对这些办法进行非凡解决，保障编译之后是一条平台相干的处理器 CAS 指令。

  比方 AtomicInteger 就是包装了 CAS 指令之后的线程安全类，他的办法都设置在一个死循环中，一直尝试将一个新值赋给内存地位的值，如果失败，阐明被其余线程改了，于是再次循环进行下一次操作，直到批改胜利地位。

  只管 CAS 看起来很美妙，然而它存在一个逻辑破绽，当别的线程将值从 A 改为 B，而后又改回 A 的时候，以后线程是不会发现的。这个破绽叫做 CAS 的ABA 问题，JUC 为了解决这个问题，提供了一个带有标记的原子援用类AtomicStampedReference。它通过管制变量值的版本来解决。

文章已同步至 GitHub 开源我的项目: JVM 底层原理解析