Synchronized的作用

  1. 原子性：确保线程互斥的访问同步代码；
    2. 可见性：保证共享变量的修改能够及时可见，其实是通过Java内存模型中的 “对一个变量unlock操作之前，必须要同步到主内存中；如果对一个变量进行lock操作，则将会清空工作内存中此变量的值，在执行引擎使用此变量前，需要重新从主内存中load操作或assign操作初始化变量值” 来保证的；
    3. 有序性：有效解决重排序问题，即 “一个unlock操作先行发生(happen-before)于后面对同一个锁的lock操作”；

    Synchronized用法

  2. 当Synchronized作用在实例方法时，监视器锁（monitor）便是对象实例（this）；
    2. 当Synchronized作用在静态方法时，监视器锁（monitor）便是对象的Class实例，因为Class数据存在于永久代，因此静态方法锁相当于该类的一个全局锁；
    3. 当Synchronized作用在某一个对象实例时，监视器锁（monitor）便是括号括起来的对象实例；
    注意，synchronized 内置锁 是一种 对象锁（锁的是对象而非引用变量），作用粒度是对象 ，可以用来实现对 临界资源的同步互斥访问 ，是 可重入 的。其可重入最大的作用是避免死锁。
    子类同步方法调用了父类同步方法，如没有可重入的特性，则会发生死锁；

    Synchronized同步原理

    JVM中的同步是基于进入与退出监视器对象（管程对象）（Monitor）来实现的，每个对象实例都会有一个Monitor对象，Monitor对象会和Java对象一同创建并销毁。Monitor对象是由C++来实现的。

    Synchronized关键字修饰对象

    字节码层面上是通过monitorenter与monitorexit指令来实现的锁的获取与释放动作。
    当线程进入到monitorenter指令后，线程将会持有Monitor对象，
    退出monitorenter指令后，线程将会释放Monitor对象
    1. monitorenter：每个对象都是一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：
    a. 如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者；
    b. 如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1；
    c. 如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权；
    2. monitorexit：执行monitorexit的线程必须是objectref所对应的monitor的所有者。指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。
    monitorexit指令出现了两次，第1次为同步正常退出释放锁；第2次为发生异步退出释放锁；

    Synchronized关键字修饰方法

    对于Synchronized关键字修饰方法来说，并没有出现monitorenter与monitorexit指令，而是出现了一个ACC_SYNCHRONIZED标志。
    JVM使用了ACC_SYNCHRONIZED访问标志来区分一个方法是否为同步方法.当方法被调用时，调用指令会检查该方法是否拥有ACC_SYNCHRONIZED标志，
    如果有，那么执行线程将会先持有方法所在对象的Monitor对象，然后再去执行方法体；在该方法执行期间，其他任何线程均无法再获取到这个Monitor对象，
    当线程执行完该方法后，它会释放掉这个Monitor对象。

    Java对象头

    在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。
    image.png
    结构图
    实例数据：存放类的属性数据信息，包括父类的属性信息
    对齐填充：由于虚拟机要求 对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐
    对象头：Java对象头一般占有2个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit，在64位虚拟机中，1个机器码是8个字节，也就是64bit），但是 如果对象是数组类型，则需要3个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。

Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Class Pointer（类型指针）。
Class Pointer是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
Mark Word用于存储对象自身的运行时数据，它是实现轻量级锁和偏向锁的关键。
image.png
Mark Word用于存储对象自身的运行时数据，如：哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等。
image.png
image.png
对象头的最后两位存储了锁的标志位，01是初始状态，未加锁，其对象头里存储的是对象本身的哈希码，随着锁级别的不同，对象头里会存储不同的内容。偏向锁存储的是当前占用此对象的线程ID；而轻量级则存储指向线程栈中锁记录的指针。从这里我们可以看到，“锁”这个东西，可能是个锁记录+对象头里的引用指针（判断线程是否拥有锁时将线程的锁记录地址和对象头里的指针地址比较)，也可能是对象头里的线程ID（判断线程是否拥有锁时将线程的ID和对象头里存储的线程ID比较）。
监视器（Monitor）
Monitor是由ObjectMonitor实现的。
image.png
ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表（ 每个等待锁的线程都会被封装成ObjectWaiter对象 ），_owner指向持有ObjectMonitor对象的线程。
1. 当多个线程同时访问一段同步代码时，这些线程会被放到一个EntryList集合中，处于阻塞状态的线程都会被放到该列表当中。接下来，当线程获取到对象的Monitor时，进入 _Owner区域并把monitor中的owner变量设置为当前线程，同时monitor中的计数器count加1，Monitor是依赖于底层操作系统的mutex lock来实现互斥的，线程获取mutex成功，则会持有该mutex，这时其他线程就无法再获取到该mutex。
2. 若线程调用 wait() 方法，将释放当前持有的monitor（释放掉所持有的mutex），owner变量恢复为null，count自减1，同时该线程进入 WaitSet集合中等待下一次被其他线程调用notify/notifyAll唤醒；
3. 若当前线程执行完毕，也将释放monitor锁（释放掉所持有的mutex）并复位count的值，以便其他线程进入获取monitor(锁)；
Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。
总结一下：通过对象互斥锁的概念来保证共享数据操作的完整性。每个对象都对应于一个可称为『互斥锁』的标记，这个标记用于保证在任何时刻，只能有一个线程访问该对象。那些处于EntryList与WaitSet中的线程均处于阻塞状态，阻塞操作是由操作系统来完成的，在linux下是通过pthread_mutex_lock函数实现的。线程被阻塞后便会进入到内核调度状态，这会导致系统在用户态与内核态之间来回切换，严重影响锁的性能。
解决用户态与内核态之间来回切换频繁问题的办法便是自旋（Spin）。
其原理是：当发生对Monitor的争用时，若Owner能够在很短的时间内释放掉锁，则那些正在争用的线程就可以稍微等待一下（即所谓的自旋），在Owner线程释放锁之后，争用线程可能会立刻获取到锁，从而避免了系统阻塞。不过，当Owner运行的时间超过了临界值后，争用线程自旋一段时间后依然无法获取到锁，这时争用线程则会停止自旋而进入到阻塞状态。所以总体的思想是：先自旋，不成功再进行阻塞，尽量降低阻塞的可能性，这对那些执行时间很短的代码块来说有极大的性能提升。显然，自旋在多处理器（多核心）上才有意义。

