做 Java 开发的程序员，大概率都接手过祖传老旧项目。这类项目普遍有几个典型特征：代码混乱无规范、嵌套冗余严重、数据库操作野蛮粗暴、无缓存、无异步、无性能监控，靠着“能跑就行”的准则苟活数年，随着业务数据量增长，性能问题彻底爆发。

做Java后端开发的同学，大概率都经历过凌晨线上告警轰炸的绝望：手机钉钉、短信、电话轮番震动，睡眼惺忪打开监控面板，映入眼帘的是一片红通通的告警色块、飙升的CPU、堆积的线程、超时的接口。

金九银十跳槽季，我面了一家一线互联网大厂的Java高级开发岗位，二轮技术面全程高能，没有八股文背诵、没有无用的框架堆砌，面试官全程只聚焦一个核心考点——Java线程安全底层实现与手写工具类。

在Java开发日常工作中，ArrayList几乎是所有开发者的默认集合首选。无论是存储业务数据、遍历列表、临时缓存对象，绝大多数人都会不假思索地写出List<T> list = new ArrayList<>()。在CRUD业务开发中，这种写法从未报错、简单易用，久而久之，ArrayList...

从事Java后端开发3年，参与过6个从0到1的企业级项目迭代，见过无数团队的技术选型闹剧：不管项目体量、不管业务复杂度、不管团队规模、不管流量高低，新项目一律无脑上SpringCloud微服务。

在绝大多数Java后端业务场景中，我们习惯性直接使用RocketMQ、Kafka、RabbitMQ等成熟开源消息中间件。这些组件经过多年迭代，性能、稳定性、可用性都经过了大厂海量流量打磨，足以支撑绝大多数企业级业务。但在我上次负责的高并发电商秒杀、订单异步核销、日志实时投...

“说一下你做过的JVM调优经验？” “生产环境OOM了怎么排查？” “G1和CMS有什么区别？怎么选择？” “年轻代和老年代比例怎么设置才合理？”