[死磕 Java 并发] 系列是 LZ 在 2017 年写的第一个死磕系列，一直没有做一个合集，这篇博客则是将整个系列做一个概览。
先来一个总览图：
[高清图，请关注“ Java 技术驿站”公众号，回复：脑图 JUC ]
synchronized 可以保证方法或者代码块在运行时，同一时刻只有一个方法可以进入到临界区，同时它还可以保证共享变量的内存可见性。深入分析 synchronized 的内在实现机制，锁优化、锁升级过程。
volatile 可以保证线程可见性且提供了一定的有序性，但是无法保证原子性。在 JVM 底层 volatile 是采用“内存屏障”来实现的。这篇博文将带你分析 volatile 的本质
happens-before 原则是判断数据是否存在竞争、线程是否安全的主要依据，保证了多线程环境下的可见性。
定义如下：
在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：
as-if-serial 语义保证在单线程环境下重排序后的执行结果不会改变。
volatile 的内存语义是：
总是说 volatile 保证可见性，happens-before 是 JMM 实现可见性的基础理论，两者会碰撞怎样的火花？这篇博文给你答案。
DCL，即 Double Check Lock，双重检查锁定。是实现单例模式比较好的方式，这篇博客告诉你 DCL 中为何要加 volatile 这个关键字。
AQS，AbstractQueuedSynchronizer，即队列同步器。它是构建锁或者其他同步组件的基础框架（如 ReentrantLock、ReentrantReadWriteLock、Semaphore 等），为 JUC 并发包中的核心基础组件。
前线程已经等待状态等信息构造成一个节点（ Node ）并将其加入到 CLH 同步队列，同时会阻塞当前线程，当同步状态释放时，会把首节点唤醒（公平锁），使其再次尝试获取同步状态。
AQS 的设计模式采用的模板方法模式，子类通过继承的方式，实现它的抽象方法来管理同步状态，对于子类而言它并没有太多的活要做，AQS 提供了大量的模板方法来实现同步，主要是分为三类：独占式获取和释放同步状态、共享式获取和释放同步状态、查询同步队列中的等待线程情况。
当需要阻塞或者唤醒一个线程的时候，AQS 都是使用 LockSupport 这个工具类来完成。
LockSupport 是用来创建锁和其他同步类的基本线程阻塞原语。
一个可重入的互斥锁定 Lock，它具有与使用 synchronized 方法和语句所访问的隐式监视器锁定相同的一些基本行为和语义，但功能更强大。ReentrantLock 将由最近成功获得锁定，并且还没有释放该锁定的线程所拥有。当锁定没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁定并返回。如果当前线程已经拥有该锁定，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。
这篇博客带你理解 重入锁：ReentrantLock 内在本质。
读写锁维护着一对锁，一个读锁和一个写锁。通过分离读锁和写锁，使得并发性比一般的排他锁有了较大的提升：在同一时间可以允许多个读线程同时访问，但是在写线程访问时，所有读线程和写线程都会被阻塞。
读写锁的主要特性：
在没有 Lock 之前，我们使用 synchronized 来控制同步，配合 Object 的 wait()、notify()系列方法可以实现等待 /通知模式。在 Java SE5 后，Java 提供了 Lock 接口，相对于 Synchronized 而言，Lock 提供了条件 Condition，对线程的等待、唤醒操作更加详细和灵活
CAS，Compare And Swap，即比较并交换。Doug lea 大神在同步组件中大量使用 CAS 技术鬼斧神工地实现了 Java 多线程的并发操作。整个 AQS 同步组件、Atomic 原子类操作等等都是以 CAS 实现的。可以说 CAS 是整个 JUC 的基石。
CyclicBarrier，一个同步辅助类。它允许一组线程互相等待，直到到达某个公共屏障点 (common barrier point)。在涉及一组固定大小的线程的程序中，这些线程必须不时地互相等待，此时 CyclicBarrier 很有用。因为该 barrier 在释放等待线程后可以重用，所以称它为循环 的 barrier。
CountDownLatch 所描述的是”在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待“。
用给定的计数 初始化 CountDownLatch。由于调用了 countDown() 方法，所以在当前计数到达零之前，await 方法会一直受阻塞。之后，会释放所有等待的线程，await 的所有后续调用都将立即返回。
Semaphore，信号量，是一个控制访问多个共享资源的计数器。从概念上讲，信号量维护了一个许可集。如有必要，在许可可用前会阻塞每一个 acquire()，然后再获取该许可。每个 release() 添加一个许可，从而可能释放一个正在阻塞的获取者。但是，不使用实际的许可对象，Semaphore 只对可用许可的号码进行计数，并采取相应的行动。
可以在对中对元素进行配对和交换的线程的同步点。每个线程将条目上的某个方法呈现给 exchange 方法，与伙伴线程进行匹配，并且在返回时接收其伙伴的对象。Exchanger 可能被视为 SynchronousQueue 的双向形式。Exchanger 可能在应用程序（比如遗传算法和管道设计）中很有用。
ConcurrentHashMap 作为 Concurrent 一族，其有着高效地并发操作。在 1.8 版本以前，ConcurrentHashMap 采用分段锁的概念，使锁更加细化，但是 1.8 已经改变了这种思路，而是利用 CAS + Synchronized 来保证并发更新的安全，当然底层采用数组+链表+红黑树的存储结构。这篇博客带你彻底理解 ConcurrentHashMap。
在 1.8 ConcurrentHashMap 的 put 操作中，如果发现链表结构中的元素超过了 TREEIFY_THRESHOLD （默认为 8 ），则会把链表转换为红黑树，已便于提高查询效率。那么具体的转换过程是怎么样的？这篇博客给你答案。
ConcurrentLinkedQueue 是一个基于链接节点的无边界的线程安全队列，它采用 FIFO 原则对元素进行排序。采用“ wait-free ”算法（即 CAS 算法）来实现的。
CoucurrentLinkedQueue 规定了如下几个不变性：
我们在 Java 世界里看到了两种实现 key-value 的数据结构：Hash、TreeMap，这两种数据结构各自都有着优缺点。
这里介绍第三种实现 key-value 的数据结构：SkipList。SkipList 有着不低于红黑树的效率，但是其原理和实现的复杂度要比红黑树简单多了。
ConcurrentSkipListMap 其内部采用 SkipLis 数据结构实现。
ArrayBlockingQueue，一个由数组实现的有界阻塞队列。该队列采用 FIFO 的原则对元素进行排序添加的。
ArrayBlockingQueue 为有界且固定，其大小在构造时由构造函数来决定，确认之后就不能再改变了。ArrayBlockingQueue 支持对等待的生产者线程和使用者线程进行排序的可选公平策略，但是在默认情况下不保证线程公平的访问，在构造时可以选择公平策略（ fair = true ）。公平性通常会降低吞吐量，但是减少了可变性和避免了“不平衡性”。
PriorityBlockingQueue 是一个支持优先级的无界阻塞队列。默认情况下元素采用自然顺序升序排序，当然我们也可以通过构造函数来指定 Comparator 来对元素进行排序。需要注意的是 PriorityBlockingQueue 不能保证同优先级元素的顺序。
DelayQueue 是一个支持延时获取元素的无界阻塞队列。里面的元素全部都是“可延期”的元素，列头的元素是最先“到期”的元素，如果队列里面没有元素到期，是不能从列头获取元素的，哪怕有元素也不行。也就是说只有在延迟期到时才能够从队列中取元素。
DelayQueue 主要用于两个方面：
SynchronousQueue 与其他 BlockingQueue 有着不同特性：
SynchronousQueue 非常适合做交换工作，生产者的线程和消费者的线程同步以传递某些信息、事件或者任务。
LinkedTransferQueue 是基于链表的 FIFO 无界阻塞队列，它出现在 JDK7 中。Doug Lea 大神说 LinkedTransferQueue 是一个聪明的队列。它是 ConcurrentLinkedQueue、SynchronousQueue (公平模式下)、无界的 LinkedBlockingQueues 等的超集。
LinkedBlockingDeque 是一个由链表组成的双向阻塞队列，双向队列就意味着可以从对头、对尾两端插入和移除元素，同样意味着 LinkedBlockingDeque 支持 FIFO、FILO 两种操作方式。
LinkedBlockingDeque 是可选容量的，在初始化时可以设置容量防止其过度膨胀，如果不设置，默认容量大小为 Integer.MAX_VALUE。
ThreadLocal 提供了线程局部 (thread-local) 变量。这些变量不同于它们的普通对应物，因为访问某个变量（通过其 get 或 set 方法）的每个线程都有自己的局部变量，它独立于变量的初始化副本。ThreadLocal 实例通常是类中的 private static 字段，它们希望将状态与某一个线程（例如，用户 ID 或事务 ID ）相关联。
所以 ThreadLocal 与线程同步机制不同，线程同步机制是多个线程共享同一个变量，而 ThreadLocal 是为每一个线程创建一个单独的变量副本，故而每个线程都可以独立地改变自己所拥有的变量副本，而不会影响其他线程所对应的副本。可以说 ThreadLocal 为多线程环境下变量问题提供了另外一种解决思路。
鼎鼎大名的线程池。不需要多说!!!!!
这篇博客深入分析 Java 中线程池的实现。
ScheduledThreadPoolExecutor 是实现线程的周期、延迟调度的。
ScheduledThreadPoolExecutor，继承 ThreadPoolExecutor 且实现了 ScheduledExecutorService 接口，它就相当于提供了“延迟”和“周期执行”功能的 ThreadPoolExecutor。在 JDK API 中是这样定义它的：ThreadPoolExecutor，它可另行安排在给定的延迟后运行命令，或者定期执行命令。需要多个辅助线程时，或者要求 ThreadPoolExecutor 具有额外的灵活性或功能时，此类要优于 Timer。 一旦启用已延迟的任务就执行它，但是有关何时启用，启用后何时执行则没有任何实时保证。按照提交的先进先出 (FIFO) 顺序来启用那些被安排在同一执行时间的任务。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.