先看代码

猜猜输出是多少 10000? 但是经过多次尝试都是一个小于10000的值

再来看另一个操作

结果输出了 10000

那到底为什么会产生这样的差异呢？

i++ 首先 i++这部在代码层面看来只是一步操作但对于应用程序来说至少需要两步操作先读出 i的值然后在进行对这个i的值进行+1操作。可是这又怎么了呢？单线程情况下这是没问题的有兴趣的朋友可以试一下。但是在多线程情况下一切就不在那么美妙了。那我们模拟一下多线程极限情况

线程 a --> 读取i(0)
线程 b --> 读取i(0)
线程 a --> 写入i(1) i=0+1
线程 b --> 写入i(1) i=0+1

正确的结果是 i=2而现在的结果只能得到 i=1 。在多线程环境中访问公共资源时由于线程切换导致操作不符合预期的情况这也就是通常所说的线程不安全。你说的我都懂！可是怎么做呢？

解决问题必须要回归问题，首先可以从多线程切换的思路下手，或者从操作不符合预期的思路下手。这就引入了两种不同的解决方案。

悲观锁解决方案:加锁使访问资源时线程不允许切换。
乐观锁解决方案:cas操作。

悲观方案代表人物(synchronized lock)

synchronized 的使用场景

修饰实例方法，为当前实例加锁，进入同步方法前要获得当前实例的锁。
修饰静态方法，为当前类对象加锁，进入同步方法前要获得当前类对象的锁。
修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码块前要获得给定对象的锁。

虽然看起来时三种不同的场景，不管隐式或者显式加锁的对象不同而已。可以归纳为是synchronized(obj)这也是锁资源的边界。synchronized语义是只允许一条线程能进入锁的边界，当多个线程到达边界时只能排队执行。也就避免了上下文切换。

你说的很对，但是你说的这个东西我奶奶都知道,有没有那种能叫出名字很厉害的招式。

monitorenter moniterexit

反编译以上代码(javap 命令)

大体可以理解意思是在i++之前加了一个monitorenter在i++之后加了一个moniterexit 这两个命令形成了资源边界.

不是我奶奶很强，但巧了上面的东西她还知道。你秀呀你倒是继续秀呀！

monitorenter 怎么实现边界的呢？你奶奶听过上面的东西一定也听说过锁优化。无锁偏向锁轻量级锁重锁先看一张我找到的图片详细的介绍了锁的升级过程。

图是好图,就是谁知道你是不是个大发明家呢。

那我们继续看，点开hotspot源码。

UseBiasedLocking这个参数是否开启偏向锁开启偏向锁的获取。

偏向锁的获取

偏向锁的获取由BiasedLocking::revoke_and_rebias方法实现实现逻辑如下：

1:通过markOop mark = obj->mark()获取对象的markOop数据mark，即对象头的Mark Word；
2:判断mark是否为可偏向状态，即mark的偏向锁标志位为 1，锁标志位为 01；
3:判断mark中JavaThread的状态：如果为空，则进入步骤（4）；如果指向当前线程，则执行同步代码块；如果指向其它线程，进入步骤（5）；
4:通过CAS原子指令设置mark中JavaThread为当前线程ID，如果执行CAS成功，则执行同步代码块，否则进入步骤（5）；
5:如果执行CAS失败，表示当前存在多个线程竞争锁，当达到全局安全点（safepoint），获得偏向锁的线程被挂起，撤销偏向锁，并升级为轻量级，升级完成后被阻塞在安全点的线程继续执行同步代码块；轻量级锁的获取

当关闭偏向锁功能，或多个线程竞争偏向锁导致偏向锁升级为轻量级锁，会尝试获取轻量级锁，其入口位于ObjectSynchronizer::slow_enter

1:markOop mark = obj->mark()方法获取对象的markOop数据mark；
2:mark->is_neutral()方法判断mark是否为无锁状态：mark的偏向锁标志位为 0，锁标志位为 01；
3:如果mark处于无锁状态，则进入步骤（4），否则执行步骤（6）；
4:把mark保存到BasicLock对象的_displaced_header字段；
5 通过CAS尝试将Mark Word更新为指向BasicLock对象的指针，如果更新成功，表示竞争到锁，则执行同步代码，否则执行步骤（6）；
6:如果当前mark处于加锁状态，且mark中的ptr指针指向当前线程的栈帧，则执行同步代码，否则说明有多个线程竞争轻量级锁，轻量级锁需要膨胀升级为重量级锁；

