JavaArrayList商品管理实战教程

本文深入剖析了Java中使用ArrayList管理商品时的常见陷阱与最佳实践，重点揭示了为何必须重写Product类的equals()和hashCode()方法——否则contains()、remove()等操作将因默认比较对象地址而失效，导致“明明存在却查不到、删不掉”的业务异常；同时系统梳理了增删改查各环节的安全写法：用Stream查找避免索引越界、用removeIf替代手动遍历删除以防并发修改异常、直接修改对象属性而非重复添加以利用引用特性，并警示可变字段参与hashCode计算带来的潜在风险，为开发者提供了一套兼顾正确性、健壮性与性能的商品集合管理方案。

为什么不用 ArrayList 直接存商品对象就出问题？

直接 new ArrayList() 存 Product 对象本身没问题，但后续查、删、改时容易因引用混乱或未重写关键方法而失效。典型表现是：list.contains(new Product("iPhone", 5999)) 返回 false，哪怕列表里真有同名同价的商品。

根本原因在于：默认的 equals() 和 hashCode() 比较的是对象地址，不是业务意义上的“相同商品”。必须在 Product 类中重写这两个方法，且逻辑要一致——比如按 id 判等（若无 ID，则用 name + price 组合）。

• 不重写 hashCode() → HashSet 或作为 HashMap 的 key 时行为异常
• 只重写 equals() 不重写 hashCode() → 违反 Java 合约，集合操作不可预测
• 用可变字段（如 price）参与 hashCode() 计算 → 对象加入 ArrayList 后修改价格，不影响列表本身，但若之后放进 HashMap 就可能找不到

增删改查怎么写才不踩空指针和越界坑？

ArrayList 的 get(int index) 和 remove(int index) 在索引越界时抛 IndexOutOfBoundsException，而不是静默失败；而按对象删除（remove(Object o)）会调用 equals()，若没重写就永远删不掉。

安全写法要主动校验：

• 查单个商品：优先用 stream().filter().findFirst()，避免手写循环+下标管理；若必须用索引，先判断 index >= 0 && index
• 删商品：用 removeIf(p -> p.getId().equals(id))，比遍历后调 remove(i) 更安全（后者易因并发修改导致 ConcurrentModificationException）
• 改价格：不要 list.get(i).setPrice(newPrice) 后再“重新放回去”——ArrayList 存的是引用，改属性即生效，无需 replace
• 批量导入：用 addAll(Collection extends E>)，别用循环反复 add()，后者在大量数据下性能差（多次扩容）

搜索功能用 contains 还是 stream？

contains() 底层就是遍历调 equals()，和手写 for 循环效率一样，但语义更清晰；stream 适合带条件组合的查找（如“价格 5 的手机”），但简单存在性判断没必要上 Stream——它有创建开销，且对小列表（

实际选型看场景：

• 只问“有没有某 ID 的商品？” → 用 list.contains(targetProduct)（前提是 Product.equals() 已正确定义）
• 要找所有“名称含‘Pro’的商品” → 用 list.stream().filter(p -> p.getName().contains("Pro")).collect(Collectors.toList())
• 要找第一个匹配项并提前退出 → list.stream().filter(...).findFirst().orElse(null)，比 for 循环少写几行，可读性更好
• 频繁按 ID 查找 → ArrayList 不是最佳结构，应补一个 Map 做索引，否则每次都是 O(n)

多线程环境下直接用 ArrayList 会怎样？

它不是线程安全的。两个线程同时执行 add()，可能触发内部数组扩容（Arrays.copyOf()），而复制和赋值不是原子操作，会导致部分元素丢失或 size 错乱，甚至抛 ArrayStoreException 或 NullPointerException。

除非系统明确是单线程（如命令行小工具），否则必须处理：

• 临时方案：用 Collections.synchronizedList(new ArrayList())，但仅保证单个方法原子性；复合操作（如“检查是否存在，不存在则添加”）仍需手动加 synchronized 块
• 推荐方案：改用 CopyOnWriteArrayList，适合读多写少（如商品列表展示频繁、后台定时刷新）；但写操作代价高（每次 add 都复制整个数组）
• 更优解：把商品管理封装成服务类，内部用 ArrayList + 显式锁（ReentrantLock），控制临界区粒度，比同步整个列表更高效

真正麻烦的不是并发修改异常本身，而是它不一定立即暴露——可能压测时才偶发，线上跑一周才出一次数据错乱。所以设计阶段就要决定线程模型，别等上线后补 synchronized。

本篇关于《JavaArrayList商品管理实战教程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！