庞大类方法会干扰JIT内联，导致processRecord()等巨型方法以解释模式执行，速度降3~10倍；隐式捕获引发对象膨胀与GC飙升；火焰图与内联日志难以诊断；应拆分为≤25行static方法、提取static final常量、用CompileCommand临时排除。
因为庞大类方法会干扰JIT编译器的内联决策，使关键清洗逻辑无法被高效编译执行，进而引发卡顿、GC飙升和CPU空转。
破坏JIT内联能力
HotSpot默认对方法体超过35行（MaxInlineSize=35）或调用链过深的方法主动放弃内联。清洗分支中一个几百行的巨型processRecord()，哪怕只调用一次，也会被标记为“hot method too big”，导致其内部循环、正则匹配、字段提取等高频操作全部以解释模式执行——速度下降3~10倍。
隐式捕获与对象膨胀
当这个大方法定义在非static上下文中，又引用了外部成员变量或闭包，JVM会为其生成隐式捕获类（如OuterClass$1）。每次循环迭代都可能触发新对象分配，不仅堆内存压力陡增，还让GC频繁回收短生命周期对象，表现为ParNew GC次数暴涨、STW时间延长。
调试与优化路径被锁死
方法过大导致火焰图中热点分散、调用栈过深，难以定位真实瓶颈；-XX:+PrintInlining日志里全是reason: too many bytecodes或failed to inline；想加@HotSpotIntrinsicCandidate也无效——JIT根本不会尝试编译它。
正确做法：拆、提、控
-
拆：把清洗逻辑按语义切分为多个≤25行的private static方法，例如
extractOrderId(String raw)、isValidTimestamp(long ts) - 提：将正则Pattern、日期格式化器等作为static final字段提前初始化，避免循环内重复编译或构造
-
控：用
-XX:CompileCommand=dontinline,com.pkg.Cleaner::hugeMethod临时排除干扰，确认性能提升后再彻底移除该方法
