背景 在 JDK1.5 之前，面对 Java 并发问题， synchronized 是一招鲜的解决方案： 1. 普通同步方法，锁上当前实例对象 2. 静态同步方法，锁上当前类 Class 对象 3. 同步块，锁上括号里面配置的对象 拿同步块来举例: 1 2 3 4 5 public void test(){ synchronized (object) { i++; } } 经过 javap -v 编译后的指令如下： monitorenter 指令是在编译后插入到同步代码块的开始位置；monitorexit是插入到方法结束和异常的位置(实际隐藏了try-

写在前面 上一篇文章原子性问题的宏观理解 带领大家了解了锁和资源的模型，有了这篇文章的铺垫，相信理解这一篇文章就非常轻松了 当我们要保护单个资源并对其进行修改其实很简单，只需按照下图分三步走 1. 创建受保护资源 R 的锁 2. 加锁进入临界区 3. 解锁走出临界区 上图的关键是「R1 的锁保护 R1」的指向关系是否正确 如果都是保护单个资源这样简单，程序猿的世界该有多美好，可惜并不是，通常我们需要保护多个资源 保护多个资源 保护多个没有关系的资源 如果多个资源没有关系，那就是保护一个资源模型的复制，同样非常简单，且看下图: 比如现实中银行取款和修改密码操作。 银行取

上一篇文章 可见性有序性，Happens-before来搞定，解决了并发三大问题中的两个，今天我们就聊聊如何解决原子性问题 原子性问题的源头就是 线程切换，但在多核 CPU 的大背景下，不允许线程切换是不可能的，正所谓「魔高一尺，道高一丈」，新规矩来了: 互斥: 同一时刻只有一个线程执行 实际上，上面这句话的意思是: 对共享变量的修改是互斥的，也就是说线程 A 修改共享变量时其他线程不能修改，这就不存在操作被打断的问题了，那么如何实现互斥呢？ 锁 对并发有所了解的小伙伴马上就能想到 锁 这个概念，并且你的第一反应很可能就是使用 synchronized，这里列出来你常见的 syn