Java中最基本的互斥同步手段便是synchronized，详细如何实现的互斥同步请连续往下看。
btw，除了synchronized，还有其余一种实现同步的办法，那便是java.util.concurrent包中的重入锁ReentrantLock，详细细节就不细说了，它和synchronized用法险些一样。只是synchronized是原生语法，而ReentrantLock是JDK供应的API层面的互斥锁。
非壅塞同步互斥同步紧张同步壅塞线程来担保线程安全，因此也被称为壅塞同步。它认为只要不去做精确的同步办法（例如加锁），那就一定会涌现问题，无论共享数据是否会涌现竞争（悲观锁）。
回来随着硬件指令集的发展，我们有了其余一种选择：前辈行操作，如果没有其他线程争用，那操作就成功了；如果有其他线程争用，产生了冲突，那就再采纳其他的补偿方法（最常见的补偿方法便是不断地重试，直到成功为止）。这种乐不雅观的并发策略的许多实现都不须要把线程挂起，以是这种同步办法成为非壅塞同步。
无需同步的线程安全方案要担保线程安全，并不一定就要进行同步，两者并没有因果关系。如果一个方法本来就不涉及共享数据，那它自然无需任何同步手段去担保精确性，因此会有一些代码天生线程安全。比如可重入代码（Reentrant Code）和线程本地存储（Thread Local Storage）等。
JDK中的synchronized改进在 JDK1.5 之前，Java 是依赖 Synchronized 关键字实现锁功能来做到线程安全。Synchronized 是 JVM 实现的一种内置锁，锁的获取和开释是由 JVM 隐式实现。
到了 JDK1.5 版本，java.util.concurrent包中新增了 Lock 接口来实现锁功能，它供应了与 Synchronized 关键字类似的同步功能，只是在利用时须要显示获取和开释锁。前边我们提到过，Lock 同步锁是基于 Java 实现的，而 Synchronized 是基于底层操作系统的 Mutex Lock 实现的，每次获取和开释锁操作都会带来用户态和内核态的切换，从而增加系统性能开销。因此，在锁竞争激烈的情形下，Synchronized 同步锁在性能上就表现得非常糟糕，它也常被大家称为重量级锁。特殊是在单个线程重复申请锁的情形下，JDK1.5 版本的 Synchronized 锁性能要比 Lock 的性能差很多。例如，在 Dubbo 基于 Netty 实现的通信中，消费端向做事端通信之后，由于吸收返回是异步，以是须要一个线程轮询监听返复书息。而在吸收时，就须要用到锁来确保 request session 的原子性。如果我们这里利用 Synchronized 同步锁，那么每当同一个线程要求锁资源时，都会发生一次用户态和内核态的切换。
到了 JDK1.6 版本之后，Java 对 Synchronized 同步锁做了充分的优化，乃至在某些场景下，它的性能已经超越了 Lock 同步锁。
synchronized利用办法Java中万物皆工具，而每一个工具都可以加锁，这是synchronized担保线程安全的根本。
对付同步方法，锁是当前实例工具，即this，对该类其他实例工具无影响。对付静态同步方法，锁是当前工具的 Class 工具， 影响其他该类的实例化工具。对付同步方法块，锁是 synchronized括号里配置的工具。也便是说，我们可以利用synchronized润色类，类中的方法或者方法块。如下面的代码，分别对应上述三种环境。
public class synchronizedTest implements Runnable { static synchronizedTest instance=new synchronizedTest(); public void run() { synchronized(instance){ //同步代码块,对应文章中第3点 // } } void synchronized method1() {} //类中的同步方法 对应文章中第1点 void static synchronized method2() {} ////类中静态同步方法 对应文章中第2点}同步方法块
当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出非常时必须开释锁。那么锁存在哪里呢？锁里面会存储什么信息呢？我们先来看一段代码以及它的字节码（我这里用的Idea的jclasslib插件）。
package techgo.blog;public class SynchronizedTest { private int i = 0; public void fun() { synchronized (this) { i ++; } }}
我们看到monitorenter和monitorexit，之后查阅虚拟机字节码指令表，我们知道这两个字节码操作分别表示得到和开释工具的锁。进入 monitorenter 指令后，线程将持有 Monitor 工具，退出 monitorenter 指令后，线程将开释该 Monitor 工具。以上这是同步方法块的实现办法。
同步方法对付同步方法来说，如果去查看其字节码，我们会看不到这两个指令，由于同步方法依赖的是方法润色符上的ACC_SYNCHRONIZED来实现的:
public synchronized void fun1() { }
当方法调用时，调用指令将会检讨该方法是否被设置 ACC_SYNCHRONIZED 访问标志。如果设置了该标志，实行线程将先持有 Monitor 工具，然后再实行方法。在该方法运行期间，其它线程将无法获取到该 Mointor 工具，当方法实行完成后，再开释该 Monitor 工具。
synchronized锁的实现synchronized的工具锁，其指针指向的是一个monitor工具（由C++实现）的起始地址。每个工具实例都会有一个 monitor。个中monitor可以与工具一起创建、销毁；亦或者当线程试图获取工具锁时自动天生。须要把稳的是monitor不是Java特有的观点，想理解更多monitor的详细先容可以查看这篇文章。
在HotSpot虚拟机中，终极采取ObjectMonitor类实现monitor。
openjdk\hotspot\src\share\vm\runtime\objectMonitor.hpp源码如下：
ObjectMonitor() { _count = 0; _owner = NULL;//指向得到ObjectMonitor工具的线程或根本锁 _EntryList = NULL ;//处于等待锁block状态的线程，会被加入到entry set； _WaitSet = NULL;//处于wait状态的线程，会被加入到wait set； _WaitSetLock = 0 ; _header = NULL;//markOop工具头 _waiters = 0,//等待线程数 _recursions = 0;//重入次数 _object = NULL;//监视器锁寄生的工具。锁不是平白涌现的，而是寄托存储于工具中。 _Responsible = NULL ; _succ = NULL ; _cxq = NULL ; FreeNext = NULL ; _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ;// _owner is (Thread ) vs SP/BasicLock _previous_owner_tid = 0;// 监视器前一个拥有者线程的ID }
当多个线程同时访问一段同步代码时，多个线程会先被存放在 ContentionList 和 _EntryList 凑集中，处于 block 状态的线程，都会被加入到该列表。接下来当线程获取到工具的 Monitor 时，Monitor 是依赖底层操作系统的 Mutex Lock 来实现互斥的，线程申请 Mutex 成功，则持有该 Mutex，其它线程将无法获取到该 Mutex，竞争失落败的线程会再次进入 ContentionList 被挂起。
如果线程调用 wait() 方法，就会开释当前持有的 Mutex，并且该线程会进入 WaitSet 凑集中，等待下一次被唤醒。如果当前哨程顺利实行完方法，也将开释 Mutex。
连续深入(锁优化)
我们都知道，工具被创建在堆中。并且工具在内存中的存储布局办法可以分为3块区域：工具头、实例数据、对齐添补。
对付工具头来说，紧张是包括俩部分信息Mark Word和Klass Point：
Mark Word用于存储工具自身的运行时数据，如哈希码（HashCode）、GC分代年事、锁状态标志、线程持有的锁、倾向线程 ID、倾向韶光戳等等。Java工具头一样平常霸占两个机器码（在32位虚拟机中，1个机器码即是4字节，也便是32bit），但是如果工具是数组类型，则须要三个机器码，由于JVM虚拟机可以通过Java工具的元数据信息确定Java工具的大小，但是无法从数组的元数据来确认数组的大小，以是用一块来记录数组长度。另一部分是类型指针Klass Point：JVM通过这个指针来确定这个工具是哪个类的实例。锁升级功能紧张依赖于 Mark Word 中的锁标志位和开释倾向锁标志位，Synchronized 同步锁便是从倾向锁开始的，随着竞争越来越激烈，倾向锁升级到轻量级锁，终极升级到重量级锁。好了本日就先到这了，锁优化的细节还在码字中。。
参考资料：
《深入理解Java虚拟机》 第二版
https://blog.csdn.net/wangyadong317/article/details/84065828
https://blog.csdn.net/zjy15203167987/article/details/82531772
https://www.cnblogs.com/JsonShare/p/11433302.html
https://baijiahao.baidu.com/s?id=1612142459503895416&wfr=spider&for=pc
http://cmsblogs.com/?p=2071
https://www.php.cn/java-article-410323.html
