一只叫煤球的猫

各位，这里是煤球，遥祝各位新年开工快乐！ 不知道你们拿到开工红包没？反正我是没有的 😭 。 前言 Java 8 引入 Lambda 至今已逾十年，它彻底改变了 Java 的编程风格。然而，很多团队在大

仍然保持 ThreadForge 的目标： 让 Java 能写出更简单、更可推理、更可观测的并发代码。这次版本，重点补齐了并发开发里几个还算常见的能力。

一个简单的「并发调用三个接口」，代码已经写了 50 多行。 并且下次遇到类似场景，还得把这些逻辑再写一遍：超时、取消、异常传播、资源清理……每次都要重新思考一遍边界条件。 传统的 `Execu

我一个臭写 Java 的，怎么半数时间在写XML。有个复杂的查询，当我熟练地打开一个几百行的 XML，准备第N次敲下 <where> 和 <if test="..."> 时，突然愣神了。

分页查询最常见的写法是 LIMIT + OFFSET： 在数据量小的时候它很正常；但是数据量到千万级后，它会变得越来越慢，常见表现是延迟随页码增长明显上升，CPU/IO 抖动，甚至出现临时表落盘。

阿城最近在我的熏陶下，喜欢看各种文章和代码。 那天他给我发了一个代码截图，附带着几句话： “哥你看，这段 sendCode 写得挺清爽的，但是我咋看着不对劲呢” “短信验证码这种接口，就这么暴露

昨天在Code Review时，我发现阿城在Service层直接返回了Result对象。 指出这个问题后，阿城有些不解，反问我为什么不能这样写。 于是我们展开了一场技术讨论（battle 🤣）。

看过我之前文章的朋友应该知道，我现在一家小公司做中层管理，带着研发部门二十多个人。 平时既做管理工作，也会写点代码。 但是始终不太擅长管理。 早上九点不到，坐在工位上，先泡上一杯咖啡，打开电脑。 飞书

很多时候我们拿到一段串行代码，第一反应就是看能不能改成并行，觉得多线程跑起来肯定快。但个别情况下，改完之后不仅不会变快，可能还会比原来还慢。问题出在哪里？线程池不够大吗？还是机器配置太低吗？其