将包装类字段改为基本类型不能消除GC扫描死角，因GC扫描的是整个对象图而非字段类型；真正影响扫描效率的是短生命周期对象逃逸、对象图深度过大及GC策略不当。
直接将长周期对象中的包装类字段改为基本类型，不能“彻底消除 JVM 垃圾回收器对堆中海量小对象的扫描死角”。这不是优化不到位的问题，而是对 GC 扫描机制和对象生命周期存在关键误判。
JVM 垃圾回收器（如 G1、ZGC）扫描的是堆中所有存活对象的引用图，不是按“字段类型”选择性跳过。只要对象本身在堆上且未被回收，它的每个字段（无论 int 还是 Integer）都属于该对象实例数据的一部分，GC 必须遍历整个对象内存布局以判断可达性与标记状态。把 Integer status 改成 int status，只是让这个字段不再是一个独立堆对象的引用，而是内联为 4 字节值——它不改变 GC 对“该 DTO 实例”的扫描行为，只减少了该实例间接关联的额外对象数量。
真正影响 GC 扫描效率和“死角感”的，是以下三类实际问题：
短生命周期包装类对象大量逃逸到老年代
比如在初始化长周期对象时，用new Integer(1)赋值给某个字段，或通过反射/序列化框架意外创建了大量临时包装类；这些对象若因同步块、方法逃逸、线程局部缓存等原因晋升至老年代，就会成为 CMS 或 Serial Old 的扫描负担——而现代 G1/ZGC 对老年代的并发扫描虽快，但仍有元数据遍历开销。对象图深度过大或存在隐藏强引用链
长周期对象若持有Map<string list>> configCache</string>这类结构，即使字段本身是基本类型，其引用的集合及内部元素仍是堆对象；GC 必须递归遍历整条链。所谓“扫描死角”，常是因某处static final Map持有已失效但未清理的长周期对象引用，导致整棵子树无法回收。JVM 未启用或未调优增量式/并发式扫描能力
例如仍使用-XX:+UseParallelGC处理低延迟场景，或 G1RegionSize 设置不合理导致大对象直接进老年代；又或者G1HeapRegionSize=4M却频繁分配 3.9MB 的 byte[]，引发大量 Humongous 分配失败和 Full GC——这些才是制造“扫描卡顿”“疑似死角”的主因。
可行的落地动作应聚焦在对象生命周期治理上：
- 把长周期对象中确定非空、无业务语义 null 状态的包装类字段，统一重构为基本类型（如
Integer code→int code），并配合@JsonInclude(NON_DEFAULT)避免序列化冗余 - 对仍需表达“缺失/未设置”语义的字段，改用
OptionalInt或专用状态枚举（如Status.MISSING），而非依赖Integer == null - 使用 JFR（Java Flight Recorder）开启
gc+heap+region事件，观察G1EvacuationPause中各 Region 的LiveBytes和GarbageBytes分布，定位长期高存活率的 Region 及其根因类 - 检查是否有自定义 ClassLoader 加载后未释放、或 ThreadLocal 持有长周期对象引用，这类泄漏会拖慢整个老年代并发标记进度
字段类型重构是必要基础工作，但它解决的是“减少堆对象总数”和“降低 Young GC 频率”，不是“绕过 GC 扫描”。真正的扫描效率提升，来自合理控制对象存活时间、避免跨代晋升、以及选用匹配业务 SLA 的 GC 策略。
