深入理解JVM——线程安全与锁优化

线程安全

当多个线程访问一个对象时，如果不考虑这些线程在执行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那么这个对象是线程安全的。

Java语言中的线程安全

线程安全是基于多线程共享数据来说的，没有与其他线程的共享数据，从线程安全来看，程序是串行执行还是多线程执行完全没有区别。
按照线程安全的“安全程度”由强到弱将各种操作的共享数据可以分为以下五类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

不可变

1) 在Java语言中不可变的对象一定是线程安全的，无论是对象的方法实现还是方的调用者，都不需要再采用任何的线程安全保障措施。如final关键字，只要一个不可变对象被正确构建出来（没有发生this引用逃逸，即对象还未构造完成this引用就被发布出去了），那其外部的可见状态永远不会发生改变，永远不会看到它在多个线程之中处于不一致的状态。

共享数据是基本数据类型，final修饰就可以保证其是不可变的。而对于对象来说，需要保证对象的行为不会对其状态产生影响（最简单的就是将对象中带有状态的变量都声明为final，在构造函数结束之后，它就是不可变的）。例如，对于java.lang.String类的对象，是一个典型的不可变对象，我们调用它的subString(),replace(）,concat()等方法都不会影响其原来的值，只是会返回一个新构造的字符串对象。除此之外还有枚举类型，以及java.lang.Number的部分子类，如Double和Long等数值包装类。

绝对线程安全

不管运行时环境如何，调用者都不需要任何额外的同步措施。
如java.util.Vector是一个线程安全的容器，它的get,add,size等方法都是被synchronized修饰的，效率很低 ，但确实是安全的。但并不意味着调用时永远不需要同步手段，如多线程中一个线程在错误的时间里对元素进行了删除，就会导致边界异常。此时对删除需要进入同步块处理。

相对线程安全

即我们通常所讲的线程安全，需要保证对这个对象单独的操作是线程安全的，调用时不需要做额外的保障措施，但对一些特定的顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。
Java中大部分都属于这类，如Vector,HashTable，Collections的synchronizedCollection()方法包装的集合等。

线程兼容

是指对象本身不是线程安全的，但是通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全的使用。平常所说非线程安全，说的就是这一类，如ArrayList,HashMap等。

线程对立

是指无论被调用端是否采取了同步措施，都无法在多线程环境中并发使用代码，由于Java语言天生具有多线程特性，线程对立这种排斥多线程的代码很少出现，且通常都是有危害的，应该尽量避免。
例如：Thread的suspend()和resume()方法，如果两线程同时持有一个线程对象，一个尝试中断，另一个尝试恢复，如果并发就，无论调用时是否进行了同步，目标线程都存在死锁的风险。如果suspend中断的线程就是要执行resume的那个，就肯定要产生死锁。因此jdk已声明废弃了suspend和resume。常见的还有System.setIn(),System.setOut(),System.runFinalizersOnExit()等。

线程安全的实现方法

互斥同步

互斥同步是常见的一种并发正确性保障手段。同步是指在多线程并发访问共享数据时，保证共享数据在同一时刻只能被一个线程使用。而互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现方式。互斥是因，同步是果；互斥是方法，同步是目的。
在Java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字经过编译后，会在同步代码块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果明确了对象参数，那就是该对象的引用；否则则根据synchronized所修饰的是实例方法还是类方法去取对应的对象实例或class对象作为锁对象。monitorenter将会尝试获取对象的锁，锁对象未被锁定或当前线程已拥有了锁，锁计数器就会加1，exit时减1，为0时则释放锁。

！！！synchronized同步块对同一线程来说是可重入的，不会出现自己把自己锁死的问题。同步代码块在已进入的线程执行完之前，会阻塞后面其他线程的进入。由于Java线程时映射到操作系统的原生线程上的，如果要阻塞或唤醒一个线程，都需要操作系统来帮忙，就需要从用户态转为核心态，状态转换需要耗费处理器的时间可能比用户代码执行时间还长，所以synchronized是一个重量级的操作。

除了synchronized之外，还可以使用java.uitl.concurrent包中的重入锁（ReentrantLock）来实现同步。ReentrantLock表现为API层面的互斥锁（lock和unlock方法配合try/finally语句块来完成），synchronized表现为原生语法层面的互斥锁。
相比synchronized，ReentrantLock增加了一些高级功能：等待可中断。可实现公平锁，以及锁可以绑定多个条件。

等待可中断：是指持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助。
公平锁：是指多个线程在等待一个锁时，必须按照申请锁的时间顺序来依次获得锁；非公平锁则不能保证这一点，在锁被释放时任何一个等待锁的线程都有机会获得锁。synchronized是非公平的，reetrantlock在默认情况下也是非公平的，可以通过带布尔值的构造函数要求使用公平锁。
锁绑定多个条件：一个ReetrantLock对象可以同时绑定多个Condition对象，而在synchronized中，锁对象的wait和notify或notifyall可以实现一个隐含条件，如果要和多于一个的条件相关联时，就不得不额外加一个锁，而ReetrantLock不用这样，只需多次调用newCondition()方法即可。
JDK1.5多线程环境下，synchronized吞吐量下降非常严重，而ReetrantLock基本保持在同一个比较稳定的水平上。JDK1.6关于性能上synchronized与ReetrantLock持平，虚拟机又更偏向于原生的synchronized，所以还是尽量使用synchronized。

非阻塞同步

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步，属于一种悲观的并发策略，即只要不去做正确的同步措施，就肯定会出问题，无论是否会出现竞争，都要进行加锁、用户态核心态的转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。
非阻塞同步：基于冲突检测的乐观并发策略，也就是说，先进行操作，如果没有其他线程争用共享数据，按操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断的重试，直到成功为止），这种乐观的并发策略的许多实现都是不需要把线程挂起的。
乐观并发策略需要“硬件指令集的发展”才能进行。因为需要操作和冲突检测这两个步骤具备原子性，只能靠硬件来保证，硬件保证一个从语义上看来需要多次操作的行为只通过一条处理器指令就能完成，指令有：
—>测试并设置
—> 获取并增加
—> 交换
—> 比较并交换（CAS）
—> 加载链接/条件存储LL/SC
CAS需要3个操作数，分别是内存位置V，旧的预期值A和新值B。CAS执行时，当且仅当V符合A时，处理器用B更新V，否则就不执行更新，但无论是否更新了V，都会返回V。这个处理过程就是一个原子操作。JDK1.5才使用CAS操作。但这种操作无法涵盖互斥同步的所有使用场景，且CAS从语义上来说并不是完美的，漏洞在于：如果一个V初次读取的时候是A，且在准备赋值的时候还是A，我们能说它的值没有被其他线程改变过么？如果在这期间曾改为B，又改回A，那CAS就会误认为它从来没有被改变过。这个漏洞就是CAS操作的ABA问题。
解决方法时J.U.C包提供一个带有标记的原子引用类AtomicStanmpedReference，可以通过控制变量值的版本来保证CAS的正确性。但大部分情况下，ABA问题都不会影响程序的并发性，需要解决的话，改用传统的互斥同步可能会比原子类更高效。

无同步方案

要保证线程安全，并不一定就要进行同步，两者没有因果关系。同步仅保证共享数据争用时的正确性的手段。如果不涉及共享数据，就无须同步，本身就是安全的。如以下两者：

可重入代码Reentrant Code

也叫纯代码，可以在代码执行的任何时刻中断它，转而去执行另外一段代码，而在控制权返回后，原来的程序不会出现任何错误。可重入性是更基本的特性，可以保证线程安全，即所有的可重入的代码都是线程安全的。但并非所有的线程安全的代码时可重入的。
可重入代码特征：不依赖存储在堆上的数据和公用的系统资源，用到的状态量都是由参数中传入，不调用非可重入的方法等。如果一个方法的返回结果是可以预测的，只要输入相同的数据，能返回相同的结果，那就满足可重入性的要求，也就是线程安全的。

线程本地存储Thread Local Storage

如一段代码中所需的数据必须与其他代码共享，那就看这些共享数据能否保证在同一个线程中执行？能保证则可以把共享数据的可见范围控制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。如消费队列的架构模式（生产者-消费者模式）都会讲产品的消费过程尽量在一个线程中消费完，其中最重要的一个应用实例就是经典的Web交互模型中的“一个请求对应一个服务器线程”的处理方式，因此很多web服务端应用都可以使用线程本地存储来解决线程安全问题。
（重点！！！）
可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。
每一个线程的Thread对象中都有一个ThreadLocalMap对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode为键，以本地线程变量为值的K-V值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V值对中找回对应的本地线程变量。

锁优化

高效并发，JDK1.5-JDK1.6的一个重要改进。各种锁优化技术都是为了在线程之间更高效地共享数据，以及解决竞争问题，从而提高程序的执行效率。

自旋锁与自适应自旋

互斥同步对性能最大的影响是阻塞的实现，挂起和恢复线程都得需要转入内核态中完成，很不值得。
如果物理器有一个以上的处理器，能让两个或以上线程同时并行执行，就让后面请求锁的那个线程“暂时等待一下”，但不放弃处理器的执行时间，看持有锁的线程是否很快就会释放锁。为了让线程等待，只需要让线程执行一个忙循环（自旋），这项技术就是自旋锁。*JDK1.4.2引入但默认关闭，JDK1.6默认开启。自旋等待不能代替阻塞。短时间效果很好，但长时间会白白消耗处理器资源，而不会做任何有用的工作，反而带来性能上的浪费。因此自旋等待的时间必须有一定的限度，超过限定次数仍没有成功获得锁，就应该使用传统的方式去挂起线程，默认是10次，可通过-XX:PreBloclSpin来修改*。
JDK1.6引入了自适应自旋锁，意味着自旋时间不再固定，由前一次在用一个锁上的自旋时间及锁的拥有者的状态来决定。在同一锁对象上，若刚刚成功获得过锁，且持有锁的线程正在运行，虚拟机就会认为这次自选也很有可能再次成功，进而它将允许自选等待时间相对更长。如果对于某个锁很少获得成功，那以后要获取这个锁就可能省略掉自旋过程，以避免浪费处理器资源。

锁消除

指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持。
若一段代码中，堆上所有数据都不会逃逸出去从而被其他线程访问到，就可以把它们当做栈上数据对待，认为是线程私有的，同步加锁自然无须进行。
例如，字符串连接

//看起来没有同步的一段代码public String concatString(String s1,String s2,String s3){    return s1+s2+s3;}

，javac会对string连接做自动优化，在JDK1.5之前，会转化为stringbuffer对象的连续append操作(该操作都有一个同步块，锁就是sb对象，但它的动态作用域被限制在concatString方法内部，sb不会逃逸到方法外被其他线程访问，因此即时编译之后会忽略掉所有的同步而直接执行)，在JDK1.5及以后，转为stringbuilder对象的连续append操作。

public String concatString(String s1,String s2,String s3){    StringBuffer sb=new StringBuffer();    sb.append(s1);//append操作都有一个同步块，锁就是sb对象    sb.append(s2);    sb.append(s3);    return sb.toString();}

锁粗化

如果虚拟机探测到有一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁的进行互斥同步操作也会导致不必要的性能损耗，如连续的append操作。
锁粗化，如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展到整个操作序列的外部，这样就只需要加锁一次就够了。