写在前面 进入源码阶段了，写了十几篇的 并发系列 知识铺垫终于要派上用场了。相信很多人已经忘了其中的一些理论知识，别担心，我会在源码环节带入相应的理论知识点帮助大家回忆，做到理论与实践相结合，另外这是超长图文，建议收藏，如果对你有用还请点赞让更多人看到 Java SDK 为什么要设计 Lock 曾几何时幻想过，如果 Java 并发控制只有 synchronized 多好，只有下面三种使用方式，简单方便 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class ThreeSync { private static fina

| 好看请赞，养成习惯 * 你有一个思想，我有一个思想，我们交换后，一个人就有两个思想 * If you can NOT explain it simply, you do NOT understand it well enough 现陆续将Demo代码和技术文章整理在一起 Github实践精选 ，方便大家阅读查看，本文同样收录在此，觉得不错，还请Star🌟 横看成岭侧成峰，远近高低各不同，并发编程理论系列基本已经结束，相信大家有了理论的铺垫，近看源码才能发现其设计之美，不会一头雾水 本来是要介绍 AQS 作为我们走进并发编程源码环节的

上一篇文章 面试问我，创建多少个线程合适？我该怎么说 从定性到定量的分析了如何创建正确个数的线程来最大化利用系统资源（其实就是几道小学数学题）。通常来讲，有了个这个知识点傍身，按需手动创建相应个数的线程就好 但是现实中，你也许听过或者被要求： 尽量避免手动创建线程，应使用线程池统一管理线程 为什么会有这样的要求？背后的道理又是怎样的呢？顺着这个经验理论来推断，那肯定是手动创建线程有缺点 手动创建线程有什么缺点？ 1. 不受控风险 2. 频繁创建开销大 不受控风险 这个缺点，相信你也可以说出一二 系统资源有限，每个人针对不同业务都可以手动创建线程，并且创建标准不一样（比如线程没有

为什么要使用多线程？ 防止并发编程出错最好的办法就是不写并发程序 既然多线程编程容易出错，为什么它还经久不衰呢？ A：那还用说，肯定在某些方面有特长呗，比如你知道的【它很快，非常快】 我也很赞同这个答案，但说的不够具体 并发编程适用于什么场景？ 如果问你选择多线程的原因就是一个【快】字，面试也就不会出那么多幺蛾子了。你有没有问过你自己 1. 并发编程在所有场景下都是快的吗？ 2. 知道它很快，何为快？怎样度量？ 想知道这两个问题的答案，我们需要一个从【定性】到【定量】的分析过程 使用多线程就是在正确的场景下通过设置正确个数的线程来最大化程序的运行速度（我感觉你还是啥也没

为什么要了解线程的生命周期？ 之前写过 Spring Bean 生命周期三部曲： 1. Spring Bean生命周期之缘起 2. Spring Bean生命周期之缘尽 3. Spring Aware 到底是什么？ 有朋友留言说：“了解了它们的生命周期后，使用 Spring Bean 好比看到它们的行动轨迹，现在使用就一点都不慌了”。我和他一样，了解事物的生命周期目的很简单，唯【不慌】也 Java 并发系列 已经写了很多，从来还没提起过那个它【Java线程生命周期】。有了前序理论图文的铺垫，在走进源码世界之前，谈论它的时机恰好到了。因为，编写并发程序的核心之一就是正确的摆弄线程

并发编程为什么会有等待通知机制 上一篇文章说明了 Java并发死锁解决思路 ， 解决死锁的思路之一就是 破坏请求和保持条件, 所有柜员都要通过唯一的账本管理员一次性拿到所有转账业务需要的账本，就像下面这样： 没有等待/通知机制之前，所有柜员都通过死循环的方式不断向账本管理员申请所有账本，程序的体现就是这样： 1 2 while(!accountBookManager.getAllRequiredAccountBook(this, target)) ； 假如账本管理员是年轻小伙，腿脚利落（即执行 getAllRequiredAccountBook方法耗时短），并且多个柜员转账

* 你有一个思想，我有一个思想，我们交换后，一个人就有两个思想 * If you can NOT explain it simply, you do NOT understand it well enough 现陆续将Demo代码和技术文章整理在一起 Github实践精选 ，方便大家阅读查看，本文同样收录在此，觉得不错，还请Star🌟 之前写了几篇 Java并发编程的系列 文章，有个朋友微群里问我，还是不能理解 volatile 和 synchronized 二者的区别, 他的问题主要可以归纳为这几个： * volatile 与 synchron

写在前面 上一篇文章原子性问题的宏观理解 带领大家了解了锁和资源的模型，有了这篇文章的铺垫，相信理解这一篇文章就非常轻松了 当我们要保护单个资源并对其进行修改其实很简单，只需按照下图分三步走 1. 创建受保护资源 R 的锁 2. 加锁进入临界区 3. 解锁走出临界区 上图的关键是「R1 的锁保护 R1」的指向关系是否正确 如果都是保护单个资源这样简单，程序猿的世界该有多美好，可惜并不是，通常我们需要保护多个资源 保护多个资源 保护多个没有关系的资源 如果多个资源没有关系，那就是保护一个资源模型的复制，同样非常简单，且看下图: 比如现实中银行取款和修改密码操作。 银行取

写在前面 在 可见性有序性，Happens-before来搞定 文章中，happens-before 的原则之一: volatile变量规则 对一个 volatile 域的写, happens-before 于任意后续对这个 volatile 域的读 按理说了解了这个规则，对 volatile 的使用就已经足够了，但是面试官可是喜欢刨根问到底的，为了更透彻的了解 volatile 的内存语义与读写语义，为了面试多一些谈资进而获得一些加分项，同时尽早填补前序文章留下的坑，于是乎这篇文章就这样尴尬的诞生了 happens-before 之 volatile 变量规则 下面的表格你还记得吗？

上一篇文章 可见性有序性，Happens-before来搞定，解决了并发三大问题中的两个，今天我们就聊聊如何解决原子性问题 原子性问题的源头就是 线程切换，但在多核 CPU 的大背景下，不允许线程切换是不可能的，正所谓「魔高一尺，道高一丈」，新规矩来了: 互斥: 同一时刻只有一个线程执行 实际上，上面这句话的意思是: 对共享变量的修改是互斥的，也就是说线程 A 修改共享变量时其他线程不能修改，这就不存在操作被打断的问题了，那么如何实现互斥呢？ 锁 对并发有所了解的小伙伴马上就能想到 锁 这个概念，并且你的第一反应很可能就是使用 synchronized，这里列出来你常见的 syn