大数据量查询引发的是“分配抖动”而非“页抖动”，因JVM堆内存按TLAB、Eden区等逻辑结构管理，非OS页粒度；其本质是短生命周期大对象高频分配与回收导致的扩容+GC复合抖动。
大数据量查询（如千万级全表扫描）本身不直接触发“堆内存页抖动”，但会引发典型的集合扩容抖动 + GC抖动复合现象，本质是短生命周期大对象高频分配与回收导致的内存行为失稳。
为什么不是“页抖动”而是“分配抖动”
JVM堆内存不按操作系统“页”粒度管理对象分配；它使用TLAB（Thread Local Allocation Buffer）、Eden区、Region等逻辑结构。所谓“抖动”，实际指：
- 短时间内大量ArrayList/HashMap实例被创建 → 触发频繁扩容（如从16→32→64→128…）
- 每次扩容都需分配新数组、复制旧元素、丢弃旧数组 → 产生大批临时对象
- 这些对象集中在Eden区快速填满 → 频繁Minor GC
- 若对象存活时间略长（如中间聚合结果未及时清理），部分进入老年代 → 加速老年代增长，诱发Full GC
典型表现：GC日志与监控信号
在千万级扫描场景下，你会观察到：
- GC日志高频出现Allocation Failure：说明Eden区反复撑爆，Minor GC间隔缩短至百毫秒级
- 年轻代晋升率陡升：jstat -gc输出中YGC次数激增，同时YGCT（Young GC耗时）和FGC（Full GC次数）同步上涨
- 堆内存曲线呈“锯齿密布+缓慢爬升”：每次GC后水位不归零，且峰值逐次抬高 → 暗示存在隐性内存泄漏或缓存未释放
- JFR中“Object Allocation Outside TLAB”事件暴增：说明线程本地缓冲区频繁不足，被迫走慢路径分配，加剧竞争与延迟
关键诱因：结构选型与处理方式失配
抖动不是GC器的问题，而是代码层面对大数据流缺乏流式约束：
- 用new ArrayList<>()接收全量查询结果 → 千万条记录直接进堆，无分批、无游标、无流式终止
- 用HashMap<String, List<Row>>做聚合 → 每个key对应数百行，List反复扩容，底层数组成倍拷贝
- 未关闭ResultSet或未设置fetchSize → JDBC驱动默认一次拉取全部结果集到内存
- 日志/监控埋点在循环内打印完整对象 → toString()触发临时字符串拼接与char[]分配
缓解方向：从分配源头控抖动
不依赖调大-Xmx，而聚焦三件事：
- 预分配容量：查前估算行数（如EXPLAIN或count(*)预估），初始化ArrayList时指定initialCapacity；HashMap按预期key数 × 1.3设capacity
- 改用流式结构：用Stream.iterate或JDBC的Statement.setFetchSize(1000) + while(rs.next())逐批处理；聚合用Map<K, LongAdder>替代Map<K, List>
- 复用中间容器：对高频创建的临时List/Map，用ThreadLocal<List>或ObjectPool封装，避免重复new
