1.同步机制
保证共享资源的读写安全，需要一种同步机制：用于解决2方面问题：
- 同步问题：即线程之间如何通信、协作。
- 互斥问题: 在同一时刻，只能有一个线程访问共享资源，通常被称为一种特殊的同步
2.同步机制-管程
2.1 认识管程
同步机制中有经典的管程方案，关于管程在并发的各种概念定义有做笔记整理。笔记看不懂就在中国大学mooc中搜索 管程 有些大学的操作系统课程会讲解管程。
管程其实就是对共享变量以及其操作的封装：
- 将共享资源封装起来，对外提供操作这些共享资源的方法。
- 线程只能通过调用管程中的方法来间接地访问管程中的共享资源
2.2 管程如何解决互斥和同步问题：
-
互斥问题：
1.1 管程是互斥进入，管程提供了入口等待队列：存储等待进入同步代码块的线程
1.2 管程的互斥性是由编译器负责保证的。 -
同步问题:
管程中设置条件变量，等待/唤醒操作，以解决同步问题。
2.1 条件变量（java里理解为锁对象自身）
2.2 等待操作:可以让进程、线程在条件变量上等待（此时，应先释放管程的使用权，不然别其它线程、进程拿不到使用权）；将线程存储到条件变量的等待队列中。
2.3 发信号操作:也可以通过发送信号将等待在条件变量上的进程、线程唤醒（将等待队列中的线程唤醒）
2.3 关键数据结构和方法：
- 线程队列：
1.1 入口等待队列：存储等待进入同步代码块的线程；线程进入管程后，可以执行同步块代码。java中的_EntryList
1.2 条件等待队列：入口等待队列中的线程，进入管程后，执行同步块代码的过程中，需要等待某个条件满足之后，才能继续执行，就将线程放入此变量的等待队列中。java是面向对象的设计，这里的条件变量即锁对象自身（线程都在等待拥有这个锁），所以只有一个条件变量等待队列即_WaitSet。 - 同步方法：
wait() ：等待条件变量，将线程放入条件变量的等待队列中。
notify()：激活某个条件变量上等待队列中的一个线程
notifyAll()：激活某个条件变量上等待队列中的所有线程
image.png
3. java版的管程synchronized
synchronized是语法糖，会被编译器编译成：1个monitorenter 和 2个monitorexit（一个用于正常退出，一个用于异常退出）。monitorenter 和 正常退出的monitorexit中间是synchronized包裹的代码，如下图：
image.png
synchronized的底层实现类ObjectMonitor的示意图：
image.png
_count：记录owner线程获取锁的次数，即重入次数，也即是可重入的。
_owner：指向拥有该对象的线程
_EntryList：管程的入口等待队列，即存放等待锁而被block的线程。
_WaitSet：管程的条件变量等待队列，存放拥有锁后，调用了wait()方法的线程。
image.png
3.1锁实例对象
- 同步实例方法
public synchronized void fun(){
}
- 同步代码块 参数是实例
public void fun(){
synchronized(this){
...
}
}
3.2锁类对象
- 同步静态方法
class Aclass{
static synchronized void fun(){
}
}
- 同步代码块 参数是类
class Aclass{
static void fun(){
synchronized (Aclass.class){
}
}
}
4. 对象的内存结构
HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域:对象头 (Header)、实例数据(Instance Data)和对齐填充(Padding)。
- 对象头:比如 hash码，对象所属的年代，对象锁，锁状态标志，偏向 锁(线程)ID，偏向时间，数组长度(数组对象)等
- 实例数据:即创建对象时，对象中成员变量，方法等
- 对齐填充:对象的大小必须是8字节的整数倍，这是计算机对内存的管理是以块为单位进行读写，块的大小是8字节的倍数。
image.png
4.1 Mark Word
Mark Word被设计成一个非固定的数据结构以便在极小的空间内 存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说， Mark Word会随着程序的运行发生变化，32位虚拟机中变化状态如下:
image.png
5.锁优化
5.1 锁膨胀
锁的性能开销的变化：无锁——>偏向锁——>轻量级锁——>重量级锁，并且膨胀方向不可逆。
image.png
偏向锁：线程获取锁后，锁对象的Mark Word标记偏向锁，通过一个字段记录当前线程id，
- 本线程再次争取锁时：检查这个线程ID跟自己一样，就重入。
- 不同的线程争取锁：，锁对象中的线程ID不是自己，且有偏向锁标识，则发起偏向锁取消操作。
2.1 在SafePoint的时候，若偏向锁取消成功，且当前线程通过CAS操作争取到了锁，则继续保持偏向锁状态.
2.2 若一次CAS操作未争取到锁，意味着还有其他的线程也在竞争这个锁，此时就进行锁升级，升级为请谅解锁。 - 轻量级锁时自适应自旋锁
3.1 自旋获取锁成功：保持轻量级锁状态？？
3.2 自旋获取锁失败 ，则进入重量级锁；
疑问点：锁不能降级，锁编程重量级锁之后，就一致要作为重量级锁使用吗？那还怎么自适应自旋？？
Java锁优化--JVM锁降级里说道：锁降级确实 是会发生的，当 JVM 进入安全点（SafePoint）的时候，会检查是否有闲置的 Monitor，然后试图进行降级。
从成本角度来说就是：
- 重量级锁：线程在用户态到内核态之间切换成本高，
- 其他的锁都是为了更小的开销：
2.1 偏向锁：一次CAS操作，修改一下锁中的字段，就被标识为拿得到了锁。
2.2 轻量锁：一次CAS操作拿不到锁，，那就自旋空转多次CAS操作，会稍稍费一点CPU，但是能更快的拿到锁；自适应自旋后，还拿不到锁，那就只能使用重量级锁了。
2.2.1 自旋锁：许多情况下，共享数据的锁定状态持续时间较短，切换线程不值得，通过让线程执行循环等待锁的释放，不让出CPU。如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式。但是它也存在缺点：如果锁被其他线程长时间占用，一直不释放CPU，会带来许多的性能开销。
2.2.2 自适应自旋锁：这种相当于是对上面自旋锁优化方式的进一步优化，它的自旋的次数不再固定，其自旋的次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，这就解决了自旋锁带来的缺点。
更多细节可以参考：聊聊并发（二）Java SE1.6中的Synchronized，里边描述的细节，有些地方推敲起来还不是很流畅。
5.2 锁消除
消除锁是虚拟机另外一种锁的优化，这种优化更彻底，在JIT编译时，对运行上下文进行扫描，做逃逸分析，去除不可能存在竞争的锁（去掉了申请和释放锁的代码了）。比如下面代码的method1和method2的执行效率是一样的，因为object锁是私有变量，不存在所得竞争关系。
image
5.3 锁粗化
锁粗化是虚拟机对另一种极端情况的优化处理，通过扩大锁的范围，避免反复获取锁和释放锁。比如下面method3经过锁粗化优化之后就和method4执行效率一样了。
image
6. synchronized 与 volatile的区别
volatile关键字本身就包含了禁止指令重排序的语义，而synchronized（及其它的锁）是通过“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步块智能串行的进入
网友评论