Synchronized是基于monitor实现的,Synchronized经过编译后，会在同步块前后分别形成monitorenter和monitorexit两个字节码指令，在执行monitorenter指令时，首先要尝试获取对象锁，如果对象没有别锁定，或者当前已经拥有这个对象锁，把锁的计数器加1，相应的在执行monitorexit指令时，会将计数器减1，当计数器为0时，锁就被释放了。
如果获取锁失败，那当前线程就要阻塞，直到对象锁被另一个线程释放为止。

synchronized底层语义原理

Java 虚拟机中的同步(Synchronization)基于进入和退出管程(Monitor)对象实现， 无论是显式同步(有明确的 monitorenter 和 monitorexit 指令,即同步代码块)还是隐式同步都是如此。在 Java 语言中，同步用的最多的地方可能是被 synchronized 修饰的同步方法。
同步方法 并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的，关于这点，稍后详细分析。

下面先来了解一个概念Java对象头，这对深入理解synchronized实现原理非常关键。

synchronized特点:可重入锁/排他锁/属于jvm，由jvm实现
可重入锁实现可重入性原理或机制是：
每一个锁关联一个线程持有者和计数器，当计数器为 0 时表示该锁没有被任何线程持有，那么任何线程都可能获得该锁而调用相应的方法；
当某一线程请求成功后，JVM会记下锁的持有线程，并且将计数器置为 1；此时其它线程请求该锁，则必须等待；而该持有锁的线程如果再次请求这个锁，就可以再次拿到这个锁，同时计数器会递增；当线程退出同步代码块时，计数器会递减，如果计数器为 0，则释放该锁。

synchronized保证可见性
JMM关于synchronized的两条规定：
1）线程解锁前，必须把共享变量的最新值刷新到主内存中
2）线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新获取最新的值
锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。

在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。

实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。
填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐，这点了解即可。
Java头对象，它实现synchronized的锁对象的基础，synchronized使用的锁对象是存储在Java对象头里的，jvm中采用2个字来存储对象头(如果对象是数组则会分配3个字，多出来的1个字记录的是数组长度)，其主要结构是由Mark Word 和 Class Metadata Address 组成

轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增加的，重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。
每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。
在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）

ObjectMonitor() {
    _header       = NULL;
    _count        = 0; //记录个数
    _waiters      = 0,
    _recursions   = 0;
    _object       = NULL;
    _owner        = NULL;
    _WaitSet      = NULL; //处于wait状态的线程，会被加入到_WaitSet
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ;
    FreeNext      = NULL ;
    _EntryList    = NULL ; //处于等待锁block状态的线程，会被加入到该列表
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
  }

ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象)，_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时。
首先会进入 _EntryList 集合，当线程获取到对象的monitor后进入_Owner区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSet集合中等待被唤醒。
若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。

monitor对象存在于每个Java对象的对象头中(存储的指针的指向)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因

GC管理的主要区域是Java堆，一般情况下只针对堆进行垃圾回收。方法区、栈和本地方法区不被GC所管理,因而选择这些区域内的对象作为GC roots,被GC roots引用的对象不被GC回收。

GC Root

常说的GC(Garbage Collector) roots，特指的是垃圾收集器（Garbage Collector）的对象，GC会收集那些不是GC roots且没有被GC roots引用的对象。

一个对象可以属于多个root，GC root有几下种：

• Class – 由系统类加载器(system class loader)加载的对象，这些类是不能够被回收的，他们可以以静态字段的方式保存持有其它对象。我们需要注意的一点就是，通过用户自定义的类加载器加载的类，除非相应的java.lang.Class实例以其它的某种（或多种）方式成为roots，否则它们并不是roots，.
• Thread – 活着的线程
• Stack Local – Java方法的local变量或参数
• JNI Local – JNI方法的local变量或参数
• JNI Global – 全局JNI引用
• Monitor Used – 用于同步的监控对象
• Held by JVM – 用于JVM特殊目的由GC保留的对象，但实际上这个与JVM的实现是有关的。可能已知的一些类型是：系统类加载器、一些JVM知道的重要的异常类、一些用于处理异常的预分配对象以及一些自定义的类加载器等。然而，JVM并没有为这些对象提供其它的信息，因此需要去确定哪些是属于”JVM持有”的了。

看java 代码的时候，很多人都会看见用完一个树或者链表后 head = null;这样的代码。有人说为了加快gc，这里为你揭秘为什么这么写。
代码一定要跑，别的不重要。
代码一定要跑，别的不重要。
代码一定要跑，别的不重要。

• 首先来看看名词的含义，GC（Garbage Collection ）
• root 根，这个root是不是很熟悉，root用户，数据结构中树的顶级节点
  也叫 root。
• roots 自然就是多个root了。
• 从我们熟悉的root里有两个概念，一个是用户，一个是节点，
• 在GC 里的含义和树里的含义差不多，开始或者顶级的节点。
  概念大概就这样，然后我们看看怎么去理解这个东西。
• 不知道或者不熟悉的同学可以看这里 点这里了解树；

怎么遍历这棵树这里就不阐述了。这里的每个节点你可以理解成每个类里的属性。

下面开始做理解gc roots

这里摘抄R大的一些回答

所有Java线程当前活跃的栈帧,静态引用等指向GC堆里的对象的引用；换句话说，当前所有正在被调用的方法的引用类型的参数/局部变量/临时值。

假设hashMap 在扩容的时候，正巧发生了gc，在标记阶段，要找出所有的root，这里的 oldTab 就是root，通过这个root，然后遍历他的所有属性，如果它里面的内容不为null 我们继续遍历内容里的对象字段是否为null，标记出所有不为null的节点。继续下图，子节点

