Jvm笔记总结(十六)：线程安全与锁优化

Jvm笔记总结(十六)：线程安全与锁优化

PS : 本文乃学习整理参考而来 ，目录参考 [ Jvm系列目录 ]

---

线程安全：当多个线程访问一个对象时，如果不用考虑这个线程在运行时环境下的调度和交替执行，也不需要进行额外同步，而调用这个对象的行为都可以获得正确的结果，那这个对象就线程安全的。所以线程安全是建立在对共享数据的安全操作保证，如果数据不存在共享，那数据（代码）天生就是安全的。

线程安全的实现方法：

1.互斥同步（阻塞同步）
2.非阻塞同步
3.无同步方案

1.互斥同步（阻塞同步）：同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个线程使用。在Java中，最基本的互斥同步手段就是synchronized关键字，经编译后会在同步块前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果没有指定，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。

由于Java线程是映射到操作系统的原生系统之上的，如果要阻塞和唤醒一个线程，都需要操作系统来帮忙，这就需要从用户态转换到核心态，因此状态转换需要花费很多处理器时间。对于简单的同步块，状态转换消耗时间有可能比用户代码执行的时间更长。所以synchronized是Java语言中一个重量级的操作。

---

2.非阻塞同步：互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能损耗，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施，那就肯定出现问题，而不论共享的数据是否真的会出现竞争，都要进行加锁、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤起等操作。随着发展，出现了一种：基于冲突检测的乐观并发策略，通俗的说就是先进行操作，如果没有其他线程争用共享数据，那就直接操作。如果共享数据有争用产生了冲突，那就再采取其他补偿措施，这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步。

---

3.无同步方案：同步只是保证数据争用时的正确性手段，如果一个方法本来就不涉及共享数据，那他自然就无需任何同步措施去保证正确性，因此一些代码天生就是线程安全的。如：可重入代码（Reentrant Code）

可重入代码（Reentrant Code）：也叫做纯代码（Pure Code），可以在代码执行的任何时刻中断他，转而去执行另外一段代码，而在控制权返回后，原来的程序不会出现任何错误。可重入代码有一些共同的特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都是由参数中传入、不调用非可重入的方法。可通过一个简单的原则来判断代码的可重入行：如果一个方法，他的返回是可预测的，只要输入了相同的数据，就能返回相同的结果，那就满足可重入性的要求，当然就是线程安全的。

---

锁优化

高效并发从JDK1.5到JDK1.6的一个重要改进，都是为了在线程之间更高效的共享数据，解决竞争问题，提高程序执行效率。其中主要包括：

1.自旋锁与自适应自旋（Adaptive Spinning）
2.锁消除（Lock Elimination）
3.锁粗化（Lock Coarsenig）
4.轻量级锁（Lightweight Locking）
5.偏向锁（Biased Locking）

1.自旋锁与自适应自旋（Adaptive Spinning）

        由于互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成（用户态与内核态的切换），这些操作给系统的并发性能带来了很大的压力。同时在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的线程“稍等一下”，但不放弃处理器执行时间，看看持有锁的线程是否很快会释放锁。为了让线程“稍等”，只需让线程执行一个忙循环（自旋），这就是自旋锁，自旋次数默认是10次。在JDK1.6中引入的自适应自旋，意味着自旋的时间不再固定，而是由前一次在同一个锁上自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就认为这次自旋也很有可能再次成功，而运行自旋等待持续相对更长的时间，比如100个循环。而如果对于某个锁，自旋很少成功获得，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对锁的状况预测就越来越准确，虚拟机就变得越聪明。

---

2.锁消除（Lock Elimination）

        锁消除是指虚拟机即时编译器在运行中进行代码优化时，对一些代码上要求同步，但被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判断依据来源于逃逸分析的数据支持。也许会有疑问，数据是否存在争用，程序员自己应该是很清楚的，怎么会对不存在竞争的情况下要求同步。答案是有许多同步措施并不是程序员加入的。而同步代码在Java程序中的普及程度超过了大部分人的想象。
如下代码：

public  String concatString(String a,String b,String c){

        return a + b + c;
}

如上代码经过编译后：

 public  String concatString(String a,String b,String c){

        StringBuffer stringBuffer = new StringBuffer();
        stringBuffer.append(a);
        stringBuffer.append(b);
        stringBuffer.append(c);
        return stringBuffer.toString();

   }

由于Javac编译器会对String连接做自动优化（String是一个被final修饰的不变类），1.5版本以前使用StringBuffer的append()，而StringBuffer.append()的每个重载都有加入了synchronized。1.5以后会使用StringBuilder对象的连续append()操作进行优化（由于线程内的连接多数是线程安全的，若考虑线程不安全时还是使用StringBuffer）。而代码中锁对象的作用域被限制在concatString方法内部，也就是不可能逃逸到concatString之外，所有虽然这里有锁，但可以被安全消除。

---

3.锁粗化（Lock Coarsenig）

        如果一系列操作都对同一个对象反复加锁和解锁，如上代码中连续的append方法就属于这个类情况，如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步范围扩展（粗化）到整个操作序列外，上代码中就扩展到第一个append之前直至最后一个append操作之后，只需一次加锁就可以了。

---

4.轻量级锁（Lightweight Locking）

        轻量级锁是相对于传统互斥锁机制实现的“重量级”锁而言。首先强调的是轻量级锁并不是用来代替重量级锁的，他的本意是在没有多线程竞争的前提下，减少使用传统的重量级锁带来的性能损耗（用户态、内核态切换）。要理解轻量级锁以及偏向锁，则必须从HotSpot虚拟机的对象（对象头）的内存布局开始。HotSpot虚拟机的对象头分为两部分信息，第一部分用于存储对象自身运行时数据，如哈希码（HashCode）、GC分代年龄（GC Age）等，这部分数据的长度在32位和64位的虚拟机中分别为32bit和64bit，官方称为“Mark Word”。另外一部分用于存储指向方法区对象类型数据的指针。在32位的虚拟机中25bit用于存储对象哈希码，4bit存储对象分代年龄，2bit存储锁标志位，其他略。
如图锁标志与对应信息：

存储内容	标志位	状态
对象哈希码、对象分代年龄	01	未锁定
指向轻量级锁记录的指针	00	轻量级锁定
指向重量级锁记录的指针	10	重量级锁
空、不需要记录信息	11	GC标记
偏向ID、偏向时间戳、对象分代年龄	01	可偏向

如果代码进入同步块，如果同步对象没有被锁定（标志位为“01”），那么线程拥有了该对象的锁，并且锁标志将转变为“00”，表示对象处于轻量级锁。而如果有其他线程争用同一锁，那轻量级锁就不在有效，而要膨胀为重量级锁，锁标志变为“10”，后面等待锁的线程也要进入阻塞状态。轻量级锁能提升程序同步性能的依据是“绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免使用重量级锁的开销，但是如果存在锁竞争，除了互斥量的开销，还额外发生了CAS操作，因此在有竞争力的情况下，轻量级锁会比传统的重量级锁更慢。

---

5.偏向锁（Biased Locking）

        可以理解为轻量级锁的一种更激进的优化。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。如果虚拟机启用了偏向锁，当还有另外一个线程尝试获取已加上偏向锁的对象时，偏向模式就宣告结束。转而将锁定标志位转为轻量级锁或其他状态。

---