String、ArrayList、HashMap 这些基础类，什么时候用错最伤性能

很多人学 Java 时，最先熟悉的就是 String、ArrayList、HashMap 这些基础类。也正因为太熟了，项目里反而经常是在它们身上出问题。不是因为类本身复杂，而是因为大家太容易“顺手就用”，很少停下来想当前场景到底合不合适。

我后来复盘一些性能问题时，发现真正的教训往往不是某个高深框架，而是这些基础选择从一开始就偏了。

String 什么时候最容易被误用

如果在循环里频繁拼接、在日志和 SQL 拼装里层层叠加字符串，String 的成本会被放大得很明显。
单次看不出什么，放进高频路径以后，内存分配和对象数量都会变得难看。

问题不在于 String 不能用，而在于“高频可变文本处理”本来就不是它最擅长的场景。

ArrayList 为什么常常被想当然地滥用

ArrayList 很通用，也确实应该成为默认选择之一。
但一旦场景变成：

• 频繁在头部插入
• 中间位置大量删除
• 列表规模长期不可控

它就不再只是“顺手的集合”，而会开始暴露扩容、搬移元素这些隐藏成本。

很多人知道这个知识点，但真正写业务时还是会忘，因为默认工具太熟了。

HashMap 的问题通常出现在“边界没有收住”

HashMap 好用到几乎什么都能装，于是它也最容易被当成临时黑箱。
一层一层往里塞数据、把动态结构一路传下去，短期开发很快，长期维护却会越来越难。

从性能角度看，键设计不稳定、对象层级太深、Map 嵌 Map 过多，都会让调试和序列化成本一起抬高。
从可维护性看，它还会吞掉类型信息，让很多错误直到运行时才冒出来。

我现在更在乎的不是“会不会用”，而是“为什么用”

这几个类都没有错，错的是在不合适的地方把它们当默认答案。
我后来写 Java 时，会更刻意地问自己：

• 这里的数据结构是稳定的吗
• 这里会不会高频修改
• 这里需不需要更明确的类型边界

只要这三个问题先问出来，很多选择就不会那么随手。

小结

基础类不是新手知识，恰恰是工程实践里最容易被低估的部分。
2017 年之后我越来越相信，很多性能和可维护性问题并不是从复杂框架开始的，而是从最熟悉的几个类被“想都没想就用了”开始的。