线程安全与锁优化、升级

  并发处理的广泛应用是使得 Amdahl 定律代替摩尔定律成为计算机性能发展源动力的根本原因，也是人类 “压榨” 计算机运算能力的最有力武器。

• Amdahl 定律：通过系统中并行化与串行化的比重来描述多处理器系统能获得的运算加速能力
• 摩尔定律：用于描述处理器晶体管数量与运行效率之间的发展关系

  这两个定律的更替代表了近年来硬件发展从追求处理器频率到追求多核心并行处理的发展过程。

一、概述

  在软件业发展的初期，程序编写都是以算法为核心的，程序员会把数据和过程分别作为独立的部分来考虑，数据代表问题空间中的客体，程序代码则用于处理这些数据，这种思维方式直接站在计算机的角度去抽象问题和解决问题，称为面向过程的编程思想。与此相对的是，面向对象的编程思想是站在现实世界的角度去抽象和解决问题，它把数据和行为都看做是对象的一部分，这样可以让程序员能以符合现实世界的思维方式来编写和组织程序。

二、线程安全

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

这个定义比较严谨，它要求线程安全的代码都必须具备一个特征：代码本身封装了所有必要的正确性保障手段（如互斥同步等），令调用者无须关心多线程的问题，更无须自己采取任何措施来保证多线程的正确调用。

2.1 java语言中的线程安全

前提：多个线程之间存在共享数据访问

  按照线程安全的“安全程度”由强至弱来排序，可以将Java语言中各种操作共享的数据分为以下5类：

• 不可变
• 绝对线程安全
• 相对线程安全
• 线程兼容
• 线程对立。

2.1.1 不可变

  JDK1.5之后，不可变的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施。

• 共享数据是一个基本数据类型：在定义时使用final关键字修饰它就可以保证它是不可变的。

• 共享数据是一个对象：需要保证对象的行为不会对其状态产生任何影响才行

java.lang.String类的对象就是一个典型的不可变对象，它的substring（）、 replace（）和concat（）这些方法都不会影响它原来的值，只会返回一个新构造的字符串对象。

除了String对象，常用的还有枚举类型，以及java.lang.N在这里插入代码片umber的部分子类，如Long和Double等数值包装类型，BigInteger和BigDecimal等大数据类型。

  保证对象行为不影响其状态的最简单的就是把对象中带有状态的变量都声明为final，这样在构造函数结束之后，它就是不可变的。

2.1.2 绝对线程安全

  满足绝对要求的东西，通常都要付出很大的代价，这个也不例外，所以java中的绝大多数标注自己是线程安全的类，大多数都不是绝对的线程安全。

例：vector类是线程安全的，它的set，get等方法都采用了synchronized同步，但是在某些情况下仍然不安全。

 private static Vector<Integer> vector = new Vector<Integer>();

    public static void main(String[] args) {
        while (true) {
            for (int i = 0; i < 10; i++) 
            {
                vector.add(i);
            }

            Thread removeThread = new Thread(new Runnable() 
            {
                @Override
                public void run() {
                    for (int i = 0; i < vector.size(); i++) {
                        vector.remove(i);
                    }
                }
            });

            Thread printThread = new Thread(new Runnable() 
            {
                @Override
                public void run() {
                    for (int i = 0; i < vector.size(); i++) {
                        System.out.println((vector.get(i)));
                    }
                }
            });

            removeThread.start();
            printThread.start();

            //不要同时产生过多的线程，否则会导致操作系统假死
            while (Thread.activeCount() > 20);
        }
    }

运行结果：

Exception in thread"Thread-132"java.lang.ArrayIndexOutOfBoundsException：
Array index out of range：17
at java.util.Vector.remove（Vector.java：777）
at org.fenixsoft.mulithread.VectorTest$1.run（VectorTest.java：21）
at java.lang.Thread.run（Thread.java：662）

  尽管这里使用到的Vector的get（）、 remove（）和size（）方法都是同步的，但是在多线程的环境中，如果不在方法调用端做额外的同步措施的话，使用这段代码仍然是不安全的，因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号i已经不再可用的话，再用i访问数组就会抛出一个ArrayIndexOutOfBoundsException。

