必须用AtomicInteger而非普通变量，因为Lambda只能捕获effectively final的局部变量，而AtomicInteger提供线程安全的原子自增操作，避免多线程下编号重复或跳号。
在动态报表引擎中，Lambda 表达式常用于数据转换、字段映射或条件计算。若需在 Lambda 内部对某个全局计数器（如行号、序号、分组内累计值）做自增操作，直接使用普通局部变量会因“effectively final”限制而编译失败。此时引入外部 AtomicInteger 是最自然、线程安全且零额外依赖的解法。
为什么必须用 AtomicInteger 而非普通变量
Lambda 只能捕获实际不可变的局部变量。比如写 int i = 0; 后在 Lambda 中执行 i++，编译器会报错：“local variables referenced from a lambda expression must be final or effectively final”。这不是语法限制，而是为了防止闭包状态混乱——尤其在报表引擎多线程并行处理数据集时，共享可变状态必须有原子保障。
典型使用场景与写法
假设报表引擎按批次处理数据列表 List<reportrow></reportrow>，需为每行生成唯一递增编号（从 1 开始），并在 Lambda 中嵌入该编号作为字段值：
- 声明一个外部
AtomicInteger实例，初始化为new AtomicInteger(0)（若要从 1 开始，可在调用时用incrementAndGet()） - 在流式处理中，Lambda 捕获该实例并调用原子方法，例如：
.map(row -> { row.setSeqNo(counter.incrementAndGet()); return row; }) - 确保该
AtomicInteger实例不被多个无关任务共享；如报表引擎支持并发执行多个独立报表，每个报表应持有自己的计数器实例
注意事项与避坑点
AtomicInteger 在报表场景下高效，但需注意几个关键细节：
-
不要混用 getAndIncrement() 和 incrementAndGet()：前者返回旧值，后者返回新值。若字段要求“第 1 行编号为 1”，就该用
incrementAndGet()；若逻辑依赖“先用再加”，才选getAndIncrement() -
避免在 forEach 中修改计数器后又用于下游计算：Stream 的
forEach不保证顺序，若需严格有序编号（如导出 Excel 行号），应改用map或预生成索引列表 -
超量风险要预判：AtomicInteger 最大值为 2147483647。若报表单次导出可能超过 21 亿行（极少见），应改用
AtomicLong，否则会静默溢出为负数 - 不建议包装成静态单例：除非明确是全局唯一序列（如日志ID生成器），否则静态共享计数器易导致不同报表任务相互干扰
替代方案对比（为何不选其他）
有人尝试用数组 int[] seq = {0} 或 new Object[]{0} 绕过 final 限制，虽可行但存在明显短板：
- 数组方案无原子性：多线程并发调用时可能出现重复编号或跳号
- 自定义 MutableInt 类增加维护成本，且不提供 compareAndSet 等高级能力
- synchronized 块在 Lambda 内无法直接使用，且会拖慢报表吞吐量
- AtomicInteger 是 JDK 标准类，语义清晰、JIT 友好、调试工具可直接识别其值
