前言前几日早上打开邮箱收到一封监控报警邮件：某某 ip 服务器 CPU 负载较高，请研发尽快排查解决，发送时间正好是凌晨。 其实早在去年我也处理过类似的问题，并记录下来：《一次生产 CPU 100% 排查优化实践》 不过本次问题产生的原因却和上次不太一样，大家可以接着往下看。

前言本篇是上一篇《一次分表踩坑实践的探讨》，所以还没看过的朋友建议先看上文。 还是先来简单回顾下上次提到了哪些内容： 分表策略：哈希、时间归档等。 分表字段的选择。 数据迁移方案。

前言前段时间写过一篇《线程池没你想的那么简单》，和大家一起撸了一个基本的线程池，具备： 线程池基本调度功能。 线程池自动扩容缩容。 队列缓存线程。 关闭线程池。

前言写这篇文章的前因是有位读者留言提到了相关的话题，其实在之前有一篇《如何成为一位「不那么差」的程序员》时有简要提到但没有细说；这次就借这个机会好好聊聊这个事情的前因后果。

前言原以为线程池还挺简单的（平时常用，也分析过原理），这次是想自己动手写一个线程池来更加深入的了解它；但在动手写的过程中落地到细节时发现并没想的那么容易。结合源码对比后确实不得不佩服 Doug Lea 。 我觉得大部分人直接去看 java.util.concurrent.ThreadPoolExecutor 的源码时都是看一个大概，因为其中涉及到了许多细节处理，还有部分 AQS 的内容，所以想要

前言经过几个小伙伴的提醒，发现个人博客中的许多图片都裂了无法访问；原因就不多说，既然出现问题就得要解决。

前言在面试过程中聊到并发相关的内容时，不少面试官都喜欢问这类问题： 当 N 个线程同时完成某项任务时，如何知道他们都已经执行完毕了。 这也是本次讨论的话题之一，所以本篇为『并发包入坑指北』的第二篇；来聊聊常见的并发工具。

周末轻松一下。

前言之前不少人问我“能否分享一些分库分表相关的实践”，其实不是我不分享，而是真的经验不多🤣；和大部分人一样都是停留在理论阶段。 不过这次多少有些可以说道了。 先谈谈背景，我们生产数据库随着业务发展量也逐渐起来；好几张单表已经突破亿级数据，并且保持每天 200+W 的数据量增加。 而我们有些业务需要进行关联查询、或者是报表统计；在这样的背景下大表的问题更加突出（比如一个查询功能需要跑好几分钟）。

前言较长一段时间以来我都发现不少开发者对 jdk 中的 J.U.C（java.util.concurrent）也就是 Java 并发包的使用甚少，更别谈对它的理解了；但这却也是我们进阶的必备关卡。 之前或多或少也分享过相关内容，但都不成体系；于是便想整理一套与并发包相关的系列文章。 其中的内容主要包含以下几个部分： 根据定义自己实现一个并发工具。 JDK 的标准实现。 实践案例。