jvm笔记07：线程安全与锁优化

 java语言中的线程安全

        按照线程安全的”安全程度”由强至弱来排序，我们可以将java语言中各种操作共享的数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立

不可变

         不可变的的对象一定是线程安全的。无论是对象的方法实现还是方法的调用者，都不需要再采用任何的线程安全保障措施 。java语言中，如果共享数据是一个基本数据类型那么只要在定义时候使用final关键字修饰它就可以保证它是不可变的。如果共享数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响，保证对象行为不影响自己状态的途径有很多种，其中最简单的就是把对象中带有状态的变量都声明为final，这样的话，在构造函数结束之后，他就是不可变的。

绝对线程安全

         在Java API 中标注自己是线程安全的类，大多数都不是绝对的线程安全。例如Vector，虽然他的add，get，size都被synchronized修饰了，但是不代表调用它的时候永远都不需要同步手段了。最简单的例子就是，新建一个拥有20个元素的Vector，开一个线程去移除Vector，开一个线程去打印Vector，会发现数组越界的错误消息。

相对线程安全

         线程的相对安全就是我们平常所说的线程安全。他需要保证这个对象单独的操作时线程安全的，我们在调用的时候不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用的端使用额外的同步手段来保证调用的正确性。

       在java语言中，大部分的线程安全类都是属于这种类型，例如Vector，HashTable Collections的synchronizedCollection（）方法包装的集合等。

线程兼容

          线程兼容是指对象本身不是线程安全的，但是可以通过在调用端正确的使用同步手段来保证对象在并发的环境中可以安全的使用。如ArrayList和HashMap

线程对立

         线程对立是指无论调用端是否采用了同步的措施，都无法在多线程环境中并发使用的代码。例如Thread的 suspend和resume方法。

线程安全实现方法

互斥同步

      互斥同步（Mutual Exception & Synchronized） 是常见的一种并发正确性保障手段。

       在java中最基本的互斥同步手段就是synchronized 关键字，synchronized 关键字经过编译之后，会在同步块的前后分别形成monitorenter 和monitorexit这两个字节码指令，这两个字节码都需要一个reference 类型的参数来指明要锁定和解锁的对象。如果java程序中的synchronized明确制定了对象参数，那就是这个对象的reference；如果没有明确指定，那就根据synchronized修饰的是实例还是类方法，去取对应的对象实例或者Class对象来作为锁的对象。

       在虚拟机规范对monitorenter 和monitorexit的行为描述中，有两点是需要特别注意的。首先synchronized同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题。其次，同步块在已经进入线程执行完之前，会阻塞后面其他线程的进入。如果要阻塞一个线程或者唤醒一个线程都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间。对于简单的代码块，状态转换消耗的时间可能比用户代码的执行时间还要长。所以synchronized是Java语言中一个重量级的操作。不过虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待，避免频繁的切入到核心态之中。

        除了synchronized之外，我们还可以使用java.util.concurrent 包中的重入锁（ReentrantLock）来实现同步，相对synchronized来说，ReentrantLock增加了一些高级功能，主要有以下三项： 等待可中断、可实现公平锁、锁可以绑定多个条件。

1）等待中断是指 当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。

2）公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁不能保证这一点，在锁释放时，任何一个等待锁的线程都有机会获得锁。synchronized是非公平锁，ReentrantLock默认情况下也是非公平的，但是可以通过带布尔值的构造函数要求使用公平锁。

3）锁绑定多个条件是指一个ReentrantLock对象可以同时绑定多个Condition对象，而在synchronized中，锁对象的wait（）和notify（）或notifyAll（）方法可以实现一个隐含条件，如果要和多于一个条件关联的时候，就不得不额外的添加一个锁，而ReentrantLock无需这样做，只需要多次调用newCondition（）方法即可。

       后续的JDK1.6发布之后人们发现synchronized和ReentrantLock的性能基本持平，由于synchronized 是原生的，所以在能实现需求的情况下，还是提倡使用synchronized。

 

