Java Synchronised机制

本文章为转载：https://blog.dreamtobe.cn/2015/11/13/java_synchronized/

I. 原末

矛盾1

A: 重量级锁中的阻塞(挂起线程/恢复线程): 需要转入内核态中完成，有很大的性能影响。

B: 锁大多数情况都是在很短的时间执行完成。

解决方案: 引入轻量锁(通过自旋来完成锁竞争)。

矛盾2

A: 重量级锁中的阻塞(挂起线程/恢复线程): 需要转入内核态中完成，有很大的性能影响。

B: 锁大多数情况都是在很短的时间执行完成。

解决方案: 引入轻量锁(通过自旋来完成锁竞争)。

矛盾3

A: 无论是轻量级锁还是重量级锁: 在进入与退出时都要通过CAS修改对象头中的Mark Word来进行加锁与释放锁。

B: 在一些情况下总是同一线程多次获得锁，此时第二次再重新做CAS修改对象头中的Mark Word这样的操作，有些多余。

解决方案: JDK6引入偏向锁(首次需要通过CAS修改对象头中的Mark Word，之后该线程再进入只需要比较对象头中的Mark Word的Thread ID是否与当前的一致，如果一致说明已经取得锁，就不用再CAS了)。

矛盾4

A: 项目中代码块中可能绝大情况下都是多线程访问。

B: 每次都是先偏向锁然后过渡到轻量锁，而偏向锁能用到的又很少。

解决方案: 可以使用-XX:-UseBiasedLocking=false禁用偏向锁。

矛盾5

A: 代码中JDK原生或其他的工具方法中带有大量的加锁。

B: 实际过程中，很有可能很多加锁是无效的(如局部变量作为锁，由于每次都是新对象新锁，所以没有意义)。

解决方法: 引入锁削除(虚拟机即时编译器(JIT)运行时，依据逃逸分析的数据检测到不可能存在竞争的锁，就自动将该锁消除)。

矛盾6

A: 为了让锁颗粒度更小，或者原生方法中带有锁，很有可能在一个频繁执行(如循环)中对同一对象加锁。

B: 由于在频繁的执行中，反复的加锁和解锁，这种频繁的锁竞争带来很大的性能损耗。

解决方法: 引入锁膨胀(会自动将锁的范围拓展到操作序列(如循环)外, 可以理解为将一些反复的锁合为一个锁放在它们外部)。

II. 基本原理

JVM会为每个对象分配一个monitor，而同时只能有一个线程可以获得该对象monitor的所有权。在线程进入时通过monitorenter尝试取得对象monitor所有权，退出时通过monitorexit释放对象monitor所有权。

monitorenter与monitorexit在编译后对称插入代码。

• monitorenter: 被插入到同步代码块之前。
• monitorexit: 被插到同步代码块之后或异常处。

1. 相关数据存在哪里?

对象头。
对象头结构

数组会多1字宽(32位: 4字节)来存储数组长度

长度	内容	说明
1字宽	Mark Word	存储对象的hashCode或锁信息等
1字宽	Class Metadata Address	存储对象类型数据的指针
1字宽	Array length	数组长度(如果是数组对象)

而对象的锁，一般只和Mark Word有关。

2. 各个锁的关系以及升级情况?

mark word 信息

锁升级是单向的: 无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁

III. 多线程下数据同步

这类锁/关键字主要是为了维护数据在高并发情况下的一致性/稳定性。

1. 数据库中的锁

共享锁(Share Lock)

又称为读锁

多个线程可并发的获得某个数据的共享锁锁，并行读取数据。在数据存在共享锁期间，不能修改数据，不能加排他锁。

如MySQL中，在查询语句最后加上LOCK IN SHARE MODE。

排他锁(eXclusive Lock)

又称为写锁

同能只能有一个线程可以获得某个数据的排他锁。在线程获取排他锁后，该线程可对数据读写，但是其他线程不能对该数据添加任何锁。

根据数据类型可分： 行锁和表锁
根据锁状态分为：悲观锁和乐观锁

2. volatile

如果一个共享变量被声明成volatile，java线程内存模型将会确保所有线程看到这个变量的值是一致的。

• 基本策略: 写操作时，会有Lock前缀指定，处理器会立马将修改直接写回系统内存，并且其他处理器会将该值在其上的高速缓存标为无效。
• 可能带来的性能消耗: 写操作实时写回内存，锁总线/锁内存。
• 优势: 一些场景上相比synchronized，执行成本更低(不会引起线程上下文切换以及调度)，使用更方便。