dog li 李二狗
synchronized sun公司在1.6版本之前性能是非常低的，李二狗发现好慢，他就设计了一个AQS框架，用java代码封装，性能比synchronized高好几倍，sun公司就不干了，我自己团队的东西还没二狗的厉害，然后就重新设计优化了synchronized。
synchronized1.6版本 和 >=1.6升级后版本图：
1.6版本之前，性能是非常低的，在多线程情况下，临界资源被线程访问时，会直接加重量级锁，这对性能非常有影响，重量级锁的话会导致cpu从用户态切换到内核态，而从1.6版本开始，sun公司团队就对synchronized 进行了优化，发现并不是所有的资源都是竞争非常激烈的，如果直接上重量级锁，性能非常低，所以就有了锁的升级优化，什么样的情况下对应什么样的锁，竞争激烈就重量级，竞争不激烈就加轻量级锁，优化后的锁分为三个等级 ：偏向锁、轻量级锁、重量级锁。
ReentrantLock AQS 框架由dog li 设计
synchronized 也是有可重入性。但是AQS的公平性synchronized 是没有的。
一、synchronized出现解决的问题
synchronized 和 lock 关键字都是可以解决并发问题，synchroized 关键字只不过用的多一点，在多线程中，临界资源经常被多个线程同时访问，会有很大的问题，所以出现了同步机制，保证资源只能被一个线程所操作；
二、原理详解
1）首先从编译层面来看：
synchronized关键字会被字节码编译器编译成 monitorenter monitorexit 分别在synchronized代码块前后；
2）加锁方式
1.方法上添加synchronized
会锁住当前对象 （this）
2.代码块逻辑添加synchronized
会锁住括号里面的对象
3.类方法添加synchronized
会锁住当前类的.class对象
三、Monitor监视器锁
它是一个配合synchronized一块使用，多个线程访问资源的一个工具，每个对象都会有一个monitor对象，保存的是该对象的的等待线程，和处于block状态的线程等等信息，底层是由c++实现，源码可以参考hotSport源码ObjectMonitor.hpp中的代码：
ObjectMonitor() { _header = NULL; _count = 0; // 记录个数 _waiters = 0, _recursions = 0; _object = NULL; _owner = NULL; _WaitSet = NULL; // 处于wait状态的线程，会被加入到_WaitSet _WaitSetLock = 0 ; _Responsible = NULL ; _succ = NULL ; _cxq = NULL ; FreeNext = NULL ; _EntryList = NULL ; // 处于等待锁block状态的线程，会被加入到该列表 _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ; }
Synchronized在JVM里的实现都是 基于进入和退出Monitor对象来实现方法同步和代码块同步，虽然具体实现细节不一样，但是都可以通过成对的MonitorEnter和MonitorExit指令来实现。
四、对象的内存结构
- 对象头 header
- Mark Word：
32位操作里，Mark Word内存大小为32bit，它占用2个机器码，2个机器码=8字节（byte），8个byte = 32 bit，而在64位系统中 1个字节= 8byte ，也就是64bit大小；
主要存放的信息是对象锁状态、是否偏向锁、gc分代年龄、当前持有线程的id，hashcode、偏向锁的线程的id、偏向的时间戳等等。
在32位的HotSpot虚拟机 中对象未被锁定的状态下，Mark Word的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标志位，1Bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）
不同锁状态下Mark Word 的内存结构图：
- 元数据指针
存放的是元数据的内存地址 kclass point 指向的是c#用来描述java类的c#对象。参考自 https://blog.csdn.net/qq_26222859/article/details/81335542
- 数组的长度
- 实例数据
存放类型属性信息数据，报告父类的属性信息；
- 对象填充位
因为jvm规定对象的起止地址必须为8的整数倍；填充数据不是必须存在的，仅仅是为了字节对齐；
五、锁升级过程
锁的状态有四种，从低到高排序：无锁状态、偏向锁、轻量级锁、重量级锁；
在jdk1.6版本之后才优化的这些锁状态，1.6版本之前直接有线程获取锁失败直接回升级成重量级锁，而1.6版本及以后，在多线程程序中，默认无锁状态，如果有线程获取对象后，会升级为偏向锁，记录偏向锁的线程id，以及修改monitor中的状态信息，count数量，当前持有锁的线程id，当有另一个线程接着获取对象锁失败后，锁会升级成轻量级锁，不会直接升级为重量级锁，因为升级重量级锁会导致线程的切换用户态到内核态，这是非常消耗性能的，这也是一个非常大的优化，当有多个线程同时获取锁对象时（目前状态为轻量级锁），那么锁的状态会自旋一段时间，这也是一个小小的优化，就认为他一会就会释放锁，当自旋一段时间后，还没有释放，会直接升级成重量级锁；
