刨根问底synchronized | 锁系列-Java中的锁

铺垫

在Java SE 1.5之前，多线程并发中，synchronized一直都是一个元老级关键字，而且给人的一贯印象就是一个比较重的锁。

为此，在Java SE 1.6之后，这个关键字被做了很多的优化，从而让以往的“重量级锁”变得不再那么重。

synchronized主要有两种使用方法，一种是代码块，一种关键字写在方法上。

这两种用法底层究竟是怎么实现的呢？在1.6之前是怎么实现的呢？

字节码实现原理

在java语言中存在两种内建的synchronized语法：1、synchronized语句；2、synchronized方法。对于synchronized语句当Java源代码被javac编译成bytecode的时候，会在同步块的入口位置和退出位置分别插入monitorenter和monitorexit字节码指令。而synchronized方法则会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令，在VM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法，而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1，表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass做为锁对象。

那么monitorenter和monitorexit以及access_flags底层又是通过什么底层技术来实现的原子操作呢？

Mutex Lock

简单来说在JVM中monitorenter和monitorexit字节码依赖于底层的操作系统的Mutex Lock来实现的，但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的。

那么我们来看看mutex lock又是一个什么鬼？

我们来看看常见的linux的内核互斥锁长什么样：

/linux/include/linux/mutex.h

