线程状态分析图

editByWpp.png

Synchronized的两种用法

• 对象锁：
  包括方法锁（默认对象锁为this当前实例对象）和同步代码块锁（自己指定锁对象）
• 类锁：
  指Synchronized修饰静态的方法或指定锁为Class对象

 类锁的概念：
      Java类可能有多个对象，但只有1个Class对象
      - 本质：所以所谓的类锁，不过是Class对象的锁而已
      - 用法和效果：类锁只能在同一时刻被一个对象拥有
类锁的形式
    1.synchronized 放到方法上
    2.synchronized （*.class）代码块

多线程访问同步方法的7种情况

• 1、两个线程同时访问一个对象的同步方法
• 2、 两个线程访问的是两个对象的同步方法
• 3、 两个线程访问的是synchronized的静态方法
• 4、同时访问同步方法和非同步方法（非同步方法不受到影响 ）
• 5、访问同一个对象的不同的普通同步方法
• 6、同时访问静态synchronized和非静态synchronized方法
• 7、方法抛出异常后，会释放锁（Lock的对应的锁不会释放锁，此处针对的是synchronized修饰的锁）

1.一把锁只能同时被一个线程获取，没有拿到锁的线程必须等待（对应1、5）
2.每个实例都对应有自己的一把锁，不同锁实例之间互不影响；例外：锁对象是*.class以及synchronized修饰的静态方法的时候，所有对象共用同一把类锁（对应2、3、4、6）
3.无论是方法正常执行完毕还是方法抛出异常，都会抛出异常（对应7）
注意：被synchronized修饰的方法a中调用另一个没有被synchronized修饰的方法b时,b可以被别的线程访问，此时方法b不受synchronized保护

性质

• 可重入
• 不可中断（劣势所在）

什么是可重入:指的是同一线程的外层函数获得锁之后，内层函数可以直接
再次获取锁
好处：避免死锁、提升封装性
粒度：线程而非调用（用三种情况来说明和pthread的区别）

粒度

• 情况1、证明同一个方法是可重入的
• 情况2、证明可重入方法不要求是同一个方法
• 情况3、证明可重入方法不要球在同一个类中

不可中断

一旦这个锁被别人获得了，如果我还想获得，我只能选择等待或者阻塞，直到别的线程释放这个锁。如果别人永远不释放锁，那么我只能永远的等待下去。

相比之下，和Lock类比较，Lock可以拥有中断的能力，第一点，如果我觉得我等待时间太长了，我有权中断现在已经获得锁的线程的执行；第二点 如果我觉得我等的时间太长了 我可以选择退出等待状态。

原理

• 加锁和释放锁的原理：现象、时机、深入JVM看字节码
• 可重入原理 ：加锁次数计数器
• 保证可见性的原理：内存模型

加锁和释放锁的原理

• 现象
• 获取 和 释放锁的时机:内置锁
• 等价代码
• 深入JVM看字节码、反编译、monitor

加锁和释放锁的原理：深入JVM看字节码
1、 概况--java虚拟机规范中有个monitor对象，该是对synchronized的实现的关键；monitor有个enter和exit
2、如何反编译呢？
javac xxx.java 编译 javap -verbose xxx.class 反编译（verbose 打印详细信息）
3.Monditorenter 和 Monditorexit指令

Monditorenter 
每个对象都与一个montior有关、每个monitor的lock锁在同一时间只能被一个线程获得；
当一个线程在尝试获得关于某个线程的所有权的时候，会出现一下三种情况之一：
1、当这个计数器为0时，表示这个锁处于闲置状态，这个线程会立刻获得这把锁，同时将计数器加一，
    表示获得这把锁的所有权，别的线程就不能再获得这把锁了；
2、（可重入性原则）当这个线程重入的时候，会导致该计数器加一；
3、当某线程尝试获取某把锁的时候，发现该对应的计数器计数器不为0，那么该线程就会进入阻塞状态，等待获得锁的线程释放锁

Monditorexit
每执行一次Monditorenter  该计数器就减一，若减一之后不为0，继续持有锁，为0则会释放锁，别的处于阻塞状态的线程就可以去抢这把锁了

可重入性原理

• JVM 负责跟踪对象被加锁的次数
• 线程第一次给对象加锁的时候，计数变成1.每当这个相同的线程再此对象上再此获得锁的时候，计数器会加一
• 没当任务离开时，计数递减，当计数为0时，锁完全释放

可见性的原理（内存模型）

image.png

缺陷

• 效率低： 锁的释放情况少、试图获得锁时不能设置超时时间、不能中断一个正在试图获得锁的线程
• 不够灵活（读写锁更灵活）：加锁和释放的时机单一，单个锁仅有单一的条件（某个对象），可能是不够的
• 无法知道是否成功获取到锁

注意点：

• 1、锁对象不能为空，作用域不宜过大，避免死锁
• 2、如何选择Lock和synchronized关键字呢？

建议：优先用java提供的类，其次用synchronized ，最后当需求有对锁的特殊需求，比如获得是否获得锁，给锁加释放时机的时候 再用Lock

• 3、多线程访问同步方法的各种具体的情况 （见多线程访问同步方法的7种情况）

思考点：

1、多个线程等待同一个synchronized锁的时候，JVM如何选择下一获取锁的的是哪一个线程呢？（内部锁调度机制）
2、synchronized使得同时只有一个线程可以执行，性能较差，有什么办法可以提升性能？ 优化锁定范围，使用别的锁（比如读写锁）
3、想更灵活地控制锁的获取和释放（现在释放锁的时机都被规定死了）怎么办？
4、什么是锁的升级、降级？什么是JVM里的偏斜锁、轻量级锁、重量级锁？

总结：

一句话介绍synchronized

• JVM会自动通过使用Monitor来加锁和解锁，保证了同时只有一个线程可以执行指定代码，从而保证了线程的安全，同时具有可重入性和不可中断性。