茅不易：首先在来接syn锁之前，需要了解我们java中对象头的结构，对象头中包含objectheader，class work以及我们的markword，markword主要从初hashcode 分代年龄等信息，首先对于原始的syn锁，我们也叫他重量级锁，在对对象加锁的过程中，会调用native方法跟操作系统申请一个监视器对象，然后将二者关联起来，在关联的过程中，会讲对象头中的markword交给monitor管理，然后markword存储对应monitor的地址，方便我们后续加锁的时候寻址，syn锁是基于monitor实现的，他里面包含owner来存储thread对象，为null则表示当前没有线程获取锁，不为null则表示已经有人获取锁了，会进入到entryset中排队等待，当然如果获取锁的线程由于一些i蛀牙UN没有准备好，进入wait，会释放锁然后进入到waitset中等待，当其他持有锁的线程进行notify后会将waitset中线程放入到entryset中等待，这个set是无序集合，所以不确定哪个线程被调度后持所锁，所以syn是非公平锁，由于加锁每次都需要跟操作系统申请monitor，这个操作sh比较重的，所以jvm底层做了很多优化，比如：重量级锁的自旋，没获取到锁在重试几次，减少线程从运行变更为阻塞状态的上下文切换，还有就是轻量级锁，使用场景是不存咋锁竞争的情况，他会在当前thread staack中创建一个lock record记录，然后将lock record 和 对象头中的markword进行 cas交换，如果当前线程发生了锁重入，发现markword里面存的lockrecrd是当前线程会将所重入的lock 记录 方null，用来记录所重入的次数，释放锁则移除一个lock rerecord，后续如果发生锁竞争，还是会走cas操作尝试交换信息，结果发现已经被交换完了，说明发生了锁竞争就会走锁锁膨胀逻辑，变成重量级锁，然后本身持有轻量级锁的线程会走重量级锁的释放锁的流程.......当然如果不存在锁竞争的情况下，频繁发生自旋，每次都要cas操作，效率也比较低，底层做了优化，干脆直接把线程id刻到markword里面，这也就是偏向锁.......