volatile不能替代synchronized，因其仅保证可见性与有序性（通过MESI缓存行失效），但不保证i++等复合操作的原子性；而synchronized通过monitorenter/monitorexit指令强制加锁并刷新整个工作内存，确保原子性。
Java 专家架构思维不是堆砌技术名词，而是把硬件缓存行为、JMM 抽象约束、字节码执行路径这三层真实物理/逻辑链路拧成一股力——系统性能瓶颈往往卡在这三者的错配点上。
为什么 volatile 不能替代 synchronized？看硬件缓存行与字节码指令的断层
volatile 修饰的变量写操作会触发 store + write + 缓存行失效（MESI 协议），但不保证原子性；而 synchronized 块在字节码层面生成 monitorenter/monitorexit 指令，强制线程获取 monitor 锁并刷新整个工作内存。常见错误是用 volatile 实现计数器（i++），它实际编译为 iload→iinc→istore 三步，中间任意一步都可能被其他线程打断。
- 真正需要原子读-改-写的场景，必须用
AtomicInteger（底层依赖Unsafe.compareAndSwapInt指令）或synchronized - volatile 适合状态标志位（如
running = false），且该变量不参与复合运算 - JIT 可能对 volatile 读做重排序优化（只要不违反 happens-before），但不会对
monitorenter做
堆内存分代设计如何匹配 CPU 缓存局部性？别只盯着 GC 日志
年轻代（Eden + Survivor）被设计得小而热，是因为新对象大多“朝生夕死”，且局部性高：连续分配的对象大概率落在同一缓存行内，CPU 预取和 TLB 命中率高；老年代则相反，对象存活久、分布散，TLB 压力大。G1 的 Region 划分本质是对这种局部性衰减的显式建模——每个 Region 独立回收，避免全堆扫描破坏缓存亲和性。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 如果发现
G1 Evacuation Pause中Copy阶段耗时突增，先查对象分配速率是否导致 Eden 区频繁溢出，而非直接调大堆 - 大对象（≥
-XX:G1HeapRegionSize）直接进 Humongous 区，会浪费整个 Region 空间，且易引发跨 Region 引用，破坏 G1 并发标记效率 - ZGC 的着色指针（colored pointer）把元数据塞进 64 位地址低 bits，省去额外的元数据表访问，直击 CPU cache line 带宽瓶颈
逃逸分析不是开关，是 JIT 对字节码控制流与对象生命周期的联合推理
JIT 编译器通过分析方法内对象的 new 指令是否“逃逸”出当前方法作用域（如被返回、存入静态字段、传给未知方法），决定能否做栈上分配（stack allocation）或锁消除（lock elision）。但这个推理高度依赖字节码结构：若方法有 try-catch 块且对象在其中创建，JIT 可能因异常路径不确定性放弃逃逸分析。
立即学习“Java免费学习笔记（深入）”；
-
-XX:+DoEscapeAnalysis默认开启，但仅当方法被 JIT 编译为 C2 代码（非 C1）时才生效 - 对象字段被 final 修饰且初始化在构造器内，有助于 JIT 推断其不可变性，提升逃逸分析成功率
- 使用
jstat -compiler查看 C2 编译队列积压情况，若大量方法未被编译，逃逸分析根本不会触发
真正的架构敏感点，藏在 JIT 如何把 invokevirtual 编译为单态内联、CPU 如何处理分支预测失败导致的流水线冲刷、以及 JMM 规则怎样被映射为 mfence/lfence 指令这些交汇处——它们不报错，但会让吞吐量掉 20%，延迟毛刺翻倍，而日志里只有一行平静的 GC 时间戳。