解决方案：

 Thread removeThread = new Thread(new Runnable() {
        @Override
        public void run() {
            synchronized (vector) {
                for (int i = 0; i < vector.size(); i++) {
                    vector.remove(i);
                }
            }
        }
    });

    Thread printThread = new Thread(new Runnable() {
        @Override
        public void run() {
            synchronized (vector) {
                for (int i = 0; i < vector.size(); i++) {
                    System.out.println((vector.get(i)));
                }
            }
        }
    });

2.1.3 相对线程安全

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

2.1.4 线程兼容

  线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用。Java API 中大部分的类都是属于线程兼容的，如与前面的 Vector 和 HashTable 相对应的集合类 ArrayList 和 HashMap 等。

2.1.5 线程对立

  线程对立是指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。 java中线程对立这种排斥多线程的代码是很少出现的，而且通常都是有害的，应当尽量避免。

一个线程对立的例子是 Thread 类的 suspend() 和 resume() 方法，如果有两个线程同时持有一个线程对象，一个尝试去中断线程，另一个尝试去恢复线程，如果并发进行的话，无论调用时是否进行了同步，目标线程都是存在死锁风险的，如果 suspend() 中断的线程就是即将要执行 resume() 的那个线程，那就肯定要产生死锁了。也正是由于这个原因，suspend() 和 resume() 方法已经被 JDK 声明废弃（@Deprecated）了。常见的线程对立的操作还有 System.setIn()、System.setOut() 和 System.runFinalizerosOnExit() 等。

2.2 线程安全的实现方法

2.2.1 互斥同步

• 互斥同步（Mutual Exclusion & Synchronization）：常见的一种并发正确性保障手段。

• 同步：在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个（或者是一些，使用信号量的时候）线程使用。

  互斥实现同步的一种手段，临界区（Critical Section）、互斥量（Mutex）和信号量（Semaphore）都是主要的互斥实现方式。因此，在这 4 个字里面，互斥是因，同步是果；互斥是方法，同步是目的。

  在Java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。

  如果Java程序中的synchronized明确指定了对象参数，那就是这个对象的reference；如果没有明确指定，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。

  根据虚拟机规范的要求，在执行monitorenter指令时，首先要尝试获取对象的锁。 如果这个对象没被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器加1，相应的，在执行monitorexit指令时会将锁计数器减1，当计数器为0时，锁就被释放。 如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另外一个线程释放为止。

值得注意的两点：

• synchronized同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题

• 同步块在已进入的线程执行完之前，会阻塞后面其他线程的进入

java中阻塞或唤醒一个线程，都需要操作系统从用户态转换到核心态中，状态转换需要耗费很多的处理器时间。对于代码简单的同步块（如被synchronized修饰的getter（）或setter（）方法），状态转换消耗的时间有可能比用户代码执行的时间还要长。 所以synchronized是Java语言中一个重量级（Heavyweight）的操作，有经验的程序员都会在确实必要的情况下才使用这种操作。而虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，避免频繁地切入到核心态之中。

  除了 synchronized 之外，我们还可以使用 java.util.concurrent（下文成 J.U.C）包中的重入锁（ReentrantLock）来实现同步，在基本用法上，ReentrantLock 与 synchronized 很相似，他们都具备一样的线程重入特性，只是代码写法上有点区别：

• 一个表现为 API 层面的互斥锁（lock() 和 unlock() 方法配合 try/finally 语句块来完成）

• 另一个表现为原生语法层面的互斥锁。

不过，相比 synchronized，ReentrantLock 增加了一些高级功能，主要有以下 3 项：

• 等待可中断
  指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助。

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

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

如果读者的程序是使用 JDK 1.6 或以上部署的话，性能因素就不再是选择 ReentrantLock 的理由了，虚拟机在未来的性能改进中肯定也会更加偏向于原生的 synchronized，所以还是提倡在 synchronized 能实现需求的情况下，优先考虑使用 synchronized 来进行同步。

2.2.2 非阻塞同步

  互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronization）。 无论共享数据是否真的会出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。随着硬件指令集的发展，我们有了另外一个选择：基于冲突检测的乐观并发策略，即先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施，比如不断重试直到成功。这样就不需要把线程挂起。

  非阻塞同步依赖于硬件指令集的发展，因为我们需要操作和冲突检测这两个步骤具备原子性，靠什么来保证呢？如果这里再使用互斥同步来保证就失去意义了，所以我们只能靠硬件来完成这件事情，硬件保证一个从语法上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类指令常用的有：

