当初的节奏曾经要变成一周一更了吗，不行，相对不行

本次的文章也是根本讲烂了的synchronized，心愿我写的比他人写的更简略易懂，哈哈哈。其实无关多线程的知识点有很多，无论哪门语言都是这样，所以当前会穿插着其余知识点来解说，不然也是太干燥了。

线程不平安

在《Java并发编程实战》中有这么一句话

当多个线程拜访一个类时，如果不必思考这些线程在运行时环境下的调度和交替进行，并且不须要额定的同步及调用方代码不用作其它的协调，这个类的行为依然是正确的，那么成这个类是线程平安的。

艰深一点来说，要想代码线程平安，其实就是保障状态的拜访时不出错的，对象的状态个别状况下指的是数据。然而数据大多数状况都是共享，可变的。

其实在咱们的日常开发中，遇到最多的线程不平安更多的是对某一个变量的批改是否能达到预期，所以上面的例子更多的聚焦于简略的保障变量的批改是平安的。

首先来看下驰名的i++不平安的例子

package concurrent.safe;import java.util.concurrent.CountDownLatch;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;public class SynchronizedDemo {    //一般办法，代码块，静态方法    public static void main(String[] args) throws InterruptedException {        int threadSize = 1000;        ThreadAddExample example = new ThreadAddExample();          //保障主线程完结于各个子线程的前面        final CountDownLatch countDownLatch = new CountDownLatch(threadSize);                //以不举荐的形式启动一个线程池        ExecutorService executorService = Executors.newCachedThreadPool();        for (int i = 0; i < threadSize; i++) {            executorService.execute(() -> {                example.add();                countDownLatch.countDown();            });        }        countDownLatch.await();                //敞开线程池，不然会始终阻塞        executorService.shutdown();        System.out.println(example.get());    }}class ThreadAddExample {    private static int cnt = 0;    public void add() {            cnt++;    }    public int get() {        return cnt;    }}

整个流程是说创立了一个线程池，而后执行了1000个工作，每个工作都是对cnt进行++操作，最初读取cnt。然而没有进行爱护，所以必定存在两个线程同时批改了cnt变量，导致了其中一个线程的批改是有效的，在本例中体现的就是cnt不可能等于1000。

来看下运行后果，能够看到后果如预期，有的时候差的比拟多，有的时候差的比拟少，次要还是看CPU。

用法

针对上述情况就须要应用肯定同步措施来保障施行的后果是对的，本文次要采纳的是synchronized关键字

代码块

在上述类中新增一个办法

public void addWithBlockSync1() {    synchronized (ThreadAddExample.class) {        cnt++;    }}

是以ThreadAddExample这个类作为锁，这样每个线程都要能获取到这个类能力对cnt资源进行批改，最终的后果如下，能够看到无论运行多少次后果都是1000，阐明没有两个及以上的线程在同一时间内批改cnt。

来看下同样是用synchronized突围代码块的另外一个例子

public void addWithBlockSync2() {    synchronized (new ThreadAddExample()) {        cnt++;    }}
留神这里用的锁是线程本人new的一个实例

奇怪了，为什么会线程不平安呢？

第一种状况就像一个房间只有一扇门，每个线程只有拿到同一个钥匙能力进房间，所以线程是平安的。第二种状况是线程本人new了一个实例，相当于给线程造了多个门，线程只须要开本人的那扇门就能进入房间。

那锁对象不是new ThreadAddExample() 而是 this 的状况呢

public void addWithBlockSync3() {    synchronized (this) {        cnt++;    }}

测试后果是能可能保障线程平安，因为锁是this，与下面不同的是整个过程咱们只new了一个对象。

一般办法

还有一种办法是间接在办法体外面增加synchronized关键字

public synchronized void addWithMethodSync() {    cnt++;}

能够发现同样也是能达到线程平安的目标

静态方法

除了上述的办法，还有一种罕用的就是在静态方法中应用关键字

public synchronized static void addWithStaticSync() {    cnt++;}

后果如下：

原理

采纳javap -verbose xxx.class看下字节码文件

同步代码块

能够看到同步代码块无论是轻易new一个对象当锁，还是采纳this单锁，其实次要是由monitorenter和monitorexit来保障了线程的平安。

办法体

可看到办法体是在flags的字段里有个ACC_SYNCHRONIZED标记，两种形式的原理大略就这样，接下来着重讲下monitor。

对象头

简略的说下对象头的组成，然而这个组成如同是没有什么主观的外在表现形式，这里也只是写出了书本上以及博客上少数批准的构造

其余的临时不必管，前期写虚拟机相干的文章的时候还会具体介绍，只有晓得对象由对象头、实例数据和对齐填充组成，而对象头外面有个指向monitor的指针，这个monitor能够看作就是一个重量级锁。

无关monitor的数据结构在jvm的源码，具体来说这里指的是hotspot的源码中，重要的变量正文也写在前面了。

因为每个对象都有对象头，每个对象头都有指向一个monitor的指针，所以每个对象都能作为锁；因为monitor中有个count的字段，所以反编译能够看到是应用了monitorenter和monitorexit，用两次monitorexit查找网上博客是说为了保障异样的状况下也能开释锁 。