前言

前几天在测试环境碰到一个非常奇怪的与 dubbo 相关的问题，事后我在网上搜索了一圈并没有发现类似的帖子或文章，于是便有了这篇。

希望对还未碰到或正在碰到的朋友有所帮助。

前言

前不久帮同事一起 review 一个 job 执行缓慢的问题时发现不少朋友在撸码实现功能时还是有需要细节不够注意，于是便有了这篇文章。

ArrayList 踩坑

1
2
3
4
5
6
7

List<String> temp = new ArrayList() ;

//获取一批数据
List<String> all = getData();
for(String str : all) {
	temp.add(str);
}

首先大家看看这段代码有什么问题嘛？

前言

前几日早上打开邮箱收到一封监控报警邮件：某某 ip 服务器 CPU 负载较高，请研发尽快排查解决，发送时间正好是凌晨。

其实早在去年我也处理过类似的问题，并记录下来：《一次生产 CPU 100% 排查优化实践》

不过本次问题产生的原因却和上次不太一样，大家可以接着往下看。

前言

本篇是上一篇《一次分表踩坑实践的探讨》，所以还没看过的朋友建议先看上文。

还是先来简单回顾下上次提到了哪些内容：

• 分表策略：哈希、时间归档等。
• 分表字段的选择。
• 数据迁移方案。

前言

前段时间写过一篇《线程池没你想的那么简单》，和大家一起撸了一个基本的线程池，具备：

• 线程池基本调度功能。
• 线程池自动扩容缩容。
• 队列缓存线程。
• 关闭线程池。

前言

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

前言

原以为线程池还挺简单的（平时常用，也分析过原理），这次是想自己动手写一个线程池来更加深入的了解它；但在动手写的过程中落地到细节时发现并没想的那么容易。结合源码对比后确实不得不佩服 Doug Lea 。

我觉得大部分人直接去看 java.util.concurrent.ThreadPoolExecutor 的源码时都是看一个大概，因为其中涉及到了许多细节处理，还有部分 AQS 的内容，所以想要理清楚具体细节并不是那么容易。

前言

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

前言

在面试过程中聊到并发相关的内容时，不少面试官都喜欢问这类问题：

当 N 个线程同时完成某项任务时，如何知道他们都已经执行完毕了。

这也是本次讨论的话题之一，所以本篇为『并发包入坑指北』的第二篇；来聊聊常见的并发工具。

周末轻松一下。