Java核心知识点自测：JVM与并发模型解析

本文深入剖析Java核心机制中的四大关键知识点——String与StringBuilder的不可变性差异及性能陷阱、HashMap在JDK 8中链表转红黑树阈值为8的数学依据与实战误区、synchronized底层锁对象本质及常见并发误用、ThreadLocal内存泄漏的真实根源与线程池下的规避策略，不仅讲清“是什么”和“为什么”，更聚焦真实压测与线上故障场景（如老年代突增、GC异常、OOM），帮你把零散知识点串联成可诊断、可决策的技术直觉——真正掌握Java，不是背答案，而是在问题发生的毫秒级响应中，精准定位那个被忽略的hashCode、未remove的ThreadLocal，或错误共享的锁对象。

为什么 String 是不可变的，而 StringBuilder 不是

因为 String 的底层 value 字节数组被 final 修饰，且所有修改操作（如 substring、concat）都返回新对象；StringBuilder 的 value 数组可被原地修改，扩容时才新建数组并复制。

常见错误现象：String s = "a"; s += "b"; 看似“修改”，实际创建了两个对象，容易在循环拼接中引发内存浪费；而 StringBuilder 在单线程场景下应优先用于频繁拼接。

• 使用场景：日志拼接、SQL 构建、模板渲染等需多次追加字符串的地方，选 StringBuilder；配置项、键名、常量等只读用途，用 String
• 参数差异：StringBuilder 构造时传初始容量（如 new StringBuilder(128)）能避免多次扩容，尤其当长度可预估时
• 性能影响：循环中用 + 拼接 1000 次字符串，比等效的 StringBuilder 慢 5–10 倍（JDK 8+ 有编译器优化，但仅限于编译期确定的字符串常量表达式）

HashMap 在 JDK 8 中的链表转红黑树阈值为什么是 8

这个阈值不是拍脑袋定的，而是基于泊松分布推导出的：当哈希碰撞后链表长度达到 8，发生这种情况的概率已低于千万分之一——说明大概率不是偶然哈希冲突，而是哈希函数失效或恶意攻击，此时转红黑树能将最坏查找从 O(n) 降到 O(log n)。

常见错误现象：自定义 Key 类只重写了 equals 却忘了重写 hashCode，导致本该命中同一个桶的元素散落各处，看似“没进树”，实则根本没形成链表；或者误以为设了 loadFactor=0.5 就能阻止树化——其实树化只看桶内链表长度，和负载因子无关。

• 使用场景：高并发读写且 Key 哈希分布不均（如用时间戳做 Key、或大量相似字符串）时，要注意是否触发树化；可通过 jdk.internal.vm.annotation.Contended 缓解伪共享，但需开启 JVM 参数
• 兼容性影响：JDK 7 的 HashMap 没有红黑树，扩容时链表会倒序插入，可能引发死循环（多线程未同步时）；JDK 8 改为正序，但依然不保证线程安全
• 注意：treeify_threshold 是静态常量，无法运行时修改；若想禁用树化，只能自己继承并覆盖 treeifyBin 方法（不推荐）

为什么 synchronized 锁的是对象，而不是代码块或方法签名

因为 JVM 层面的锁本质是对象头里的 mark word，它记录锁状态（无锁、偏向、轻量、重量）、线程 ID 或 Monitor 地址；所谓“锁方法”，只是编译器把隐式锁对象（实例方法是 this，静态方法是 Class 对象）插进了字节码的 monitorenter/monitorexit 指令。

常见错误现象：用 synchronized(list) 同步一个外部传入的 List，结果别人也在同一对象上加锁，造成意外阻塞；或在单例类里对局部变量加锁（如 synchronized(new Object())），完全无效。

• 使用场景：保护共享状态时，锁对象必须是所有竞争线程都能访问到的**同一个引用**；缓存场景常用 synchronized(map)，但更稳妥的是用 ConcurrentHashMap
• 参数差异：锁对象不能为 null，否则抛 NullPointerException；也不能是基本类型包装类（如 Integer.valueOf(127)），因为小整数会缓存复用，不同逻辑可能无意共用锁
• 性能影响：过度细粒度（如每个元素一把锁）增加锁开销；过度粗粒度（如整个集合一把锁）又限制并发度；折中方案常是分段锁（ConcurrentHashMap 的 Segment 已被废弃，现用 Node 数组 + CAS + synchronized 协同）

ThreadLocal 内存泄漏的根本原因和规避方式

泄漏不在 ThreadLocal 变量本身，而在它的内部类 ThreadLocalMap 中，Entry 继承了 WeakReference，key（即 ThreadLocal 实例）是弱引用，但 value 是强引用；当 ThreadLocal 被回收后，key 为 null，但 value 仍被 Entry 持有，直到线程结束或主动 remove()。

常见错误现象：Web 容器中用 ThreadLocal 存用户上下文，请求结束后没调 remove()，线程被池复用后，旧 value 一直占着堆内存，最终 OutOfMemoryError: Metaspace 或堆溢出。

• 使用场景：框架级透传（如 TransactionSynchronizationManager、MDC 日志上下文）必须配对使用 try-finally 块确保 remove()
• 规避方式：ThreadLocal 声明为 static final，避免被意外置为 null 导致 key 提前回收；每次 set() 前先 remove()（尤其在线程池场景）
• 注意：ThreadLocal 的 initialValue() 只在第一次 get() 时调用，若中间 remove() 过，下次 get() 会重新触发初始化——这可能掩盖状态残留问题

事情说清了就结束。真正难的不是记住“8 是树化阈值”或“ThreadLocal 要 remove”，而是你在压测时看到 GC 日志里老年代突然涨了一大截，得立刻反应过来是不是某个 ThreadLocal 忘清理了，或者那个 HashMap 的 Key 其实没重写 hashCode。

终于介绍完啦！小伙伴们，这篇关于《Java核心知识点自测：JVM与并发模型解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！