• 测试并设置（Test-and-Set）。
• 获取并增加（Fetch-and-Increment）。
• 交换（Swap）。
• 比较并交换（Compare-and Swap，下文成 CAS）。
• 加载连接 / 条件存储（Load-Linked / Store-Conditional，下文称 LL/SC）。

CAS 指令需要有 3 个操作数：

• 内存位置：V （在 Java 中可以简单理解为变量的内存地址）
• 旧的预期值：A
• 新值： B

CAS 指令执行时，当且仅当 V 符合旧值预期值 A 时，处理器用新值 B 更新 V 的值，否则它就不执行更新，但是无论是否更新了 V 的值，都会返回 V 的旧值，上述的处理过程是一个原子操作。

在 JDK 1.5 之后，Java 程序中才可以使用 CAS 操作，该操作由 sun.misc.Unsafe 类里面的 compareAndSwapInt() 和 compareAndSwapLong() 等几个方法包装提供，虚拟机在内部对这些方法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器 CAS 指令，没有方法调用的过程，或者可以认为是无条件内联进去了。（注：这种被虚拟机特殊处理的方法称为固有函数（intrinsics），类似的固有函数还有 Math.sin() 等）

由于 Unsafe 类不是提供给用户程序调用的类（Unsafe.getUnsafe() 的代码中限制了只有启动类加载器（Bootstrap ClassLoader）加载的 Class 才能访问它），因此，如果不采用反射手段，我们只能通过其他的 Java API 来间接使用它，如 J.U.C 包里面的整数原子类，其中的 compareAndSet() 和 getAndIncrement() 等方法都使用了 Unsafe 类的 CAS 操作。

例：我们曾在上一章通过这段 20 个线程自增 10000 次的代码来证明 volatile 变量不具备原子性，那么如何才能让它具备原子性呢？把 “race++” 操作或 increase() 方法用同步块包裹起来当然是一个办法，但是如果改成如下代码清单所示的代码，那效率将会提高许多

/**
 * Atomic变量自增运算测试
 * 
 * @author zzm
*/
public class AtomicTest {

    public static AtomicInteger race = new AtomicInteger(0);

    public static void increase() 
    {
        race.incrementAndGet();
    }

    private static final int THREADS_COUNT = 20;

    public static void main(String[] args) throws Exception {
        Thread[] threads = new Thread[THREADS_COUNT];
        for (int i = 0; i < THREADS_COUNT; i++) {
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < 10000; i++) {
                        increase();
                    }
                }
            });
            threads[i].start();
        }

        while (Thread.activeCount() > 1)
            Thread.yield();

        System.out.println(race);
    }
}

运行结果：

200000

使用 AtomicInteger 代替 int 后，程序输出了正确的结果，一切都要归功于 incrementAndGet() 方法的原子性。它的实现其实非常简单，如下代码清单所示。

   /**
     * Atomically increment by one the current value.
     * @return the updated value
     */
    public final int incrementAndGet() 
    {
        for (;;) {
            int current = get();
            int next = current + 1;
            if (compareAndSet(current, next))
                return next;
        }
    }

incrementAndGet() 方法在一个无限循环中，不断尝试将一个比当前值大 1 的新值赋给自己。如果失败了，那说明在执行 “获取-设置” 操作的时候值已经有了修改，于是再次循环进行下一次操作，直到设置成功为止。

尽管 CAS 看起来很美，但显然这种操作无法涵盖互斥同步的所有使用场景，并且 CAS 从语义上来说并不是完美的，存在这样的一个逻辑漏洞：如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然为 A 值，那我们就能说它没有被其他线程改变过了吗？如果在这段期间它的值曾经被改成了 B，后来又被改回 A，那 CAS 操作就会误认为它从来没有被改变过。这个漏洞称为 CAS 操作的 “ABA” 问题。J.U.C 包为了解决这个问题，提供了一个带有标记的原子引用类 “AtomicStampedReference”，它可以通过控制变量值的版本来保证 CAS 的正确性。不过目前来说这个类比较 “鸡肋”，大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更高效。

