不能将长生命周期迭代器缓存到threadlocal中，因其持有容器引用、含可变状态，多请求复用线程时会导致串号和内存泄漏；修复需禁用该用法，改用无状态参数或轻量标记，并严格清理。
不能把长生命周期迭代器缓存到 ThreadLocal 中——这不是“排查手段”，而是典型的泄漏源头。所谓“变量串号”和“内存泄漏”，往往正是这种用法直接导致的。
为什么迭代器放进 ThreadLocal 会串号
迭代器（如 ArrayList.iterator()、HashMap.entrySet().iterator()）本身持有对容器状态的引用，且多数是非线程安全、有内部游标（cursor）、modCount 等可变字段的对象。一旦被塞进 ThreadLocal：
- 多个请求复用同一线程时，前一个请求留下的迭代器未清理，后一个请求调用 get() 拿到的仍是旧迭代器；
- 若该迭代器已遍历到中间位置，下次再 next() 就可能抛
NoSuchElementException或返回错误元素； - 更隐蔽的是：若迭代器引用了原始集合（尤其带闭包或匿名类的 Stream 迭代器），还会意外延长整个业务对象生命周期，造成“伪串号”——比如日志里看到 A 用户的 ID 出现在 B 用户的上下文中。
为什么必然引发内存泄漏
迭代器本身虽小，但它强引用着背后的集合、元素甚至整个 Service 实例（例如通过 lambda 捕获 this）。而 ThreadLocal 的 value 是强引用，key（ThreadLocal 实例）却是弱引用：
- 当 ThreadLocal 变量被回收（如 Spring Bean 销毁、Filter 类卸载），key 变成 null，Entry 成为“幽灵条目”；
- 但迭代器及其引用链上的大对象（如 10MB 的 List
）仍牢牢卡在 ThreadLocalMap 里； - 在线程池场景下，一个 Tomcat 工作线程存活数小时，这类条目就堆积数小时——MAT 中常看到成百上千个
java.util.ArrayList$Itr占据老年代。
真正有效的排查与修复路径
不要试图“缓存迭代器”，要定位它从哪来、为何没清、是否真需要：
-
堆转储聚焦分析：用
jmap -dump抓 heap.hprof，MAT 中执行 OQL：
SELECT * FROM java.util.ArrayList$Itr WHERE (OBJECTS this.array) != null
再检查其array字段是否指向你业务中的大集合； -
代码扫描重点位置：搜索
iterator()、.spliterator()、Stream.of(...).iterator()出现在 ThreadLocalset()前后的代码块；特别注意 Filter、Interceptor、AOP 切面中是否在 doFilter/afterCompletion 里漏掉remove()； -
替换方案必须落地：
• 迭代逻辑改造成无状态方法参数传递（如传 index + list）；
• 若需跨方法维持遍历进度，改用轻量级标记（如
AtomicInteger position）而非持有一个完整迭代器； • 确实要缓存中间结果？用局部变量或 request-scoped bean，绝不放入 ThreadLocal。
上线前必做验证动作
在预发环境开启 JVM 参数：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError
然后模拟 500 次请求，观察：
- Full GC 后老年代内存是否回落；
- 用 jstat -gc
查看 MC（Metaspace Capacity）是否缓慢上涨（说明类加载器被阻塞，大概率是静态 ThreadLocal 持有 WebappClassLoader）； - 请求结束后立刻 jmap -histo:live
| grep Itr —— 数量应为 0 或稳定在个位数。
