String不可变因其value数组被final修饰且操作均返回新对象；StringBuilder的value可原地修改，扩容时才新建数组。
为什么 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 就能阻止树化——其实树化只看桶内链表长度，和负载因子无关。
立即学习“Java免费学习笔记（深入）”；
- 使用场景：高并发读写且 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()会重新触发初始化——这可能掩盖状态残留问题
ThreadLocal 要 remove”，而是你在压测时看到 GC 日志里老年代突然涨了一大截，得立刻反应过来是不是某个 ThreadLocal 忘清理了，或者那个 HashMap 的 Key 其实没重写 hashCode。 