2.2.3 无同步方案

  同步只是保证共享数据争用时的正确性的手段，如果方法本身就不涉及共享数据，那么明显是线程安全的。以下为典型的两类的介绍：

• 可重入代码（Reentrant Code）
  这种代码也叫做纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。可重入的代码都是线程安全的，但线程安全的代码并不一定是可重入的。

可重入代码有一些共同的特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都由参数中传入、不调用非可重入的方法等。我们可以通过一个简单的原则来判断代码是否具备可重入性：如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。

例：可重入代码指可被多个函数或程序调用的一段代码(通常是一个函数),而且它保证在被任何一个函数调用时都以同样的方式运行,如:

void test()
{
	int i;
	i=2;
	printf("%d\n",i );
	i++;
	printf("%d\n",i);
}

无论谁调用它结果都一样,得到

2
3

但

void test()
{
	static int i=2;			//依赖于堆栈中数据？
	printf("%d\n",i );
	i++;
	prinft("%d\n",i);
}

就不一样了,对不同的调用结果不一样:如:
第一次:

2
3

第二次

3
4

第三次

4
5

• 线程本地存储（Thread Local Storage）
  如果共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。

Java 语言中，如果一个变量要被多线程访问，可以使用 volatile 关键字声明它为 “易变的”

三、锁优化

3.1 自旋锁与自适应自旋

  互斥同步对性能最大的营销阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态完成，这些操作给系统的并发性能带来了很大的压力在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。 这时，可以让后面请求锁的那个线程执行一个忙循环（自旋），但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁，这项技术就是所谓的自旋锁。

  自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，因此，如果锁被占用的时间很短，自旋等待的效果就会非常好，反之，如果锁被占用的时间很长，那么自旋的线程只会白白耗处理器资源，而不会做任何有用的工作，反而会带来性能上的浪费。 因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了。 自旋次数的默认值是 10 次，用户可以使用参数 -XX:PreBlockSpin 来更改。

  在 JDK 1.6 中引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如 100 个循环。另外，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。

  有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机就会变得越来越 “聪明” 了。

3.2 锁消除

  锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。很多的同步措施并不是程序员自己加入的，而是JVM在运行期间转换导致的。

锁消除的主要判定依据来源于逃逸分析的数据支持，如果判定在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把他们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。

例：一段看起来没有同步的代码

public static String concatString(String s1, String s2, String s3) 
{
	return s1 + s2 + s3;
}

Java转化后的字符串连接操作

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();
}

每个 StringBuffer.append() 方法中都有一个同步块，锁就是 sb 对象。

虚拟机观察变量 sb，很快就会发现它的动态作用域被限制在 concatString() 方法内部。也就是说，sb 的所有引用永远不会 “逃逸” 到 concatString() 方法之外，其他线程无法访问到它，因此，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。

3.3 锁粗化

  如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，这样只需要加锁一次就可以了。

3.4 轻量级锁

  轻量级锁并不是用来代替重量级锁（传统的锁机制）的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

1. HotSpot 虚拟机的对象（对象头部分）的内存布局

  HotSpot 虚拟机的对象头（Object Header）分为两部分信息：

• 第一部分：用于存储对象自身的运行时数据，如哈希码（HashCode）、GC 分代年龄（Generational GC Age）等，这部分数据是长度在 32 位和 64 位的虚拟机中分别为 32 bit 和 64 bit，官方称它为 “Mark Word”，它是实现轻量级锁和偏向锁的关键。
• 另外一部分用于存储指向方法区对象类型数据的指针，如果是数组对象的话，还会有一个额外的部分用于存储数组长度。

  对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Work 被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。

例如，在 32 位的 HotSpot 虚拟机中对象未被锁定的状态下，Mark Word 的 32bit 空间中：

所占空间	用途
25bit	用于存储对象哈希码（HashCode）
4bit	用于存储对象分代年龄
2bit	用于存储锁标志位
1bit	固定为 0

在其他状态（轻量级锁定、重量级锁定、GC 标记、可偏向）下对象的存储内容见表HotSpot虚拟机对象头 Mark Word：

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

