必须重写 Product 的 equals() 和 hashCode() 方法，否则 list.contains() 等操作因默认比较对象地址而失效；查删改需规避空指针、越界及并发修改异常，推荐用 stream 查找、按属性删除、直接修改引用对象属性。
为什么不用 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()，若没重写就永远删不掉。
安全写法要主动校验：
立即学习“Java免费学习笔记（深入）”；
- 查单个商品：优先用
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。