非阻塞同步        

       互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也成为阻塞同步。所以处理问题的方式上说，互斥同步属于悲观锁的并发策略，总是认为不去做正确的同步措施，那就肯定会出错，无论共享数据还是真的会出现竞争，它都要进行加锁。

      随着硬件指令集的发展，基于冲突检测的乐观锁并发策略出现了，通俗的说，就是先进行操作，如果没有其他线程竞争用共享数据，那操作就成功了；如果共享数据有竞争，产生了冲突，那就在采取 其他的补偿措施（最常见的补偿措施就是不断尝试，知道成功为止），这种乐观锁的并发策略的许多实现都不需要把线程挂起，因此这种操作同步称作非阻塞同步。

      乐观锁，是基于CAS原理实现的，但是CAS也有逻辑缺陷，就是会有可能引发"ABA" 问题，不过大部分情况下，ABA问题不会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能回避原子类更高效。

无同步方案

       线程安全不一定需要进行同步，两者没有因果关系，同步只是保证数据争用时候的正确性。如果一个方法本来就不涉及共享数据，那他自然就无须任何同步操作，因此会有一些代码天生就是线程安全的.

可重入代码（Reentant Code）：可重入代码有一些共性，例如不依赖存储在堆上的数据，和共用的系统资源，用到的状态量都是参数传入、不掉用非可重入的方法等。如果一个方法，只要输入了相同的参数，就能返回相同的结果，那他就满足可重入性的要求，也就是线程安全的。

线程本地存储(Thread Local Storage)：如果一段代码所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程执行？如果能保证，我们就可把共享数据的可见范围限制在同一个线程之内，这样，无需同步也能保证线程之间不出现数据争用的问题。

         java语言中如果一个变量要被多个线程访问，可以使用volatile关键字声明它为“易变得”；如果一个变量要被某个线程独享，可以通过ThreadLocal 类来实现线程本地存储的功能。每一个线程对象中都有一个ThreadLocalMap对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode为键，以本地线程变量为值得K-V值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashMap值，使用这个值就可以在线程K-V 值对中找回对应的本地线程变量。

锁优化

自旋锁与自适应自旋

          由于同步互斥中国，对性能影响最大的是阻塞的实现，挂起线程金和恢复线程的操作都需要转入内核态完成，这些操作给系统的并发性能带来压力，同时虚拟机开发团队注意到共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得，如果物理机器有两个以上的处理器，能让两个或者两个以上的线程同时执行，我们就可以让后面请求锁的那个线程 “稍等一下”但不放弃处理器执行时间，看看锁是否很快释放。为了让线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

         自旋如果超过限定次数还没有获得锁的话，那么就会挂起，限定次数可以通过-XX:PreBlockSpin 来修改，默认是10。 

        JDK1.6以后默认开启自旋锁，而且引入了自适应自旋锁。自适应意味着自旋的时间不在固定，而是由前一次在同一个锁上的自旋时间以及所的拥有者状态来决定。如果上一次自旋获取锁成功过，那么虚拟机会认为这次自旋也很有可能成功，进而允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功，那么以后获取锁的时候会省略掉自旋的过程，避免浪费CPU资源（自旋是需要浪费CPU资源的）。

锁消除

       锁消除，是指虚拟机即时编译在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。

锁粗化

       原则上，我们再编写代码的时候，总是推荐将同步块的作用范围限制在尽量小，只在共享数据的实际作用域才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。

      大部分情况下，上面的原则是正确的，但是如果一些列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作时出现在循环体重的，那即使没有线程竞争，频繁的进行互斥同步操作也会导致不必要的性能消耗。所以这个时候可以把锁粗化，将锁提到循环的外面。

轻量级锁

        轻量级锁是JDK1.6中加入的新型锁机制，他们名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就称为“重量级”锁。需要强调一点的就是轻量级锁不是来替代重量级锁的，他的本意是在没有多线程的竞争条件下，减少传统的重量级锁 使用 以减少操作系统互斥量产生的性能消耗。

       轻量级锁提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据，如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但是如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争下，轻量级锁回避传统的重量级锁慢。

偏向锁

      偏向锁也是JDK1.6引入的，它的目的是消除数据在无竞争状态下的同步原语，进一步提高程序运行性能。也就是说轻量级锁是在无竞争条件下使用CAS操作去消除同步使用的互斥量，那么偏向锁就是在无竞争情况下把整个同步都消除掉，连CAS操作都不做了。

    偏向锁可以提高带有同步但无竞争的程序性能。