Java 集合遍历删除,最怕的是看起来能跑
· 阅读需 2 分钟
Java 集合遍历删除这个问题,很多人都知道有坑。
可真正麻烦的地方在于,它不是每次都立刻用最醒目的方式出错。有些代码在某个数据量、某种路径下能跑,看起来像是可用的,结果一换场景就开始报错或者漏删,这种“看起来能跑”的状态反而最危险。
Java 集合遍历删除这个问题,很多人都知道有坑。
可真正麻烦的地方在于,它不是每次都立刻用最醒目的方式出错。有些代码在某个数据量、某种路径下能跑,看起来像是可用的,结果一换场景就开始报错或者漏删,这种“看起来能跑”的状态反而最危险。
很多人学 Java 时,最先熟悉的就是 String、ArrayList、HashMap 这些基础类。也正因为太熟了,项目里反而经常是在它们身上出问题。不是因为类本身复杂,而是因为大家太容易“顺手就用”,很少停下来想当前场景到底合不合适。
Java 项目里很容易出现一种“看上去很稳”的异常处理:每一层都在 catch,每一层都在包一层自己的提示,最后用户确实看不到原始异常了,但开发排查时也很难再看到真正的现场。
2017 年我在处理一些线上问题时,对这一点的体会越来越深。
“接口和抽象类怎么选”几乎是每个 Java 学习阶段都会碰到的问题。
很多回答会从语法、继承、默认实现这些点切入,这些都没错。但 2017 年我在项目里慢慢形成的判断是:真正决定选择的,常常不是当前写起来哪个方便,而是未来变化会往哪个方向长。
Java 8 刚出来那阵,很多人讨论接口默认方法,讨论点常常是“它是不是打破了接口的纯粹性”。我后来在项目里真正用过几次后,反而觉得更实际的问题是:哪些重复代码适合放进去,哪些不适合。
2016 年接手 Java 项目时,我遇到过一种很典型的混乱:同样是处理用户逻辑的类,有的叫 UserDao,有的叫 UserMapper,有的叫 UserServiceImpl,还有的直接叫 UserManager。项目还能跑,但只要需求稍微一变,大家就会先花时间猜“这个类到底管什么”。