锁优化

在 JDK 1.6 中默认是开启偏向锁和轻量级锁的，可以通过-XX:-UseBiasedLocking来禁用偏向锁。
无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁

偏向锁

为了在没有多线程竞争的情况下尽量减少不必要的轻量级锁执行路径。因为轻量级锁的加锁解锁操作是需要依赖多次CAS原子指令的，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗也必须小于节省下来的CAS原子指令的性能消耗）。
1. 检测Mark Word是否为可偏向状态，即是否为偏向锁1，锁标识位为01；
2. 若为可偏向状态，则测试线程ID是否为当前线程ID，如果是，则执行步骤（5），否则执行步骤（3）；
3。 如果测试线程ID不为当前线程ID，则通过CAS操作竞争锁，竞争成功，则将Mark Word的线程ID替换为当前线程ID，否则执行线程（4）；
4. 通过CAS竞争锁失败，证明当前存在多线程竞争情况，当到达全局安全点，获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码块；
5. 执行同步代码块；

轻量级锁

也是JDK1.6中引入的，轻量级，是相对于使用互斥量的重量级锁来说的。线程发生竞争锁的时候，不会直接进入阻塞状态，而是先尝试做CAS修改操作，进入自旋，这个过程避免了线程状态切换的开销，不过要消耗cpu资源。
详细过程是：
1. 线程尝试进入同步代码块，如果锁对象未被锁定，在当前线程对应的栈帧中，建立锁记录的空间，用于存储锁对象Mark Word的拷贝。然后JVM用CAS方式尝试将锁对象的MarkWord内容替换为指向前述“锁记录”的指针。
2. 如果成功，当前线程则持有了锁，处于轻量级锁定状态。
3. 如果失败，则表示这时可能会有多个线程同时在尝试争抢该对象的锁，进入自旋尝试获取轻量级锁，若自旋结束时仍未获得锁，轻量级锁就要膨胀为重量级锁。

重量级锁

也就是我们使用的互斥量方式实现的锁，当存在多线程竞争时，只要没拿到锁，就会进入阻塞状态，主要消耗是在阻塞-唤起-阻塞-唤起的线程状态切换上。 线程最终从用户态进入到了内核态。

自旋锁

若自旋失败（依然无法获取到锁），那么锁就会转化为重量级锁，在这种情况下，无法获取到锁的线程都会进入到Monitor（即内核态）自旋最大的一个特点就是避免了线程从用户态进入到内核态。
适应性自旋锁：线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。反之，如果对于某个锁，很少有自旋能够成功，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。

互斥锁属性

  1. PTHREAD_MUTEX_TIMED_NP：这是缺省值，也就是普通锁。当一个线程加锁以后，其余请求锁的线程将会形成一个等待队列，并且在解锁后按照优先级获取到锁。这种策略可以确保资源分配的公平性。
    2. PTHREAD_MUTEX_RECURSIVE_NP：嵌套锁。允许一个线程对同一个锁成功获取多次，并通过unlock解锁。如果是不同线程请求，则在加锁线程解锁时重新进行竞争。
    3. PTHREAD_MUTEX_ERRORCHECK_NP：检错锁。如果一个线程请求同一个锁，则返回EDEADLK，否则与PTHREAD_MUTEX_TIMED_NP类型动作相同，这样就保证了当不允许多次加锁时不会出现最简单情况下的死锁。
    4. PTHREAD_MUTEX_ADAPTIVE_NP：适应锁，动作最简单的锁类型，仅仅等待解锁后重新竞争。

    编译器对于锁的优化措施

    锁消除技术
    JIT编译器（Just In Time编译器）可以在动态编译同步代码时，使用一种叫做逃逸分析的技术，来通过该项技术判别程序中所使用的锁对象是否只被一个线程所使用，而没有散布到其他线程当中；如果情况就是这样的话，那么JIT编译器在编译这个同步代码时就不会生成synchronized关键字所标识的锁的申请与释放机器码，从而消除了锁的使用流程。
    锁粗化
    JIT编译器在执行动态编译时，若发现前后相邻的synchronized块使用的是同一个锁对象，那么它就会把这几个synchronized块给合并为一个较大的同步块，这样做的好处在于线程在执行这些代码时，就无需频繁申请与释放锁了，从而达到申请与释放锁一次，就可以执行完全部的同步代码块，从而提升了性能。

    关于Lock与synchronized关键字在锁的处理上的重要差别

  2. 锁的获取方式：前者是通过程序代码的方式由开发者手工获取，后者是通过JVM来获取（无需开发者干预）
    2. 具体实现方式：前者是通过Java代码的方式来实现，后者是通过JVM底层来实现 （无需开发者关注）
    3. 锁的释放方式：前者务必通过unlock()方法在finally块中手工释放，后者是通过JVM来释放（无需开发者关注）
    4. 锁的具体类型：前者提供了多种，如公平锁、非公平锁，后者与前者均提供了可重入锁