同事说"Lambda 就是匿名内部类的语法糖" 三月底做代码评审，我提了个建议说"这里可以用 Lambda 简化"。同事回了句："Lambda 不就是匿名内部类的语法糖吗，性能还差一点，没必要改。" 我说不上来哪里不对，但记得在哪看过说 JDK 8 的 Lambda 底层用的是 invokedyna
统计三月的订单，查出来是四月的 3 月中旬接了个老项目的改造任务，其中一块是给运营加个按月导出订单的功能。我写了个 SQL 拼时间的工具类，自测的时候点了三月，导出来的数据全是四月的。 当时那段代码： public static Date monthStart(int year, int month
一个 DTO 我写了 47 行 if 年前接手了一个商户入驻的接口，参数对象有 12 个字段，原来的校验代码长这样： public Result<?> apply(MerchantApplyDTO dto) { if (dto.getMerchantName() == null || dto
同事发来一段代码，问为什么 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 {
