Java Synchronized和Lock比较浅析

   <p>synchronized是基于jvm底层实现的数据同步，lock是基于Java编写，主要通过硬件依赖CPU指令实现数据同步。下面一一介绍</p>    <h3>一、 synchronized <strong>的实现方案</strong></h3>    <p>1.synchronized能够把任何一个非null对象当成锁，实现由两种方式：</p>    <p>a.当synchronized作用于非静态方法时，锁住的是当前对象的事例，当synchronized作用于静态方法时，锁住的是class实例，又因为 Class的相关数据存储在永久带，因此静态方法锁相当于类的一个全局锁。</p>    <p>b.当 synchronized作用于一个对象实例时，锁住的是对应的代码块。</p>    <p>2.synchronized锁又称为对象监视器（object）。</p>    <p>3.当多个线程一起访问某个对象监视器的时候，对象监视器会将这些请求存储在不同的容器中。</p>    <p>> Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中</p>    <p>> Entry List： Contention List中那些有资格成为候选资源的线程被移动到 Entry List中</p>    <p>> Wait Set：哪些调用 wait方法被阻塞的线程被放置在这里</p>    <p>> OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为 OnDeck</p>    <p>> Owner：当前已经获取到所资源的线程被称为 Owner</p>    <p>>  !Owner：当前释放锁的线程</p>    <p>下图展示了他们之前的关系</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/537315caf57c60746f0e03abe8254f38.png"></p>    <p>4.synchronized在jdk1.6之后提供了多种优化方案：</p>    <p>>自旋锁</p>    <p>jdk1.6之后默认开启，可以使用参数-XX:+UseSpinning控制，自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，因此，如果锁被占用的时间很短，自旋等待的效果就会非常好，反之，如果锁被占用的时候很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有用的工作，反而会带来性能上的浪费。自旋次数的默认值是 10 次，用户可以使用参数 -XX:PreBlockSpin 来更改。</p>    <p>自旋锁的本质：执行几个空方法，稍微等一等，也许是一段时间的循环，也许是几行空的汇编指令。</p>    <p>>锁消除</p>    <p>即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除，依据来源于逃逸分析的数据支持，那么是什么是逃逸分析？对于虚拟机来说需要使用数据流分析来确定是否消除变量底层框架的同步代码，因为有许多同步的代码不是自己写的。</p>    <p>例1.1</p>    <pre>  public static String concatString(String s1, String s2, String s3) {        return s1 + s2 + s3;    }    </pre>    <p>由于 String 是一个不可变的类，对字符串的连接操作总是通过生成新的 String 对象来进行的，因此 Javac 编译器会对 String 连接做自动优化。在 JDK 1.5 之前，会转化为 StringBuffer 对象的连续 append() 操作，在 JDK 1.5 及以后的版本中，会转化为 StringBuilder 对象的连续 append() 操作，这里的stringBuilder.append是线程不同步的（假设是同步）。</p>    <p>Javac 转化后的字符串连接代码为：</p>    <pre>  public static String concatString(String s1, String s2, String s3) {        StringBuffer sb = new StringBuffer();        sb.append(s1);        sb.append(s2);        sb.append(s3);        return sb.toString();    }    </pre>    <p>此时的锁对象就是sb,虚拟机观察变量 sb，很快就会发现它的动态作用域被限制在 concatString() 方法内部。也就是说，sb 的所有引用永远不会 “逃逸” 到concatString() 方法之外，其他线程无法访问到它，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。</p>    <p>>锁粗化</p>    <p>将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。</p>    <p>>轻量级锁</p>    <p>加锁过程：在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为 “01” 状态）虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝，这时候线程堆栈与对象头的状态如图 13-3 所示</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/4de19eec90ff55f507c0052cdb2cf5f6.png"></p>    <p>然后，虚拟机将使用 CAS 操作尝试将对象的 Mark Word 更新为指向 Lock Record 的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象 Mark Word 的锁标志位 （Mark Word 的最后 2bit）将转变为 “00”，即表示此对象处于轻量级锁定状态，这时线程堆栈与对象头的状态如图13-4        </p>    <p style="text-align: center;">      <img src="https://simg.open-open.com/show/583fbbd3eaef46beeee0597a60999273.png"></p>    <p>如果上述更新操作失败，则说明这个锁对象被其他锁占用，此时轻量级变为重量级锁，标志位为“10”，后面等待的线程进入阻塞状态。</p>    <p>解锁过程：也是由CAS进行操作的，如果对象的 Mark Word 仍然指向着线程的锁记录，那就用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其他线程尝试过获取该锁，那就要释放锁的同时，唤醒被挂起的线程。</p>    <p>轻量级锁能提升程序同步性能的依据是 “对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了 CAS 操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。</p>    <p>>偏向锁</p>    <p>偏向锁也是 JDK 1.6 中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用 CAS 操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连 CAS 操作都不做了。</p>    <p>实质就是设置一个变量，判断这个变量是否是当前线程，是就避免再次加锁解锁操作，从而避免了多次的CAS操作。坏处是如果一个线程持有偏向锁，另外一个线程想争用偏向对象，拥有者想释放这个偏向锁，释放会带来额外的性能开销，但是总体来说偏向锁带来的好处还是大于 CAS的代价的。在具体问题具体分析的前提下，有时候使用参数 -XX:-UseBiasedLocking 来禁止偏向锁优化反而可以提升性能。</p>    <h3>二、 lock <strong>的实现方案</strong></h3>    <p>与synchronized不同的是lock是纯java手写的，与底层的JVM无关。在 java.util.concurrent.locks包中有很多 Lock的实现类，常用的有ReenTrantLock、ReadWriteLock(实现类有ReenTrantReadWriteLock)</p>    <p>，其实现都依赖 java.util.concurrent.AbstractQueuedSynchronizer类（简称 AQS），实现思路都大同小异，因此我们以 ReentrantLock作为讲解切入点。</p>    <p>分析之前我们先来花点时间看下 AQS。 AQS是我们后面将要提到的 CountDownLatch/FutureTask/ReentrantLock/RenntrantReadWriteLock/Semaphore的基础，因此 AQS也是 Lock和 Excutor实现的基础。它的基本思想就是一个同步器，支持获取锁和释放锁两个操作。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/962224a093572985dd2b4e5ae383abdb.png"></p>    <p>要支持上面锁获取、释放锁就必须满足下面的条件：</p>    <p>1、  状态位必须是原子操作的</p>    <p>2、  阻塞和唤醒线程</p>    <p>3、  一个有序的队列，用于支持锁的公平性</p>    <p>场景：可定时的、可轮询的与可中断的锁获取操作，公平队列，或者非块结构的锁。</p>    <p>主要从以下几个特点介绍：</p>    <p>1.可重入锁</p>    <p>如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。</p>    <p>2.可中断锁</p>    <p>可中断锁：顾名思义，就是可以相应中断的锁。</p>    <p>在Java中，synchronized就不是可中断锁，而Lock是可中断锁。</p>    <p>如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。</p>    <p>3.公平锁和非公平锁</p>    <p>公平锁以请求锁的顺序来获取锁，非公平锁则是无法保证按照请求的顺序执行。synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。</p>    <p>参数为true时表示公平锁，不传或者false都是为非公平锁。</p>    <pre>  ReentrantLock lock = new ReentrantLock(true);  </pre>    <p>4.读写锁</p>    <p>读写锁将对一个资源（比如文件）的访问分成了2个锁，一个读锁和一个写锁。</p>    <p>正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。</p>    <p>ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。</p>    <p>可以通过readLock()获取读锁，通过writeLock()获取写锁。</p>    <h3>三、总结</h3>    <p>1.synchronized</p>    <p>优点：实现简单，语义清晰，便于JVM堆栈跟踪，加锁解锁过程由JVM自动控制，提供了多种优化方案，使用更广泛</p>    <p>缺点：悲观的排他锁，不能进行高级功能</p>    <p>2.lock</p>    <p>优点：可定时的、可轮询的与可中断的锁获取操作，提供了读写锁、公平锁和非公平锁</p>    <p>缺点：需手动释放锁unlock，不适合JVM进行堆栈跟踪</p>    <p>3.相同点</p>    <p>都是可重入锁</p>    <p>参考文章：http://www.cnblogs.com/longshiyVip/p/5213771.html</p>    <p> </p>    <p>来自：http://www.cnblogs.com/jiangds/p/6476293.html</p>    <p> </p>