“零内存脱敏”需同时满足字段值不逃逸和脱敏结果复用常量池，借助逃逸分析优化分配位置，再通过ByteBuddy在Jackson/Gson序列化入口织入低开销脱敏逻辑，避免堆上新建敏感字符串对象。
不能靠逃逸分析直接实现“零内存脱敏”，但可以借它减少脱敏过程中的堆分配，再配合 ByteBuddy 在字节码层拦截序列化入口，把脱敏逻辑织入关键路径，做到不改业务代码、不额外分配敏感字符串对象。
逃逸分析不是脱敏工具，而是内存优化前提
Java 的逃逸分析本身不处理数据内容，只影响对象分配位置。所谓“零内存脱敏”，真实含义是：避免在堆上构造原始敏感值（如 new String("138****1234")），尤其防止脱敏中间结果反复创建、滞留堆中被 GC 扫描。
- 脱敏操作本身（比如手机号掩码）若基于栈上局部变量计算，且返回的是字面量或常量池引用，JVM 可能将其整个优化掉，或复用已有字符串
- 但如果脱敏逻辑触发了 StringBuilder.append()、String.substring() 或反射调用（如 Jackson 的 getter），就极易导致新 String 对象逃逸到堆
- 验证方式：加 JVM 参数 -XX:+PrintEscapeAnalysis -XX:+PrintOptoAssembly，观察脱敏方法内是否出现 allocates on heap 类提示
ByteBuddy 织入点必须落在序列化前最后一环
源码不改，意味着不能在 Controller 返回前手动调用 maskPhone(user.getPhone())。真正可行的切口是：在 JSON 序列化器真正读取字段值的那一刻，动态替换其返回值。
- 不要增强
@Sensitive字段的 getter 方法——它可能被其他非序列化逻辑调用，污染语义 - 应增强 Jackson 的 BeanPropertyWriter.serializeAsField() 或 Gson 的 ReflectiveTypeAdapterFactory.Adapter.write()，这些是所有 POJO 字段输出的统一出口
- 用 ByteBuddy 的
Advice插入逻辑：当检测到当前写入字段带@Sensitive注解时，跳过原值读取，直接调用预注册的脱敏函数（如Masker.phone(value)） - 关键细节：脱敏函数内部必须用 char[] + System.arraycopy 或 StringLatin1.inflate 等低开销方式构造掩码串，避免 new String 构造器逃逸
真正“零内存”的两个硬约束
不是加个注解就自动零分配，需同时满足：
-
字段值本身不逃逸：比如用户手机号来自数据库查询，若 DAO 层用
ResultSet.getString()返回的已是堆上 String，那再怎么脱敏都绕不开初始堆分配；更优做法是让 JDBC 驱动直接返回 char[]，由脱敏逻辑就地覆写 -
脱敏结果复用常量池：对固定格式（如手机号总掩成
"138****1234"），可预先缓存 100 个常见掩码模板（"138****0000"到"138****9999"），脱敏时仅做数组索引查表，完全不 new 对象
验证是否真达成“零内存”效果
光看日志不行，要抓运行时证据：
- 用 JFR（JDK Flight Recorder） 录制 10 秒高频接口调用，筛选
jdk.ObjectAllocationInNewTLAB事件，重点关注java.lang.String和java.lang.StringBuilder的分配次数与大小 - 对比开启 ByteBuddy 脱敏前后：若脱敏字段从每请求分配 3~5 个 String 降到 0 次，且 TLAB 分配速率无突增，说明成功压平了内存毛刺
- 用 async-profiler 采样堆内存分布：
./profiler.sh -e alloc -d 30 -f alloc.svg PID，确认敏感字段相关字符串不再出现在 top allocators 中