2. 轻量级锁的执行过程

  在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为 “01” 状态）虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝（官方把这份拷贝加上了一个 Displaced 前缀，即 Displaced Mark Word），这时候线程堆栈与对象头的状态如下图所示：

  然后，虚拟机将使用 CAS 操作尝试将对象的 Mark Word 更新为指向 Lock Record 的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象 Mark Word 的锁标志位 （Mark Word 的最后 2bit）将转变为 “00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图：

  如果这个更新操作失败了，虚拟机首先会检查对象的 Mark Word 是否指向当前线程的栈帧，如果指说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象以及被其他线程线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态变为 “10”，Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

3. 轻量级锁的解锁过程

  它的解锁过程也是通过 CAS 操作来进行的，如果对象的 Mark Word 仍然指向着线程的锁记录，那就用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其他线程尝试过获取该锁，那就要释放锁的同时，唤醒被挂起的线程。

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

3.5 偏向锁

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

偏向锁的 “偏”，就是偏心的 “偏”、偏袒的 “偏”，它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

1. 偏向锁的原理

  假设当前虚拟机启用了偏向锁（启用参数 -XX:+UseBiasedLocking，这是 JDK 1.6 的默认值），那么，当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为 “01”，即偏向模式。同时使用 CAS 操作把获取到这个锁的线程 ID 记录在对象的 Mark Word 之中，如果 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如 Locking、Unlocking 及对 Mark Word 的 Update 等）。

  当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为 “01”）或轻量级锁定（标志位为 “00”）的状态，后续的同步操作就如上面介绍的轻量级锁那样执行。偏向锁、轻量级锁的状态转换及对象 Mark Word 的关系如图：

四、锁升级

jdk 1.6中将锁分为四种状态：由低到高分别为：

• 无锁状态
• 偏向锁状态
• 轻量级锁状态
• 重量级锁状态

4.1 偏向锁

  偏向锁是如果一个线程获取到了偏向锁，在没有其他线程竞争的情况下，如果下次再执行该同步块时则只需要简单判断当前偏向锁所偏向的对象是否是当前线程，如果是则不需要再进行任何获取锁与释放锁的过程，直接执行同步块。

  当一个线程在执行同步块时，它会先获取该对象头的MarkWord，通过MarkWord来判断当前虚拟机是否支持偏向锁（因为偏向锁是可以手动关闭的），如果不支持则直接进入轻量级锁获取过程。如果支持，则判断当前MarkWord中存储的ThreadID是否指向当前线程，如果指向当前线程，则直接开始执行同步块。如果没有指向当前线程，则通过CAS将对象头的MarkWord中相应位置替换为当前线程ID表示当前线程获取到了偏向锁，如果CAS成功，同时将偏向锁置为1，执行同步块；若CAS失败，则表示存在多个线程竞争，当达到全局安全点(safepoint)的时候，暂停获得偏向锁的线程，撤销偏向锁（将偏向锁置为0，并且将ThreadID置为空），然后将锁升级为轻量级锁，之后恢复刚暂停的线程，则刚刚CAS失败的线程通过自旋的方式等待轻量级锁被释放。

4.2 轻量级锁

  轻量级锁是当一个线程获取到该锁后，另一个线程也来获取该锁，这个线程并不会被直接阻塞，而是通过自旋来等待该锁被释放，所谓的自旋就是让线程执行一段无意义的循环。

• 如果直到自旋结束该锁还未被释放，那么此时轻量级锁膨胀为重量级锁，将后面的线程全部阻塞

• 如果线程2正在自旋等待线程1释放锁，此时线程3也来竞争锁，那么这时该轻量级锁膨胀为重量级锁将等待线程全部阻塞。
  

4.3 重量级锁

  重量级锁是如果多个线程同时竞争锁，只会有一个线程得到这把锁，其他线程获取锁失败不会和轻量级锁一样进行自旋等待锁被释放，而是直接阻塞没有获取成功的线程。重量级锁的实现与对象内部的monitor监视器息息相关。monitor在虚拟机中实际实现是ObjectMonitor。通过JVM顶级基类oopDesc类中的一个成员oopMark类型的子对象去调monitor()方法来获取到ObjectMonitor对象，而重量级锁就是通过获取ObjectMonitor这把监视器锁来实现的。