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

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

有朋友私信问我如何安排日常，以及相对高效的写东西？我觉得有必要单独写一篇文章来和大家交流这个事 不做没有灵魂的 TODO List 我们都是上进的好青年，大家手里应该都有自己的 TODO list，我通常会用 Microsoft To Do 这款软件做简单的日常安排 求学期间，每个寒暑假临近，我都可以把做各种 plan，立各种 flag 的气质拿捏的死死的。如你所料，假期过后一个 plan 都没有做，一个 flag 都没有完成。 这种表面风光，实则没有了灵魂TODO list 只是短期心理慰藉，当需要验证结果时，情绪轻则低落一会，重则焦虑半天 造成这种问题的原因很简单 * 大杂

为什么要使用多线程？ 防止并发编程出错最好的办法就是不写并发程序 既然多线程编程容易出错，为什么它还经久不衰呢？ 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

本已将PMP考试记录在2019年年终总结的事件之一里了，春节有朋友问我，想让我分享一下，我回想了整个过程还是挺有趣的，于是本文就以纪实的形式写写考PMP的那点事，有兴趣的可以私聊，避免说广告 PMP（Project Management Professional）学名「项目管理专家」，我叫它「拍马屁」。2019年4月的时候在朋友圈看到有两位朋友先后【注意是先后，有埋伏】晒出来PMP的证件出来，看着挺好看的（文末有，还是纪念版，这个理由好牵强），就果断去骚扰了他们询问具体情况 朋友A：有的公司认可这个证件，没事考个还挺有用的。 朋友B：考试险过，不知道有没有用，有朋友考，一起跟着考了 心

* 你有一个思想，我有一个思想，我们交换后，一个人就有两个思想 * If you can NOT explain it simply, you do NOT understand it well enough 现陆续将Demo代码和技术文章整理在一起 Github实践精选，本文同样收录在此，方便大家阅读查看，觉得不错，还请Star🌟 日常工作对集合操作真的太频繁了，前端时间就写过一篇关于Java 12 集合的文章 Java12 Collectors.teeing 的使用详解 ， 有朋友留言说这个功能比较好用。个人觉得 Java12还有几个特性可以尝试