children: ["JVM/Runtime-Data-Areas", "JVM/OOM"]

"JUC/CountDownLatch、CyclicBarrier、Semaphore"

Subproject commit 008a48f7972aba21b62f8886e09a4041e5c79eee

每个初学多线程的 Javaer，在遇到这种多线程问题的时候，肯定会先想到 Synchronized，我们把它称为“同步”，

3. 有序性：有效解决重排序问题，即 “一个unlock操作先行发生(happen-before)于后面对同一个锁的lock操作”；

synchronized 的用法可以从两个维度上面分类：

synchronized 可以修饰方法和代码块

- 修饰代码块

- synchronized(this|object) {}

- synchronized(类.class) {}

- 修饰方法

- 修饰非静态方法

- 修饰静态方法

- 获取对象锁

- synchronized(this|object) {}

- 修饰非静态方法

- 获取类锁

- synchronized(类.class) {}

- 修饰静态方法

如图，synchronized可以用在**方法**上也可以使用在**代码块**中，其中方法是实例方法和静态方法分别锁的是该类的实例对象和该类的对象。而使用在代码块中也可以分为三种，具体的可以看上面的表格。这里的需要注意的是：**如果锁的是类对象的话，尽管new多个实例对象，但他们仍然是属于同一个类依然会被锁住，即线程之间保证同步关系**。

从语法上讲，Synchronized 可以把任何一个非null对象作为"锁"，在 HotSpot JVM 实现中，**锁有个专门的名字：对象监视器（Object Monitor）**。

Synchronized 概括来说其实总共有三种用法：

3. 当 synchronized 作用在某一个对象实例时，监视器锁（monitor）便是括号括起来的对象实例；

| 作用范围 | 锁对象 |

| :--------- | :----------------------------------------------------------- |

| 非静态方法 | 当前对象 => this |

| 静态方法 | 类对象 => SynchronizedSample.class （一切皆对象，这个是类对象） |

| 代码块 | 指定对象 => lock |

注意，synchronized 内置锁是一种对象锁（锁的是对象而非引用变量），**作用粒度是对象 ，可以用来实现对 临界资源的同步互斥访问 ，是可重入的。其可重入最大的作用是避免死锁**，如：

上面的代码中有一个同步代码块，锁住的是类对象，并且还有一个静态方法，锁住的依然是该类的类对象。编译之后，切换到 SynchronizedDemo.class 的同级目录之后，然后用**javap -v SynchronizedDemo.class**查看字节码文件：

如图，上面用黄色高亮的部分就是需要注意的部分了，这也是添Synchronized关键字之后独有的。执行同步代码块后首先要先执行**monitorenter**指令，退出的时候**monitorexit**指令。通过分析之后可以看出，使用Synchronized进行同步，其关键就是必须要对对象的监视器monitor进行获取，当线程获取monitor后才能继续往下执行，否则就只能等待。而这个获取的过程是**互斥**的，即同一时刻只有一个线程能够获取到monitor。上面的demo中在执行完同步代码块之后紧接着再会去执行一个静态同步方法，而这个方法锁的对象依然就这个类对象，那么这个正在执行的线程还需要获取该锁吗？答案是不必的，从上图中就可以看出来，执行静态同步方法的时候就只有一条monitorexit指令，并没有monitorenter获取锁的指令。这就是**锁的重入性**，即在同一锁程中，线程不需要再次获取同一把锁。Synchronized先天具有重入性。**每个对象拥有一个计数器，当线程获取该对象锁后，计数器就会加一，释放锁后就会将计数器减一**

synchronized关键字不能继承。

对于父类中的 synchronized 修饰方法，子类在覆盖该方法时，默认情况下不是同步的，必须显示的使用 synchronized 关键字修饰才行。

在定义接口方法时不能使用synchronized关键字。

构造方法不能使用synchronized关键字，但可以使用synchronized代码块来进行同步。

数据同步需要依赖锁，那锁的同步又依赖谁？**synchronized给出的答案是在软件层面依赖JVM，而j.u.c.Lock给出的答案是在硬件层面依赖特殊的CPU指令。**

通过上面两段描述，我们应该能很清楚的看出Synchronized的实现原理，**Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。**

从编译的结果来看，方法的同步并没有通过指令 `monitorenter` 和 `monitorexit` 来完成（理论上其实也可以通过这两条指令来实现），不过相对于普通方法，其常量池中多了 `ACC_SYNCHRONIZED` 标示符。JVM就是根据该标示符来实现方法的同步的：

两种同步方式本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。两个指令的执行是JVM通过调用操作系统的互斥原语mutex来实现，被阻塞的线程会被挂起、等待重新调度，会导致“用户态和内核态”两个态之间来回切换，对性能有较大影响。