struct mutex { /* 1: unlocked, 0: locked, negative: locked, possible waiters */ atomic_t count; spinlock_t wait_lock; struct list_head wait_list; #ifdef CONFIG_DEBUG_MUTEXES struct thread_info *owner; const char *name; void *magic; #endif #ifdef CONFIG_DEBUG_LOCK_ALLOC struct lockdep_map dep_map; #endif };

mutex lock的作用及访问规则：

mutex lock互斥锁主要用于实现内核中的互斥访问功能。mutex lock内核互斥锁是在原子 API 之上实现的，但这对于内核用户是不可见的。对它的访问必须遵循一些规则：同一时间只能有一个任务持有互斥锁，而且只有这个任务可以对互斥锁进行解锁。互斥锁不能进行递归锁定或解锁。一个互斥锁对象必须通过其API初始化，而不能使用memset或复制初始化。一个任务在持有互斥锁的时候是不能结束的。互斥锁所使用的内存区域是不能被释放的。使用中的互斥锁是不能被重新初始化的。并且互斥锁不能用于中断上下文。但是互斥锁比当前的内核信号量选项更快，并且更加紧凑，因此如果它们满足您的需求，那么它们将是您明智的选择。

各字段解释：

1、atomic_t count。指示互斥锁的状态：

1 没有上锁，可以获得

0 被锁定，不能获得

负数 被锁定，且可能在该锁上有等待进程

初始化为没有上锁。

2、spinlock_t wait_lock。

等待获取互斥锁中使用的自旋锁。在获取互斥锁的过程中，操作会在自旋锁的保护中进行。初始化为为锁定。

3、struct list_head wait_list。

等待互斥锁的进程队列。

知道了操作系统是如何实现锁的？那么mutex lock的底层实现又是基于什么呢？

自然要去看看cpu的内容了。

cpu层面实现锁

先考虑单核场景：

能不能硬件做一种加锁的原子操作呢？能，大名鼎鼎的“test and set”指令就是做这个事情的。

通过上面的手段，单核环境下，锁的实现问题得到了圆满的解决。那么多核环境呢？简单嘛，还是“test and set”不就得了，这是一条指令，原子的，不会有问题的。真的吗，单独一条指令能够保证该指令在单个核上执行过程中不会被中断打断，但是两个核同时执行这个指令呢？。。。你再想想，硬件执行时还是得从内存中读取lock，判断并设置状态到内存，貌似这个过程也不是那么原子嘛。对，多个核执行确实会存在这个问题。怎么办呢？首先我们得明白这个地方的关键点，关键点是两个核会并行操作内存而且从操作内存这个调度来看“test and set”不是原子的，需要先读内存然后再写内存，如果我们保证这个内存操作是原子的，就能保证锁的正确性了。确实，硬件提供了锁内存总线的机制，我们在锁内存总线的状态下执行test and set操作，就能保证同时只有一个核来test and set，从而避免了多核下发生的问题。

总结一下，在硬件层面，CPU提供了原子操作、关中断、锁内存总线的机制；OS基于这几个CPU硬件机制，就能够实现锁；再基于锁，就能够实现各种各样的同步机制（信号量、消息、Barrier等等等等）。所以要想理解OS的各种同步手段，首先需要理解cpu层面的锁，这是最原点的机制，所有的OS上层同步手段都基于此。

上面从语言级、操作系统级别一直到cpu级别，逐步深挖，来阐释synchronized锁的重量级锁的实现。

锁优化

但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的；然而在现实中的大部分情况下，同步方法是运行在单线程环境（无锁竞争环境）如果每次都调用Mutex Lock那么将严重的影响程序的性能。不过在jdk1.6中对锁的实现引入了大量的优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销。

用户态和内核态

至于用户态和内核态的这里简单介绍下：

Linux操作系统的体系架构分为用户态和内核态（或者用户空间和内核）。内核从本质上看是一种软件——控制计算机的硬件资源，并提供上层应用程序运行的环境。用户态即上层应用程序的活动空间，应用程序的执行必须依托于内核提供的资源，包括CPU资源、存储资源、I/O资源等。为了使上层应用能够访问到这些资源，内核必须为上层应用提供访问的接口：即系统调用。

内核态: CPU可以访问内存所有数据, 包括外围设备, 例如硬盘, 网卡. CPU也可以将自己从一个程序切换到另一个程序。

用户态: 只能受限的访问内存, 且不允许访问外围设备. 占用CPU的能力被剥夺, CPU资源可以被其他程序获取。

用户态和内核态的切换

　　因为操作系统的资源是有限的，如果访问资源的操作过多，必然会消耗过多的资源，而且如果不对这些操作加以区分，很可能造成资源访问的冲突。所以，为了减少有限资源的访问和使用冲突，Unix/Linux的设计哲学之一就是：对不同的操作赋予不同的执行等级，就是所谓特权的概念。简单说就是有多大能力做多大的事，与系统相关的一些特别关键的操作必须由最高特权的程序来完成。Intel的X86架构的CPU提供了0到3四个特权级，数字越小，特权越高，Linux操作系统中主要采用了0和3两个特权级，分别对应的就是内核态和用户态。运行于用户态的进程可以执行的操作和访问的资源都会受到极大的限制，而运行在内核态的进程则可以执行任何操作并且在资源的使用上没有限制。很多程序开始时运行于用户态，但在执行的过程中，一些操作需要在内核权限下才能执行，这就涉及到一个从用户态切换到内核态的过程。比如C函数库中的内存分配函数malloc()，它具体是使用sbrk()系统调用来分配内存，当malloc调用sbrk()的时候就涉及一次从用户态到内核态的切换，类似的函数还有printf()，调用的是wirte()系统调用来输出字符串，等等。

所有用户程序都是运行在用户态的, 但是有时候程序确实需要做一些内核态的事情, 例如从硬盘读取数据, 或者从键盘获取输入等. 而唯一可以做这些事情的就是操作系统, 所以此时程序就需要先操作系统请求以程序的名义来执行这些操作.

这时需要一个这样的机制: 用户态程序切换到内核态, 但是不能控制在内核态中执行的指令。

这种机制叫系统调用, 在CPU中的实现称之为陷阱指令(Trap Instruction)

他们的工作流程如下:

1、用户态程序将一些数据值放在寄存器中, 或者使用参数创建一个堆栈(stack frame), 以此表明需要操作系统提供的服务。

2、用户态程序执行陷阱指令。

3、CPU切换到内核态, 并跳到位于内存指定位置的指令, 这些指令是操作系统的一部分, 他们具有内存保护, 不可被用户态程序访问。

4、这些指令称之为陷阱(trap)或者系统调用处理器(system call handler). 他们会读取程序放入内存的数据参数, 并执行程序请求的服务。

5、系统调用完成后, 操作系统会重置CPU为用户态并返回系统调用的结果。

简单来说在JVM中monitorenter和monitorexit字节码依赖于底层的操作系统的Mutex Lock来实现的，但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的。然而在现实中的大部分情况下，同步方法是运行在单线程环境（无锁竞争环境）如果每次都调用Mutex Lock那么将严重的影响程序的性能。不过在jdk1.6中对锁的实现引入了大量的优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销。

锁粗化（Lock Coarsening）

也就是减少不必要的紧连在一起的unlock，lock操作，将多个连续的锁扩展成一个范围更大的锁。

如果一段代码经常性的加锁和解锁，在解锁与下次加锁之间又没干什么事情，则可以将多次加加锁解锁操作合并成一对。这一功能可用-XX：-EliminateLocks禁止。

锁消除（Lock Elimination）

通过运行时JIT编译器的逃逸分析来消除一些没有在当前同步块以外被其他线程共享的数据的锁保护，通过逃逸分析也可以在线程本地Stack上进行对象空间的分配（同时还可以减少Heap上的垃圾收集开销）。

直白点就是对于一些明显不会产生竞争的情况下，Jvm会根据现实执行情况对代码的锁进行擦除以提高执行效率。

轻量级锁（Lightweight Locking）

这种锁实现的背后基于这样一种假设，即在真实的情况下我们程序中的大部分同步代码一般都处于无锁竞争状态（即单线程执行环境），在无锁竞争的情况下完全可以避免调用操作系统层面的重量级互斥锁，取而代之的是在monitorenter和monitorexit中只需要依靠一条CAS原子指令就可以完成锁的获取及释放。当存在锁竞争的情况下，执行CAS指令失败的线程将调用操作系统互斥锁进入到阻塞状态，当锁被释放的时候被唤醒。

我的理解是不用有多核情况下的用户态到内核态的切换了。只需要考虑单核的情况了。

偏向锁（Biased Locking）

引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。下面看具体细节：

上图为Mark Word对象头的布局，其中有一个thread ID。偏向锁就是通过这个来实现的。

具体逻辑就是：

以下文字摘自《实战java高并发程序设计》 一书中 4.2Java虚拟机对锁优化所做的努力：

“锁偏向是一种针对加锁操作的优化手段。它的核心思想是：如果一个线程获得了锁，那么锁就进入偏向模式。当这个线程再次请求锁时，无须再做任何同步操作。这样就节省了大量有关锁申请的操作，从而提高了程序性能。因此，对于几乎没有锁竞争的场合，偏向锁有比较好的优化效果，因为连续多次极有可能是同一个线程请求相同的锁。而对于锁竞争比较激烈的场合，其效果不佳。因为在竞争激烈的场合，最有可能的情况是每次都是不同的线程来请求相同的锁。这样偏向模式会失效，因此还不如不启用偏向锁”。

以下为维基百科中的介绍，简单看看吧：

Briefly, the compare-and-swap (CAS) operations normally used to acquire a Java monitor incurs considerable local latency in the executing CPU. Since most objects are locked by at most one thread during their lifetime, we allow that thread to bias an object toward itself. Once biased, that thread can subsequently lock and unlock the object without resorting to expensive atomic instructions.

在JDK1.6以后默认已经开启了偏向锁这个优化，我们可以通过在启动JVM的时候加上-XX:-UseBiasedLocking参数来禁用偏向锁（在存在大量锁对象的创建并高度并发的环境下禁用偏向锁能够带来一定的性能优化）。

适应性自旋（Adaptive Spinning）

当线程在获取轻量级锁的过程中执行CAS操作失败时，在进入与monitor相关联的操作系统重量级锁（mutex semaphore）前会进入忙等待（Spinning）然后再次尝试，当尝试一定的次数后如果仍然没有成功则调用与该monitor关联的semaphore（即互斥锁）进入到阻塞状态。

自旋锁不会引起调用者睡眠，如果自旋锁已经被别的单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，“自旋”一词就是因此而得名。

也就是说自旋锁就是一直在那里刷新，看看锁有没有被释放。而不是像传统的那种等待正在调用的线程释放锁后，然后通知这些等待的锁然后唤醒。

关于TAS vs CAS

另外一个事情，就是也许你会有所疑惑，怎么一会test and set ，一会又是compare and swap ，二者究竟有什么不同：

test-and-set modifies the contents of a memory location and returns its old value as a single atomic operation. compare-and-swap atomically compares the contents of a memory location to a given value and, only if they are the same, modifies the contents of that memory location to a given new value.

其实这两个都是cpu的原子指令：

CAS原子操作在维基百科中的代码描述如下:

int compare_and_swap(int* reg, int oldval, int newval) { ATOMIC(); int old_reg_val = *reg; if (old_reg_val == oldval) *reg = newval; END_ATOMIC(); return old_reg_val; }

也就是检查内存*reg里的值是不是oldval，如果是的话，则对其赋值newval。上面的代码总是返回old_reg_value，调用者如果需要知道是否更新成功还需要做进一步判断，为了方便，它可以变种为直接返回是否更新成功，如下：

bool compare_and_swap (int *accum, int *dest, int newval) { if ( *accum == *dest ) { *dest = newval; return true; } return false; }

Test-And-Set，写值到某个内存位置并传回其旧值。汇编指令BST。

#define LOCKED 1 int TestAndSet(int* lockPtr) { int oldValue; // Start of atomic segment // The following statements should be interpreted as pseudocode for // illustrative purposes only. // Traditional compilation of this code will not guarantee atomicity, the // use of shared memory (i.e. not-cached values), protection from compiler // optimization, or other required properties. oldValue = *lockPtr; *lockPtr = LOCKED; // End of atomic segment return oldValue; }

总结

本文试图对java的synchronized关键字从语言层面到jvm，再到操作系统，再到

cpu层层深挖，让我们对synchronized有一个深刻的理解。在java6之前，synchronized关键字就是那个很重的互斥锁。我们之所以说它重，是因为底层需要进行用户态到内核态的切换。于是在java6中对synchronized进行了优化。减少底层的切换，于是有了轻量级锁，只是进行基本的CAS原子操作；然而CAS还是会涉及的底层，于是又有了偏向锁，通过mark word对象头中的thread ID进行置换，如果下次还是同样的线程，那么就直接进入，而不再需要进行CAS底层原子操作。另外我们也介绍了锁消除这种机制，从而减少了一些根本不必要的同步。我们还简单的讨论了锁粗化，这是一种减少我们频繁的获取和释放锁的不错的做法。

以上是本人学习后的总结，如果不对之处还望指正！