静态引用这样的代码也会成为root

private static Object objoct;

这里可以看到Node里还有Node,标记的时候就这这样，遍历每个属性的子属性，一直到遍历完，则这些被标记的为有引用的。gc标记的过程就是一棵树在遍历他所有的节点，这样应该很清楚了吧。最后没有被标记的就给清楚掉。

/**
 * @author 铁拳阿牛
 * @createTime 2018/7/14 下午3:33
 **/
public class Node {

    private Object object;
       //如果这个Node被引用他的属性又被引用，属性为对象且不为null，这样一直遍历下去，
     
    private Node node;
}

理论扯完了，接下来实践

/**
 * @author 铁拳阿牛
 * @createTime 2018/7/14 下午3:46
 *
 * 请把以下参数设置到jvm里
 * -Xmx4000M -Xms4000M -Xmn1300M  -XX:+UseParNewGC  -XX:+UseConcMarkSweepGC  -XX:+UseCMSInitiatingOccupancyOnly  -XX:CMSInitiatingOccupancyFraction=75 -XX:+PrintGCDetails
 **/
public class Test {

    private static final int _1MB = 1024 * 1024;

    private static final int LENGTH = 40000000;

    public static void main(String[] args) {
        Node next = null;
        for(int i = 0; i <= LENGTH; i++){
            Node node = new Node(i,next);
            next = node;
        }
        //如果不设置为null这里将会又大批量的遍历，打开这里和不打开这里，gc时间完全不一样，现在你直到为什么要设置为null了吗？
//        next = null;
        triggerGC();
    }

    /**
     * 不触发gc看不见效果
     * new 很多小对象。不然直接到 old区去了。
     */
    private static void triggerGC(){
//        byte[] all = new byte[2000 * _1MB]; //这里为什么没又直接new 一个大对象？它可能直接就到old区去了。
        for(int i = 0 ; i < 500 ; i++){
            byte[] bytes = new byte[2 * _1MB];
        }
    }

    //POJO 不用看这里
    static class Node {
        
        private int valuel;
        
        private Node node;
        
        public Node(int valuel, Node node) {
            this.valuel = valuel;
            this.node = node;
        }

        public int getValuel() {
            return valuel;
        }

        public void setValuel(int valuel) {
            this.valuel = valuel;
        }

        public Node getNode() {
            return node;
        }

        public void setNode(Node node) {
            this.node = node;
        }
    }

}

第一次我们要把eden 的空间尽可能的占满将这两行代码注释掉，发现eden已经用了94% 很不错。

//        next = null;
//        triggerGC();
～～～～～～～～～～～～～～～～～
Heap
 par new generation   total 1198080K, used 1001063K [0x00000006c6000000, 0x0000000717400000, 0x0000000717400000)
  eden space 1064960K,  94% used [0x00000006c6000000, 0x0000000703199e78, 0x0000000707000000)
  from space 133120K,   0% used [0x0000000707000000, 0x0000000707000000, 0x000000070f200000)
  to   space 133120K,   0% used [0x000000070f200000, 0x000000070f200000, 0x0000000717400000)
 concurrent mark-sweep generation total 2764800K, used 0K [0x0000000717400000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 2674K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 288K, capacity 386K, committed 512K, reserved 1048576K

然后我们开始测试了，发现gc时间非常的短， [Times: user=0.04 sys=0.00, real=0.01 secs] ,gc基本没有占用我们的时间。

        next = null;
        triggerGC();
～～～～～～～～～～～～～～～～～
[GC (Allocation Failure) [ParNew: 1063732K->399K(1198080K), 0.0101658 secs] 1063732K->399K(3962880K), 0.0102629 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
Heap
 par new generation   total 1198080K, used 933048K [0x00000006c6000000, 0x0000000717400000, 0x0000000717400000)
  eden space 1064960K,  87% used [0x00000006c6000000, 0x00000006feeca630, 0x0000000707000000)
  from space 133120K,   0% used [0x000000070f200000, 0x000000070f263d38, 0x0000000717400000)
  to   space 133120K,   0% used [0x0000000707000000, 0x0000000707000000, 0x000000070f200000)
 concurrent mark-sweep generation total 2764800K, used 0K [0x0000000717400000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 2674K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 288K, capacity 386K, committed 512K, reserved 1048576K

然后我们对比测试，发现gc时间非常的短，[Times: user=145.85 sys=1.89, real=20.17 secs] ,额这个gc时间。。。

//        next = null;
        triggerGC();
～～～～～～～～～～～～～～～～～
[GC (Allocation Failure) [ParNew: 1063732K->133119K(1198080K), 20.1710025 secs] 1063732K->938404K(3962880K), 20.1710585 secs] [Times: user=145.85 sys=1.89, real=20.17 secs] 
Heap
 par new generation   total 1198080K, used 1065769K [0x00000006c6000000, 0x0000000717400000, 0x0000000717400000)
  eden space 1064960K,  87% used [0x00000006c6000000, 0x00000006feeca630, 0x0000000707000000)
  from space 133120K,  99% used [0x000000070f200000, 0x00000007173ffff8, 0x0000000717400000)
  to   space 133120K,   0% used [0x0000000707000000, 0x0000000707000000, 0x000000070f200000)
 concurrent mark-sweep generation total 2764800K, used 805284K [0x0000000717400000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 2676K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 288K, capacity 386K, committed 512K, reserved 1048576K

把这些对象标记后其他的都是要清除的，所以现在知道为什么要设置为null
了吗？就是为了加快标记阶段。如果你有个超大的map或者list的时候这样
做会有一点点帮助。(普通开发过程中基本没有必要考虑)

明白java的源码里为什么会有这些操作了吗？