假设线程A和B同时执行到临界区if (mark->is_neutral())：

1、线程AB都把Mark Word复制到各自的_displaced_header字段，该数据保存在线程的栈帧上，是线程私有的；
2、Atomic::cmpxchg_ptr原子操作保证只有一个线程可以把指向栈帧的指针复制到Mark Word，假设此时线程A执行成功，并返回继续执行同步代码块；
3、线程B执行失败，退出临界区，通过ObjectSynchronizer::inflate方法开始膨胀锁；

重量级锁

重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。锁膨胀过程锁的膨胀过程通过ObjectSynchronizer::inflate函数实现

1:整个膨胀过程在自旋下完成；
2:mark->has_monitor()方法判断当前是否为重量级锁，即Mark Word的锁标识位为 10，如果当前状态为重量级锁，执行步骤（3），否则执行步骤（4）；
3:mark->monitor()方法获取指向ObjectMonitor的指针，并返回，说明膨胀过程已经完成；
4:如果当前锁处于膨胀中，说明该锁正在被其它线程执行膨胀操作，则当前线程就进行自旋等待锁膨胀完成，这里需要注意一点，虽然是自旋操作，但不会一直占用cpu资源，每隔一段时间会通过os::NakedYield方法放弃cpu资源，或通过park方法挂起；如果其他线程完成锁的膨胀操作，则退出自旋并返回；
5: 如果当前是轻量级锁状态，即锁标识位为 00，膨胀过程如下

1:通过omAlloc方法，获取一个可用的ObjectMonitor monitor，并重置monitor数据；
2:通过CAS尝试将Mark Word设置为markOopDesc:INFLATING，标识当前锁正在膨胀中，如果CAS失败，说明同一时刻其它线程已经将Mark Word设置为markOopDesc:INFLATING，当前线程进行自旋等待膨胀完成；
3:如果CAS成功，设置monitor的各个字段：_header、_owner和_object等，并返回；

当锁膨胀完成并返回对应的monitor时，并不表示该线程竞争到了锁，真正的锁竞争发生在ObjectMonitor::enter方法中。

1、通过CAS尝试把monitor的_owner字段设置为当前线程；
2、如果设置之前的_owner指向当前线程，说明当前线程再次进入monitor，即重入锁，执行_recursions ++ ，记录重入的次数；
3、如果之前的_owner指向的地址在当前线程中，这种描述有点拗口，换一种说法：之前_owner指向的BasicLock在当前线程栈上，说明当前线程是第一次进入该monitor，设置_recursions为1，_owner为当前线程，该线程成功获得锁并返回；
4、如果获取锁失败，则等待锁的释放；

monitor竞争失败的线程，通过自旋执行ObjectMonitor::EnterI方法等待锁的释放，EnterI方法的部分逻辑实现如下

1、当前线程被封装成ObjectWaiter对象node，状态设置成ObjectWaiter::TS_CXQ；
2、在for循环中，通过CAS把node节点push到_cxq列表中，同一时刻可能有多个线程把自己的node节点push到_cxq列表中；
3、node节点push到_cxq列表之后，通过自旋尝试获取锁，如果还是没有获取到锁，则通过park将当前线程挂起，等待被唤醒，代码如下：

4、当该线程被唤醒时，会从挂起的点继续执行，通过ObjectMonitor::TryLock尝试获取锁，

上面大概是synchronized的基本流程。

你说的这些东西都是啥的我看不见的，我看见我才信。

好那只能祭出一些少儿不宜的东西了 jol。

public class ObjectView {
 public static void main(String[] args) throws InterruptedException {
    Thread.sleep(10000L);
    Object o = new Object();
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
    for (int i = 0; i < 2; i++) {
       new Thread(()->{
            synchronized (o){
                System.out.println(ClassLayout.parseInstance(o).toPrintable());
                try {
                   Thread.sleep(20L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
       System.out.println(ClassLayout.parseInstance(o).toPrintable());
       Thread.sleep(30);

    }

}}

上面代码你可以根据竞争做一些修改观察一下输出的不同。

啥？你奶奶这些都知道！

欢迎留言或者斗图

从i++说起刨根问底synchronized

悲观方案代表人物(synchronized lock)