Java集合类从Vector换成ArrayList因Vector方法全加synchronized致单线程吞吐降30%以上，且其capacityIncrement难预测；ConcurrentHashMap的computeIfAbsent禁放阻塞操作以防桶锁雪崩；SimpleDateFormat不可重入而DateTimeFormatter不可变；StructuredTaskScope仅适用于短生命周期强依赖任务，不可替代ExecutorService。
Java集合类为什么从Vector换成ArrayList？
因为Vector所有方法都加了synchronized，但实际业务里绝大多数场景不需要全表锁——它让单线程吞吐直接掉30%以上。你真需要线程安全，应该按需加锁或换Collections.synchronizedList，而不是默认背一个重锁。
常见错误现象：Vector在循环遍历时抛ConcurrentModificationException，不是因为“多线程”，而是因为单线程里边遍历边remove——这点和ArrayList完全一致，别被名字骗了。
- 使用场景：老项目维护时看到
Vector，优先考虑替换为ArrayList，再单独评估是否需要同步包装 -
Vector的capacityIncrement参数几乎没人调，扩容逻辑反而比ArrayList更难预测 - JDK 21里
Vector仍是public，但Javadoc明确写了“This class is thread-safe but inefficient”
ConcurrentHashMap的computeIfAbsent为什么不能放阻塞操作？
它底层用的是分段锁+CAS，整个计算过程会一直持有对应桶的锁。如果你在里面做HTTP请求、数据库查询或者Thread.sleep(1000)，等于把整个桶卡死，其他线程对这个桶的所有读写都会排队等你——性能雪崩就是这么来的。
常见错误现象：压测时QPS突然断崖下跌，监控显示ConcurrentHashMap的get平均延迟飙升到秒级，但CPU不高，大概率是computeIfAbsent里塞了IO。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：只放纯内存计算，比如字符串拼接、对象构造；IO类逻辑提前算好再传入
- 如果必须懒加载远程数据，改用双重检查+普通
HashMap+synchronized块，自己控制锁粒度 -
computeIfAbsent返回null会被存进去，别指望它跳过——这是最容易漏掉的空指针陷阱
为什么java.time包上线后，SimpleDateFormat还总出错？
因为SimpleDateFormat不是线程不安全，它是「不可重入」：哪怕单线程反复调用parse，只要中间穿插了setLenient(false)之类的状态变更，结果就可能错乱。而java.time里的DateTimeFormatter是真正不可变的，能当常量静态复用。
常见错误现象：时间解析偶尔把"2023-02-30"当成合法日期（没开lenient却没报错），或者并发下解析出"2025-13-01"这种不存在的日期。
- 使用场景：所有新代码禁止出现
new SimpleDateFormat，统一用DateTimeFormatter.ofPattern("yyyy-MM-dd") -
DateTimeFormatter的parse默认严格模式，要兼容宽松解析得显式调用withResolverStyle(ResolverStyle.LENIENT) - 注意时区：
LocalDateTime.parse不带时区信息，想转ZonedDateTime必须显式atZone(ZoneId.systemDefault())
JDK 17+的StructuredTaskScope真能替代ExecutorService吗？
不能，它是为「短生命周期、强依赖关系、必须全部完成或一起失败」的子任务设计的，比如同时调用3个下游API，任一失败就立刻中断其余两个。而ExecutorService适合长期运行的任务队列、定时调度这些场景。
常见错误现象：用StructuredTaskScope跑一个每5分钟执行一次的定时任务，结果JVM无法退出——因为scope没close，子线程变成守护线程失败后还在挂起。
- 关键区别：
StructuredTaskScope的生命周期必须由调用方严格管理，try-with-resources是硬性要求 - 性能影响：它避免了线程池队列竞争，子任务直接在forkJoinPool里跑，但仅限于JDK 19+的预览特性转正版才稳定
- 别把它当
CompletableFuture的语法糖——错误处理模型完全不同，join会抛ExecutionException，不是CompletionException
复杂点在于：很多所谓“并发需求”其实混合了结构化依赖和非结构化长任务，这时候得拆成两层——外层用StructuredTaskScope管协调，内层用ExecutorService管执行，边界稍不注意就会泄露线程或锁住scope。
