在JAVA里，多线程访问共享资源时，因为安全问题，所以引入了Synchronize,我们都知道该锁为非公平锁，重量级锁。
非公平锁，意思就是多线程获取锁是否成功，并非按照线程的优先级来，而是一起去抢，谁抢到谁占有
重量级锁，这里的重量级指的是获取锁的CPU开销较大,为什么开销大，后面会详细说明。
在jdk1.6之前，Synchronize完全属于重量级锁。后来为了提升其性能，出线了锁升级的一堆优化操作
在推出锁升级的优化方案之前，jdk的研发人员专门对锁的使用，以及锁的持有线程者进行了大量的统计，发现在单进程下的子线程中，共享资源的访问并非那么频繁，第二，锁的持有和释放本可以用在更小的粒度上。
基于以上统计发现，我们开始对Synchronize进行优化。这里我们就拿对象锁来说明。
首先我们先来了解一个基本概念，就是Object o = new Object() 。新产生一个对象，在堆内存中的结构包含三部分，对象头，实例数据，对齐。
对象头(mark word)按照CPU的型号分为32和64，目前主流64bit位。为了方便，我们用32位来讲解
对象头大致分为，hashcode,分带年龄，是否偏向，锁标志位，(线程id)偏向锁特有
以下开始来讲解锁升级过程
无锁，最开始我们new出来一个对象，认为没有线程来使用，所以处于无锁态
偏向锁，多线程中，有一个线程如果使用了该对象，那么这个时候这把锁就偏向该线程，同时在对象头里记录下该线程id。如果该线程下次再来持有这把锁时，发现是自己持有的，就不需要再次加锁了。如果这个时候，另外一个线程也想来占有这把锁，那么结果只有两种，要么成功，要么失败。失败后，怎么办，JVM决定把锁升级下
轻量级锁，接上一部，发现锁失败了，那么我就过一会再来尝试下加锁，这个循环的过程，我们称之为自旋，也就是自旋锁。自旋锁，具体就不说了，前面有一篇文章专门描述了。这里会有个问题，要一直拿不到锁怎么办？
自适应自旋，在轻量级锁中，我们用到了自适应。自适应的理解，是建立在锁的持有和释放能够很快完成，那么等待加锁的线程根据获取锁的时间，来自己调整自旋的次数，这样就避免了盲目等待，比如说，B线程发现A线程持有的锁很快就被释放了，那么就让自己多等待一会，否则就不等了。
自旋消耗cpu么？答案是肯定的，因为这个过程主要是通过cpu来完成，如果等待过程中，发现cpu消耗较大，即使自旋能够获得，但是基于整体性能的要求，那么jvm决定进一步升级
重量级锁，上面我们说到，重量级锁很耗费性能，为什么？原因是拿不到锁的线程，直接被park(挂起)，然后放在等待队列里，等候被唤醒。所以这里就牵扯到了线程的切换，而线程的切换势必会在操作系统层面，进行内核和用户态的切换，这种切换肯定是耗费性能的。
综上所述，其实jdk对他的优化，说白了就是先看不加锁有没问题，如果有，那么先加个乐观锁，如果还不行，那么就自旋加锁，如果还不行，才到最后一部重量级锁。相比之前一上来就是重量级锁，性能有很大提升。
