概念
公平锁/非公平锁
公平锁是指多个线程按照申请锁的顺序来获取锁。
非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。
对于 Java ReentrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。
对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过 AQS 的来实现线程调度，所以并没有任何办法使其变成公平锁。
可重入锁
可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。
说的有点抽象，下面会有一个代码的示例。对于 Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁，其名字是Re entrant Lock重新进入锁。对于Synchronized而言,也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。
synchronized void setA() throws Exception{ Thread.sleep(1000); setB();}synchronized void setB() throws Exception{ Thread.sleep(1000);}
上面的代码就是一个可重入锁的一个特点，如果不是可重入锁的话，setB 可能不会被当前线程执行，可能造成死锁。
独享锁/共享锁
独享锁是指该锁一次只能被一个线程所持有。
共享锁是指该锁可被多个线程所持有。
对于 Java ReentrantLock而言，其是独享锁。但是对于 Lock 的另一个实现类ReadWriteLock，其读锁是共享锁，其写锁是独享锁。读锁的共享锁可保证并发读是非常高效的，读写，写读 ，写写的过程是互斥的。独享锁与共享锁也是通过 AQS 来实现的，通过实现不同的方法，来实现独享或者共享。对于Synchronized而言，当然是独享锁。
互斥锁/读写锁
上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。互斥锁在 Java 中的具体实现就是ReentrantLock 读写锁在 Java 中的具体实现就是ReadWriteLock
乐观锁/悲观锁
乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。
从上面的描述我们可以看出，悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。悲观锁在 Java 中的使用，就是利用各种锁。乐观锁在 Java 中的使用，是无锁编程，常常采用的是 CAS 算法，典型的例子就是原子类，通过 CAS 自旋实现原子操作的更新。
分段锁
分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为 Segment，它即类似于 HashMap（JDK7 与 JDK8 中 HashMap 的实现）的结构，即内部拥有一个 Entry 数组，数组中的每个元素既是一个链表；同时又是一个 ReentrantLock（Segment 继承了 ReentrantLock)。当需要 put 元素的时候，并不是对整个 hashmap 进行加锁，而是先通过 hashcode 来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程 put 的时候，只要不是放在一个分段中，就实现了真正的并行的插入。但是，在统计 size 的时候，可就是获取 hashmap 全局信息的时候，就需要获取所有的分段锁才能统计。分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。
偏向锁/轻量级锁/重量级锁
这三种锁是指锁的状态，并且是针对Synchronized。在 Java 5 通过引入锁升级的机制来实现高效Synchronized。
这三种锁的状态是通过对象监视器在对象头中的字段来表明的。
偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。
轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。
重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。
自旋锁
在 Java 中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗 CPU。
为什么用 Lock、ReadWriteLock
-
synchronized 的缺陷
- 被 synchronized 修饰的方法或代码块，只能被一个线程访问。如果这个线程被阻塞，其他线程也只能等待。
- synchronized 不能响应中断。
- synchronized 没有超时机制。
- synchronized 只能是非公平锁。
-
Lock、ReadWriteLock 相较于 synchronized，解决了以上的缺陷：
- Lock 可以手动释放锁（synchronized 获取锁和释放锁都是自动的），以避免死锁。
- Lock 可以响应中断
- Lock 可以设置超时时间，避免一致等待
- Lock 可以选择公平锁或非公平锁两种模式
- ReadWriteLock 将读写锁分离，从而使读写操作分开，有效提高并发性。
Lock 和 ReentrantLock
要点
如果采用 Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用 Lock 必须在 try catch 块中进行，并且将释放锁的操作放在 finally 块中进行，以保证锁一定被被释放，防止死锁的发生。
lock() 方法的作用是获取锁。如果锁已被其他线程获取，则进行等待。
tryLock() 方法的作用是尝试获取锁，如果成功，则返回 true；如果失败（即锁已被其他线程获取），则返回 false。也就是说，这个方法无论如何都会立即返回，获取不到锁时不会一直等待。
tryLock(long time, TimeUnit unit) 方法和 tryLock() 方法是类似的，区别仅在于这个方法在获取不到锁时会等待一定的时间，在时间期限之内如果还获取不到锁，就返回 false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回 true。
lockInterruptibly() 方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过 lock.lockInterruptibly() 想获取某个锁时，假若此时线程 A 获取到了锁，而线程 B 只有在等待，那么对线程 B 调用 threadB.interrupt() 方法能够中断线程 B 的等待过程。由于 lockInterruptibly() 的声明中抛出了异常，所以 lock.lockInterruptibly() 必须放在 try 块中或者在调用 lockInterruptibly() 的方法外声明抛出 InterruptedException。
注意：当一个线程获取了锁之后，是不会被 interrupt() 方法中断的。因为本身在前面的文章中讲过单独调用 interrupt() 方法不能中断正在运行过程中的线程，只能中断阻塞过程中的线程。因此当通过 lockInterruptibly() 方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以响应中断的。
unlock() 方法的作用是释放锁。
ReentrantLock 是唯一实现了 Lock 接口的类。
ReentrantLock 字面意为可重入锁。
源码
Lock 接口定义
public interface Lock { void lock(); void lockInterruptibly() throws InterruptedException; boolean tryLock(); boolean tryLock(long time, TimeUnit unit) throws InterruptedException; void unlock(); Condition newCondition();}
ReentrantLock 属性和方法
ReentrantLock 的核心方法当然是 Lock 中的方法（具体实现完全基于 Sync 类中提供的方法）。
此外，ReentrantLock 有两个构造方法，功能参考下面源码片段中的注释。
// 同步机制完全依赖于此private final Sync sync;// 默认初始化 sync 的实例为非公平锁（NonfairSync）public ReentrantLock() {}// 根据 boolean 值选择初始化 sync 的实例为公平的锁（FairSync）或不公平锁（NonfairSync）public ReentrantLock(boolean fair) {} Sync
Sync类是ReentrantLock的内部类，也是一个抽象类。ReentrantLock的同步机制几乎完全依赖于Sync。使用 AQS 状态来表示锁的保留数（详细介绍参见 ）。Sync是一个抽象类，有两个子类：FairSync- 公平锁版本。NonfairSync- 非公平锁版本。
示例
public class ReentrantLockDemo { private ArrayList arrayList = new ArrayList (); private Lock lock = new ReentrantLock(); public static void main(String[] args) { final ReentrantLockDemo demo = new ReentrantLockDemo(); new Thread(() -> demo.insert(Thread.currentThread())).start(); new Thread(() -> demo.insert(Thread.currentThread())).start(); } private void insert(Thread thread) { lock.lock(); try { System.out.println(thread.getName() + "得到了锁"); for (int i = 0; i < 5; i++) { arrayList.add(i); } } catch (Exception e) { e.printStackTrace(); } finally { System.out.println(thread.getName() + "释放了锁"); lock.unlock(); } }}
?
ReadWriteLock 和 ReentrantReadWriteLock
要点
对于特定的资源，ReadWriteLock 允许多个线程同时对其执行读操作，但是只允许一个线程对其执行写操作。
ReadWriteLock 维护一对相关的锁。一个是读锁；一个是写锁。将读写锁分开，有利于提高并发效率。
ReentrantReadWriteLock 实现了 ReadWriteLock 接口，所以它是一个读写锁。
“读-读”线程之间不存在互斥关系。
“读-写”线程、“写-写”线程之间存在互斥关系。
源码
ReadWriteLock 接口定义
public interface ReadWriteLock { /** * 返回用于读操作的锁 */ Lock readLock(); /** * 返回用于写操作的锁 */ Lock writeLock();}
示例
public class ReentrantReadWriteLockDemo { private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); public static void main(String[] args) { final ReentrantReadWriteLockDemo demo = new ReentrantReadWriteLockDemo(); new Thread(() -> demo.get(Thread.currentThread())).start(); new Thread(() -> demo.get(Thread.currentThread())).start(); } public synchronized void get(Thread thread) { rwl.readLock().lock(); try { long start = System.currentTimeMillis(); while (System.currentTimeMillis() - start <= 1) { System.out.println(thread.getName() + "正在进行读操作"); } System.out.println(thread.getName() + "读操作完毕"); } finally { rwl.readLock().unlock(); } }}
AQS
AQS 作为构建锁或者其他同步组件的基础框架，有必要好好了解一下其原理。
要点
作用：AQS，AbstractQueuedSynchronizer，即队列同步器。它是构建锁或者其他同步组件的基础框架（如 ReentrantLock、ReentrantReadWriteLock、Semaphore 等）。
场景：在 LOCK 包中的相关锁(常用的有 ReentrantLock、 ReadWriteLock)都是基于 AQS 来构建。然而这些锁都没有直接来继承 AQS，而是定义了一个 Sync 类去继承 AQS。那么为什么要这样呢?because:锁面向的是使用用户，而同步器面向的则是线程控制，那么在锁的实现中聚合同步器而不是直接继承 AQS 就可以很好的隔离二者所关注的事情。
原理：AQS 在内部定义了一个 int 变量 state，用来表示同步状态。AQS 通过一个双向的 FIFO 同步队列来完成同步状态的管理，当有线程获取锁失败后，就被添加到队列末尾。
源码
AbstractQueuedSynchronizer 继承自 AbstractOwnableSynchronize。
同步队列
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable { /** 等待队列的队头，懒加载。只能通过 setHead 方法修改。 */ private transient volatile Node head; /** 等待队列的队尾，懒加载。只能通过 enq 方法添加新的等待节点。*/ private transient volatile Node tail; /** 同步状态 */ private volatile int state;}
AQS 维护了一个 Node 类型双链表，通过 head 和 tail 指针进行访问。
Node
static final class Node { /** 该等待同步的节点处于共享模式 */ static final Node SHARED = new Node(); /** 该等待同步的节点处于独占模式 */ static final Node EXCLUSIVE = null; /** 等待状态,这个和 state 是不一样的:有 1,0,-1,-2,-3 五个值 */ volatile int waitStatus; static final int CANCELLED = 1; static final int SIGNAL = -1; static final int CONDITION = -2; static final int PROPAGATE = -3; /** 前驱节点 */ volatile Node prev; /** 后继节点 */ volatile Node next; /** 等待锁的线程 */ volatile Thread thread;}
很显然，Node 是一个双链表结构。
waitStatus 5 个状态值的含义：
- CANCELLED（1） - 该节点的线程可能由于超时或被中断而处于被取消(作废)状态，一旦处于这个状态，节点状态将一直处于 CANCELLED(作废)，因此应该从队列中移除.
- SIGNAL（-1） - 当前节点为 SIGNAL 时，后继节点会被挂起，因此在当前节点释放锁或被取消之后必须被唤醒(unparking)其后继结点.
- CONDITION（-2） - 该节点的线程处于等待条件状态，不会被当作是同步队列上的节点,直到被唤醒(signal)，设置其值为 0,重新进入阻塞状态。
- PROPAGATE（-3） - 下一个 acquireShared 应无条件传播。
- 0 - 非以上状态。
获取独占锁
acquire
/** * 先调用 tryAcquire 查看同步状态。 * 如果成功获取同步状态，则结束方法，直接返回； * 反之，则先调用 addWaiter，再调用 acquireQueued。 */public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt();}
addWaiter
addWaiter 方法的作用是将当前线程插入等待同步队列的队尾。
private Node addWaiter(Node mode) { // 1. 将当前线程构建成 Node 类型 Node node = new Node(Thread.currentThread(), mode); // 2. 判断尾指针是否为 null Node pred = tail; if (pred != null) { // 2.2 将当前节点插入队列尾部 node.prev = pred; if (compareAndSetTail(pred, node)) { pred.next = node; return node; } } // 2.1. 尾指针为 null，说明当前节点是第一个加入队列的节点 enq(node); return node;}
enq
enq 方法的作用是通过自旋（死循环），不断尝试利用 CAS 操作将节点插入队列尾部，直到成功为止。
private Node enq(final Node node) { // 设置死循环，是为了不断尝试 CAS 操作，直到成功为止 for (;;) { Node t = tail; if (t == null) { // 1. 构造头结点（必须初始化，需要领会双链表的精髓） if (compareAndSetHead(new Node())) tail = head; } else { // 2. 通过 CAS 操作将节点插入队列尾部 node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } }}
acquireQueued
acquireQueued 方法的作用是通过自旋（死循环），不断尝试为等待队列中线程获取独占锁。
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { // 1. 获得当前节点的上一个节点 final Node p = node.predecessor(); // 2. 当前节点能否获取独占式锁 // 2.1 如果当前节点是队列中第一个节点，并且成功获取同步状态，即可以获得独占式锁 // 说明：当前节点的上一个节点是头指针，即意味着当前节点是队列中第一个节点。 if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return interrupted; } // 2.2 获取锁失败，线程进入等待状态等待获取独占式锁 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }
acquireQueued Before
setHead 方法private void setHead(Node node) { head = node; node.thread = null; node.prev = null;}
将当前节点通过 setHead 方法设置为队列的头结点，然后将之前的头结点的 next 域设置为 null，并且 pre 域也为 null，即与队列断开，无任何引用方便 GC 时能够将内存进行回收。
shouldParkAfterFailedAcquire
shouldParkAfterFailedAcquire 方法的作用是使用 compareAndSetWaitStatus(pred, ws, Node.SIGNAL) 将节点状态由 INITIAL 设置成 SIGNAL，表示当前线程阻塞。
当 compareAndSetWaitStatus 设置失败，则说明 shouldParkAfterFailedAcquire 方法返回 false，重新进入外部方法 acquireQueued。由于 acquireQueued 方法中是死循环，会再一次执行 shouldParkAfterFailedAcquire，直至 compareAndSetWaitStatus 设置节点状态位为 SIGNAL。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { int ws = pred.waitStatus; if (ws == Node.SIGNAL) return true; if (ws > 0) { do { node.prev = pred = pred.prev; } while (pred.waitStatus > 0); pred.next = node; } else { compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false;}parkAndCheckInterruptparkAndCheckInterrupt 方法的作用是调用 LookSupport.park 方法，该方法是用来阻塞当前线程的。private final boolean parkAndCheckInterrupt() { LockSupport.park(this); return Thread.interrupted();}
acquire 流程
综上所述，就是 acquire 的完整流程。可以以一幅图来说明：
释放独占锁
release
release 方法以独占模式发布。如果 tryRelease 返回 true，则通过解锁一个或多个线程来实现。这个方法可以用来实现 Lock.unlock 方法。
public final boolean release(int arg) { // 判断同步状态释放是否成功 if (tryRelease(arg)) { Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false;}
unparkSuccessor
unparkSuccessor 方法作用是唤醒 node 的下一个节点。
头指针的后继节点
private void unparkSuccessor(Node node) { /* * 如果状态为负值（即可能需要信号），请尝试清除信号。 * 如果失败或状态由于等待线程而改变也是正常的。 */ int ws = node.waitStatus; if (ws < 0) compareAndSetWaitStatus(node, ws, 0); /** * 释放后继节点的线程。 * 如果状态为 CANCELLED 放或节点明显为空， * 则从尾部向后遍历以找到状态不是 CANCELLED 的后继节点。 */ Node s = node.next; if (s == null || s.waitStatus > 0) { s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) s = t; } // 后继节点不为 null 时唤醒该线程 if (s != null) LockSupport.unpark(s.thread);}
总结
- 线程获取锁失败，线程被封装成 Node 进行入队操作，核心方法在于 addWaiter()和 enq()，同时 enq()完成对同步队列的头结点初始化工作以及 CAS 操作失败的重试 ;
- 线程获取锁是一个自旋的过程，当且仅当 当前节点的前驱节点是头结点并且成功获得同步状态时，节点出队即该节点引用的线程获得锁，否则，当不满足条件时就会调用 LookSupport.park()方法使得线程阻塞 ；
- 释放锁的时候会唤醒后继节点；
获取可中断的独占锁
acquireInterruptibly
Lock 能响应中断，这是相较于 synchronized 的一个显著优点。
那么 Lock 响应中断的特性是如何实现的？答案就在 acquireInterruptibly 方法中。
public final void acquireInterruptibly(int arg) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); if (!tryAcquire(arg)) // 线程获取锁失败 doAcquireInterruptibly(arg);}
doAcquireInterruptibly
获取同步状态失败后就会调用 doAcquireInterruptibly 方法
private void doAcquireInterruptibly(int arg) throws InterruptedException { // 将节点插入到同步队列中 final Node node = addWaiter(Node.EXCLUSIVE); boolean failed = true; try { for (;;) { final Node p = node.predecessor(); // 获取锁出队 if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return; } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) // 线程中断抛异常 throw new InterruptedException(); } } finally { if (failed) cancelAcquire(node); }}
与 acquire 方法逻辑几乎一致，唯一的区别是当 parkAndCheckInterrupt 返回 true 时（即线程阻塞时该线程被中断），代码抛出被中断异常。
获取超时等待式的独占锁
tryAcquireNanos
通过调用 lock.tryLock(timeout,TimeUnit) 方式达到超时等待获取锁的效果，该方法会在三种情况下才会返回：
- 在超时时间内，当前线程成功获取了锁；
- 当前线程在超时时间内被中断；
- 超时时间结束，仍未获得锁返回 false。
我们仍然通过采取阅读源码的方式来学习底层具体是怎么实现的，该方法会调用 AQS 的方法 tryAcquireNanos
public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); return tryAcquire(arg) || // 实现超时等待的效果 doAcquireNanos(arg, nanosTimeout);}doAcquireNanosprivate boolean doAcquireNanos(int arg, long nanosTimeout) throws InterruptedException { if (nanosTimeout <= 0L) return false; // 1. 根据超时时间和当前时间计算出截止时间 final long deadline = System.nanoTime() + nanosTimeout; final Node node = addWaiter(Node.EXCLUSIVE); boolean failed = true; try { for (;;) { final Node p = node.predecessor(); // 2. 当前线程获得锁出队列 if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return true; } // 3.1 重新计算超时时间 nanosTimeout = deadline - System.nanoTime(); // 3.2 超时返回 false if (nanosTimeout <= 0L) return false; // 3.3 线程阻塞等待 if (shouldParkAfterFailedAcquire(p, node) && nanosTimeout > spinForTimeoutThreshold) LockSupport.parkNanos(this, nanosTimeout); // 3.4 线程被中断抛出被中断异常 if (Thread.interrupted()) throw new InterruptedException(); } } finally { if (failed) cancelAcquire(node); }}
获取共享锁
acquireSharedpublic final void acquireShared(int arg) { if (tryAcquireShared(arg) < 0) doAcquireShared(arg);}
尝试获取共享锁失败，调用 doAcquireShared
private void doAcquireShared(int arg) { final Node node = addWaiter(Node.SHARED); boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); if (p == head) { int r = tryAcquireShared(arg); if (r >= 0) { // 当该节点的前驱节点是头结点且成功获取同步状态 setHeadAndPropagate(node, r); p.next = null; // help GC if (interrupted) selfInterrupt(); failed = false; return; } } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); }}
以上代码和 acquireQueued 的代码逻辑十分相似，区别仅在于自旋的条件以及节点出队的操作有所不同。
释放共享锁
releaseSharedpublic final boolean releaseShared(int arg) { if (tryReleaseShared(arg)) { doReleaseShared(); return true; } return false;}
doReleaseShared
当成功释放同步状态之后即 tryReleaseShared 会继续执行 doReleaseShared 方法
发送后继信号并确保传播。 （注意：对于独占模式，如果需要信号，释放就相当于调用头的 unparkSuccessor。）
private void doReleaseShared() { for (;;) { Node h = head; if (h != null && h != tail) { int ws = h.waitStatus; if (ws == Node.SIGNAL) { if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0)) continue; // loop to recheck cases unparkSuccessor(h); } else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE)) // 如果 CAS 失败，继续自旋 continue; } // 如果头指针变化，break if (h == head) break; }}
获取可中断的共享锁
acquireSharedInterruptibly 方法与 acquireInterruptibly 几乎一致，不再赘述。
获取超时等待式的共享锁
tryAcquireSharedNanos 方法与 tryAcquireNanos 几乎一致，不再赘述。
免费Java资料需要自己领取，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程。
传送门：