现陆续将Demo代码和技术文章整理在一起 Github实践精选 ，方便大家阅读查看，本文同样收录在此，觉得不错，还请Star🌟 看到本期内容这么少，是不是心动了呢？ 前言 上一篇万字长文 Java AQS队列同步器以及ReentrantLock的应用 为我们读 JUC 源码以及其设计思想做了足够多的铺垫，接下来的内容我将重点说明差异化，如果有些童鞋不是能很好的理解文中的一些内容，强烈建议回看上一篇文章，搞懂基础内容，接下来的阅读真会轻松加愉快 AQS 中我们介绍了独占式获取同步状态的多种情形： * 独占式获取锁 * 可响应中断的独占式获取锁 * 有超时限制的独占式获

写在前面 进入源码阶段了，写了十几篇的 并发系列 知识铺垫终于要派上用场了。相信很多人已经忘了其中的一些理论知识，别担心，我会在源码环节带入相应的理论知识点帮助大家回忆，做到理论与实践相结合，另外这是超长图文，建议收藏，如果对你有用还请点赞让更多人看到 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 作为我们走进并发编程源码环节的

最近在陆续写 Java 并发编程系列，好多朋私信问我的不是并发内容本身，而是我的 IDEA 主题配置。我就姑且认为好的主题配置可以写出更好的并发程序吧 即便这种可能性只有万分之一，我也要把我的 IDEA 相关值得配置的内容/插件和大家分享出来 先来一张我的 IDE 截图，有你看中的地方吗？ 插件篇 好用的插件总是让人： 神清气爽，精神抖擞 ，丰神异彩，炯炯有神，神采奕奕，气贯长虹 ，英姿飒爽，精神焕发 下面所有插件都可以按照文中标注的名称在 IDEA 插件市场中直接搜索并安装 Material Theme UI Material Theme UI 在主题下载量排行榜中高居第一

上一篇文章 面试问我，创建多少个线程合适？我该怎么说 从定性到定量的分析了如何创建正确个数的线程来最大化利用系统资源（其实就是几道小学数学题）。通常来讲，有了个这个知识点傍身，按需手动创建相应个数的线程就好 但是现实中，你也许听过或者被要求： 尽量避免手动创建线程，应使用线程池统一管理线程 为什么会有这样的要求？背后的道理又是怎样的呢？顺着这个经验理论来推断，那肯定是手动创建线程有缺点 手动创建线程有什么缺点？ 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

项目需要，我需要储备一些Node.js 相关的知识了，整体感觉是一件好事 背景 从前，我也写过前端，不过那会最多用到HTML5 +jQuery相关技术。也没有准确的时间点来划分，我就忽忽悠悠的专注于Java后端了 像现在的大前端Angular、VUE、REACT这些大前端框架我只是略有了解，完全没有用过，用Node作为中间服务器也是相对陌生状态，项目中需要，我是一定不会放过这个可以掉头发的良机（想法很简答， 跳出自己的舒适区） 毕竟要在实际项目中写Node代码的，这么严峻的问题我是要认真对待的，要不然会让队友消耗太多 WTFs/min 能量（这是什么含义？请看【读《Clean C