1. JDK 版本号引发的血案
在 server 上把 JDK 版本从 1.8.231 升级成了 1.8.261，然后一个服务崩溃了……
大家一脸懵逼地查原因，兜兜转转无数层后，终与发现一个底层依赖的不知名 jar 包试图去获取 JDK 版本号，然而用了一个 byte 去存储这个版本号，然后因为 261 超出范围溢出了……溢出了……
2. 又一个 JDK 升级引发的血案
这个动作稍大点，把 JDK 从 1.6 升成了 1.8, 然后又一个服务崩溃了……这个查起来又费了半天劲，最终发现原因是原先不知谁写的，for 循环一个 HashMap，然而这个循环顺序竟然是有依赖关系的！也就是说必须先遍历某个元素才行。JDK 8 升级了 hash 函数，然后这个顺序就变了，然后就挂了……
3. 打 log 也能把程序内存打爆?
开发者都永远也想不到用户会怎么用他的程序。log4j 有一个功能，就是在 MDC 中设置用户自定义的属性，例如用户名，这样子在这个 session 内 log 内容就可以把用户名打在 log 中。结果一个天才发现了，这个 MDC 是同一 session 内可访问的耶，正好有些对象传递，但又不能改动接口，因为改接口影响太大，把 MDC 当成共享内存来用好了。恶例就此打开，更过分的是他还把这个写成了公用函数，别人以为这是啥高科技纷纷调用，后果可想而知，Java 程序员很少有删除对象的习惯，一开始大家还都没发现，直到很久以后，随着服务量逐渐攀升，终于有一天内存爆了。一群人排查了一整天才抓到罪魅祸首，如果不是那哥们儿已经跑路了可能会被打……
4. 又一个打 log 的奇葩 bug
有天觉得 log 打得太多了，就把 log level 从 debug 调到了 info，然后发现服务不可用了，这个倒定位得很快，发现了神人写的如下代码, 差不多像这面这样子：
log.debug("result count: " + dao.update());