从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
面了三家公司，两次被问到"单例为什么要加 volatile" 十月中旬开始投简历试水，面试被问了三次单例模式。第一次我背出了双重检查锁的写法，面试官追问"为什么 instance 要加 volatile"，我卡住了，说了句"保证可见性"，他摇摇头。第二次还是同一个问题，我还是没答到点上。 回来自己翻
一个订单对象序列化 100 万次，花了 4.2 秒 十月份做对账文件的导出，要把 100 万条订单转成 JSON 写到文件里。我用 Fastjson 1.2.49，代码就一行： String json = JSON.toJSONString(order); 跑完计时：4.2 秒。我当时觉得挺快了，
那条跑了 4.7 秒的 SQL，我改了三个地方降到 23 毫秒 九月底，运营反馈"订单查询页面打不开"。我一看监控，那个列表接口的 TP99 从平时的 120ms 涨到了 4.7 秒，慢查询日志里刷了一屏同一条 SQL。 库是 MySQL 5.7.21，订单表 t_order 数据量 860 万。先
单线程也报 ConcurrentModificationException，我想了一晚上没想通 九月底做购物车清理，需求是把库存为 0 的商品从列表里剔掉。我写得很顺手： for (CartItem item : cartItems) { if (item.getStock() == 0)
第一次独立部署：catalina.out 里那几行看不懂的报错 九月份，师傅让我自己往测试服务器部署一次项目。我以为就是把 war 包扔进去，结果从下午两点折腾到晚上八点。这篇把我那天遇到的四个坑和后来整理的排查顺序记下来，免得下次再花六个小时。 环境：CentOS 7.4，JDK 8u151，To
凌晨两点的告警：Redis used_memory 撞到了 maxmemory 我们的 Redis 是 4.0.2，主从各 4G。某天凌晨收到告警，used_memory 冲到 3.9G，然后业务开始大面积报： redis.clients.jedis.exceptions.JedisDataExce
put 进去的东西，get 出来是 null 8 月中旬写购物车合并逻辑，用了一个 Map<SkuKey, Integer> 统计数量。代码逻辑很简单，先把老购物车的商品塞进 map，再遍历新购物车累加： Map<SkuKey, Integer> countMap = new HashMap<>()
本地跑得好好的，一上测试环境就 NoSuchMethodError 那次是给项目加了个 HTTP 工具类，本地单元测试全绿，提交完心情不错。结果测试环境部署完，一调用就炸： java.lang.NoSuchMethodError: org.apache.http.impl.client.Closea
压测数据打脸：我把 synchronized 换成 ReentrantLock，反而慢了 8 月份做优惠券发放模块，有个扣库存的临界区。师傅说了句"ReentrantLock 比 synchronized 快"，我就吭哧吭哧把代码全改了，还加了 finally 释放锁。结果自己压测一测，10 并发下
Too many open files：明明用了 try-with-resources 那是个导出功能，把订单导成 CSV 文件。上线第二天下午，监控开始报 java.io.IOException: Too many open files，接口全挂。登上机器一看，重启就好了，过一天又来。 我先去查系
前端同事贴了我的三个接口，问：这仨怎么都是 POST？ 刚入职那阵子我给订单模块写了几个接口，写完自我感觉良好。结果前端同事在群里贴了这么一串： POST /order/getOrderList POST /order/createOrder POST /order/updateOrderStatu
客服工单里的串号：A 用户看到了 B 用户的手机号 7 月初的一个下午，客服转过来一张截图：用户 A 在个人中心看到的手机号，是另一个用户的。我第一反应是不信，把那串号码脱敏后在库里一查，确实属于用户 B，两个人八竿子打不着。 我们那个接口长这样，用户信息是从一个 ThreadLocal 里取的，网
对账时发现：同一个事务里两次查询的结果不一样 上周做月底对账，写了个校验脚本：先统计账户表的总余额，再逐条核对流水，最后再统计一次总余额，看两次是否一致。结果两次统计的数字差了 3800 元。 我一开始以为是脚本 bug，查了半天才发现——脚本跑的过程中，有交易在实时发生，我第二次统计时读到了新提交
师傅甩给我一段 GC 日志，我一个字都看不懂 上个月排查一个接口抖动的问题，师傅在机器上敲了一串命令，屏幕上刷出这么一段东西： 2018-07-05T14:23:11.482+0800: 6.291: [GC (Allocation Failure) [PSYoungGen: 524288K->43
六月十三号上午，MySQL 被 3 万 QPS 打挂了 那天早上 9:07，我还在地铁上，DBA 的电话就打过来了："你们的库 CPU 100%，连接数打满，赶紧看看是不是缓存挂了。" 到公司一看监控，数据库 QPS 从平时的 800 飙到 31000，CPU 100%，连接数 500 打满，大量请
