string.intern() 仅在加载大量重复配置键名或枚举字面量、以及高频字符串等值判断且统一intern流程时才省内存；循环中对动态拼接字符串调用反而加剧内存压力。
String.intern() 什么时候真能省内存
多数人以为调用 intern() 就能自动去重、减少 GC 压力，实际常适得其反。它把字符串塞进 JVM 的运行时常量池（HotSpot 中是本地内存的字符串表），一旦引用没被及时清理，反而会拖慢 GC，甚至引发 OutOfMemoryError: Metaspace。
真正适合的场景只有两个：一是加载大量重复的配置键名或枚举字面量（比如 JSON 字段名、SQL 列名），且生命周期与应用一致；二是做高频字符串等值判断（== 替代 .equals()），但必须确保所有参与比较的字符串都走同一套 intern 流程。
- 不要在循环里对动态拼接的字符串（如
"user_" + id）调用intern()—— 每次都生成新对象再入池，白占空间 - JDK 7+ 后
intern()不再复制字符串到永久代，但字符串表本身无大小限制，默认也不扩容，容易哈希冲突变慢 - 替代方案更稳：用
ConcurrentHashMap<string string></string>自建缓存，显式控制大小和淘汰（比如 LRU）
BigDecimal 构造时别用 double 参数
new BigDecimal(0.1) 得到的是 0.1000000000000000055511151231257827021181583404541015625，不是你想要的“精确 0.1”。这是 IEEE 754 双精度浮点数二进制表示固有缺陷，BigDecimal 只是忠实地把那个不精确的 double 值转成十进制展示出来。
只要涉及金额、计费、科学计算等要求精确小数的场景，必须绕过 double 这一环。
立即学习“Java免费学习笔记（深入）”；
- 优先用字符串构造：
new BigDecimal("0.1")—— 字符串按字面量解析，无精度损失 - 整数运算可用
BigDecimal.valueOf(long)或BigDecimal.valueOf(double)，后者内部其实也是先转字符串再构造，比直接 new 安全 - 注意
valueOf(double)并非万能：传入0.1d仍会带误差，它只是对常见小数做了特例优化（比如 0.1、0.5），但不保证全覆盖
ArrayList 初始化容量该设多少
默认构造 new ArrayList() 分配 10 个元素空间，后续 add 超限时触发扩容：1.5 倍增长（JDK 17+ 改为 1.5 倍向上取整），每次都要数组拷贝。如果预估要存 1000 个元素，从 10 开始扩 8 次，光复制就超 1.5 万次引用赋值。
关键不是“要不要设”，而是“怎么设才不浪费”——设太大浪费堆内存，设太小又频繁扩容。
- 明确知道数量：直接传参，
new ArrayList(expectedSize) - 只知道范围（比如 500–2000）：按上限设，宁可略大，避免扩容；或者用
ensureCapacity()在首次批量 add 前补足 - 不确定数量但确定会 add 很多次（如日志收集）：考虑改用
ArrayDeque（无扩容开销，支持 O(1) 尾插）或流式处理（Stream.collect(Collectors.toList())内部会尝试预估）
Log4j2 异步日志为什么没变快
加了 AsyncLogger 却发现吞吐没涨、延迟反而波动更大，大概率是线程争用或缓冲区打满。Log4j2 的异步日志靠 RingBuffer（LMAX Disruptor 实现）跨线程传递日志事件，但这个缓冲区大小固定、生产者/消费者速度不匹配时会阻塞或丢日志。
它不是“开了就快”的开关，而是一组需要对齐的参数。
- 检查
log4j2.xml是否真启用了异步：需同时满足asyncLogger配置 +Disruptorjar 在 classpath（log4j-core依赖它） - 默认
RingBuffer大小是 2^16 = 65536，如果单条日志大或写入频率极高，缓冲区满后生产者线程会阻塞（BlockingWaitStrategy）或丢弃（DiscardingWaitStrategy） - 调优重点在
waitStrategy和ringBufferSize：高吞吐低延迟场景用YieldingWaitStrategy，配合ringBufferSize="131072"（2^17）；但要注意这会多占几 MB 堆外内存
性能调优最常被忽略的一点：所有“优化”都建立在真实压测数据之上。没测过 intern() 前后内存曲线、没抓过 GC 日志看 BigDecimal 构造频次、没用 JFR 看过 RingBuffer 消费延迟，那调整就只是碰运气。
