前言前不久帮同事一起 review 一个 job 执行缓慢的问题时发现不少朋友在撸码实现功能时还是有需要细节不够注意，于是便有了这篇文章。 ArrayList 踩坑1234567List<String> temp = new ArrayList() ;//获取一批数据List<String> all = getData();for(String str : all) &#

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

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

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

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

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

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

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

周末轻松一下。

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