同事发来一段代码，问为什么 127 和 128 结果不一样 万圣节前一天，隔壁工位刚转岗过来的同事在群里贴了这段代码： Integer a = 127; Integer b = 127; System.out.println(a == b); Integer c = 128; Integer d
一个订单对象序列化 100 万次，花了 4.2 秒 十月份做对账文件的导出，要把 100 万条订单转成 JSON 写到文件里。我用 Fastjson 1.2.49，代码就一行： String json = JSON.toJSONString(order); 跑完计时：4.2 秒。我当时觉得挺快了，
单线程也报 ConcurrentModificationException，我想了一晚上没想通 九月底做购物车清理，需求是把库存为 0 的商品从列表里剔掉。我写得很顺手： for (CartItem item : cartItems) { if (item.getStock() == 0)
put 进去的东西，get 出来是 null 8 月中旬写购物车合并逻辑，用了一个 Map<SkuKey, Integer> 统计数量。代码逻辑很简单，先把老购物车的商品塞进 map，再遍历新购物车累加： Map<SkuKey, Integer> countMap = new HashMap<>()
Too many open files：明明用了 try-with-resources 那是个导出功能，把订单导成 CSV 文件。上线第二天下午，监控开始报 java.io.IOException: Too many open files，接口全挂。登上机器一看，重启就好了，过一天又来。 我先去查系
用 Stream 写的统计，结果是错的 Java 8 的 Stream 我从去年开始用，写起来确实爽，但这段时间接连踩了几个坑，都是"能编译、能运行、结果不对"那种，比直接报错更难查。记一下。 坑一：Stream 只能用一次 第一次遇到是这段代码： Stream<Order> stream = or
我写的 180 行 if-else 被 review 打回了 上周做了个订单状态流转的需求，我吭哧吭哧写完，自我感觉良好地提了 MR。师傅留了一条评论："状态机别这么写，用枚举。" 先看看我交上去的东西： @Service public class OrderStateService {
客服说：订单创建时间显示成了 1970 年 5 月 14 号早上，客服群里转过来一张用户截图，订单详情里的创建时间是 1970-01-01 08:00:00。我第一反应是数据库存了 0，查了一下，数据库里的时间戳完全正常。 那就是显示的时候格式化错了。去看那段代码： @Service public
优惠券金额半夜自己变了 4 月 27 号凌晨一点，我被电话叫醒。客服说有用户投诉：领的 20 元券，下单时变成 5 元了。我爬起来查数据库，发现那批用户券的金额字段确实从 20 变成了 5，而且更新时间不是操作时间。 翻代码的时候找到了这段： // 从配置里取出默认的券模板 CouponTempla
导出功能上线，CPU 直接干到 780% 新做的对账单导出上线第一天，监控图上 CPU 从 15% 一条直线拉到 780%（8 核机器）。同一个时间点 Full GC 频率从每小时 2 次变成每分钟 30 多次。导出的文件也就 4MB 大小，不至于。 我用 jstack 抓了几把线程，大量线程停在这
