JDK

结论先行 JDK 8 起 "java.util.Random" 已经不再用 "synchronized"，但它内部是一个 "AtomicLong" 上的 CAS 循环——共享一个 "Random" 实例在多线程热路径上依然会串行化，只是从「

«结论先行：K8s 里 CoreDNS 抖 8 秒，Go/Python 服务完全无感，Java 服务却持续 30 秒报 "UnknownHostException"——差 3.6 倍，锅不在网络、不在 CoreDNS，而在 JDK 自己的

«结论先行：一台 NIO 网关"零请求、单核 100% CPU"，第一嫌疑不是业务代码，而是 JDK 在 epoll 平台上的 Selector 空转缺陷（JDK-6670302）——"select()" 在没有事件时频繁空醒，把 "epo

«结论先行："Too many open files" 很少是「一个 bug」，它通常是三件事叠加——代码异常路径没 close（漏 fd）+ 进程 "ulimit -n" 软上限被设得太低（把正常用量放大成事故）+ 监控只盯 CPU/内存

结论先行 JDK 8u131 及更早版本（x86 + Linux epoll）存在一个 Selector 空轮询 bug（JDK-6670342）："Selector.select()" 在没有事件时仍立即返回，导致 "select → 判