1. 什么是内存泄漏它不是“程序变慢”那么简单刚入行那会儿我带过几个实习生他们一遇到应用卡顿、响应延迟第一反应就是“服务器CPU太高了”“是不是网络抖动”——直到某次线上服务凌晨OOM崩溃堆内存直冲98%GC日志里Full GC频率从每小时1次飙升到每分钟3次而业务QPS压根没涨。查了一整夜最后定位到一个被反复new却从未remove的HashMap缓存对象它像滚雪球一样吃掉了所有堆空间。那一刻我才真正明白内存泄漏memory leak不是性能问题而是资源管理失控的慢性自杀。很多人把“内存泄漏”和“内存占用高”混为一谈这是致命误区。举个生活化的例子你租了一间公寓每次搬家都把旧家具塞进储藏室但从来不清理——储藏室慢慢堆满门都打不开最后连新买的沙发都搬不进去。这时你不是“太爱买家具”而是没有建立“用完即清”的回收机制。内存泄漏正是如此对象本该被垃圾回收器GC回收却因某些引用链意外存活导致堆内存持续增长最终触发OutOfMemoryErrorOOM。它不等于“内存用得多”而等于“该释放的没释放”。在Java生态中这个概念尤其关键。因为Java标榜“自动内存管理”开发者容易产生幻觉——“反正有GC我不用管”。但GC只负责回收不可达对象而“可达性”取决于JVM的引用判定规则。一旦你无意中维持了强引用比如静态集合、未注销监听器、线程局部变量TLV未清理对象就永远“活着”哪怕业务逻辑早已结束。Android开发中更典型Activity销毁后若Handler持有其引用或Bitmap未recycleActivity实例就卡在内存里拖垮整个App。Kafka消费者端若未关闭KafkaConsumer实例连接池缓冲区也会持续膨胀最终OOM报错场景根本不是高并发而是长周期运行后的资源滞留。所以理解内存泄漏首先要破除两个迷思第一“有GC就安全”第二“只有大对象才危险”。实际上一个1KB的监听器对象泄漏10万次就是100MB一个未关闭的数据库连接背后可能挂着数MB的网络缓冲区。它不挑大小只认“是否该死却没死”。这也是为什么Java面试题里反复考WeakReference、ThreadLocal.remove()、静态内部类陷阱——这些都不是炫技而是生产环境里最常踩的坑。接下来我们就一层层拆开它的技术肌理看它怎么发生、怎么发现、怎么根治。2. 内存泄漏的底层原理与Java引用模型深度解析要真正防住内存泄漏不能只靠工具扫描得懂JVM怎么判定一个对象“该不该死”。这背后是Java的可达性分析算法和分代引用模型它们共同决定了GC的回收边界。很多开发者调优时只改-Xmx参数却不知道JVM判断“可回收”的逻辑本身就有漏洞——而泄漏就藏在这些逻辑缝隙里。2.1 可达性分析GC的“生死判决书”是怎么写的JVM并不靠“对象是否还在用”来判断回收而是用GC Roots可达性分析。简单说从一组特定对象GC Roots出发沿着引用链向下搜索所有能被遍历到的对象视为“存活”其余则标记为可回收。这里的GC Roots不是随便选的而是JVM硬编码的几类对象虚拟机栈栈帧中的本地变量表中引用的对象比如方法里new出来的对象只要栈帧没出它就活着本地方法栈中JNI即Native方法引用的对象Android里NDK调用常涉及方法区中类静态属性引用的对象比如public static List cache new ArrayList()这个cache永远是Root方法区中常量引用的对象如字符串常量池里的String所有被同步锁synchronized关键字持有的对象锁对象本身也是Root。关键来了只要对象能通过任意一条引用链连到GC Roots它就永远不会被回收。而泄漏的本质就是本不该连上的链被你无意中焊死了。比如一个静态MapString, Object缓存你put进去一个Activity实例Activity里又持有了Context、View树、Handler——整条引用链从static Map直达ActivityActivity就成了GC Roots的“远房亲戚”永远不可达回收。我实测过一个案例某电商App的购物车模块用静态单例管理CartManager里面有个static MapLong, CartItem缓存。用户切换账号时旧CartItem对象没clear而CartItem里又持有了Bitmap通过Glide加载Bitmap又关联着Activity的Context。结果每个账号登录一次就多几百KB内存滞留。用MAT分析堆转储heap dump发现“dominator tree”里CartManager占了70%堆空间根源就是这条静态引用链。2.2 四种引用类型为什么WeakReference不是“万能解药”Java提供四种引用强度对应不同回收策略。很多人以为“用了WeakReference就万事大吉”其实恰恰相反——用错反而加速泄漏。我们逐个拆解强引用Strong Reference最常见的new Object()。只要强引用存在GC绝不回收。泄漏主因90%来自强引用滥用比如静态集合、未注销监听器、线程池里的Runnable持有外部类引用。软引用SoftReference内存不足时才回收适合做缓存如图片缓存。但它不是泄漏防护盾——如果软引用对象被频繁访问JVM可能一直不回收照样OOM。我见过用SoftReference存大量JSON解析结果的代码结果GC压力一大直接触发OOM而非回收。弱引用WeakReferenceGC时无论内存是否充足都会回收。这才是真正的“临时工”引用。但注意WeakReference本身不阻止回收它包裹的对象被回收后get()返回null你需要主动判空。常见错误是写成weakRef.get().doSomething()没判空就NPE。正确姿势是WeakReferenceContext weakContext new WeakReference(activity); Context ctx weakContext.get(); if (ctx ! null !ctx.isDestroyed()) { // Android需额外判destroyed ctx.doSomething(); }虚引用PhantomReference最鸡肋也最精准。它不阻止回收唯一作用是在对象被GC前收到通知用于资源清理如关闭文件句柄。但要注意虚引用必须配合ReferenceQueue使用且get()永远返回null。很多教程教“用PhantomReference防泄漏”实际落地极难——你需要自己维护队列、轮询、执行清理逻辑稍有疏漏就失效。这里有个反直觉点ThreadLocal不是“线程私有”而是“线程局部变量表里的强引用”。ThreadLocalMap的Entry继承WeakReferencekey是弱引用但value是强引用如果ThreadLocal对象被回收比如static变量置nullkey变成null但value还卡在map里形成“内存泄漏”。这就是为什么必须显式调用threadLocal.remove()——不是为了清key而是为了清value。我在线上排查过一个定时任务线程池每个任务都new ThreadLocal 但没remove跑一周后每个线程的ThreadLocalMap里积压上百Connection直接OOM。2.3 垃圾回收机制如何“帮倒忙”GC本意是减负但配置不当反而加剧泄漏影响。Java默认使用G1收集器JDK9它的设计哲学是“停顿时间优先”但对泄漏场景很不友好G1将堆分为多个Region年轻代GCYoung GC只清理Eden区老年代对象不动当老年代空间不足触发Mixed GC但Mixed GC只回收部分老年代Region如果泄漏对象集中在老年代比如静态缓存Mixed GC可能永远扫不到它因为Region选择策略基于“收益比”回收空间/耗时而泄漏对象所在Region可能“收益低”被跳过。这就导致一种诡异现象堆内存持续上涨但GC日志里看不到Full GC。你看到的是频繁Young GC 偶尔Mixed GC而老年代占用率从30%→60%→95%缓慢爬升直到撑爆。此时调大-Xmx只是延缓死亡而非解决问题。我处理过一个Kafka OOM案例消费者线程池里每个Consumer都持有一个ConcurrentHashMap缓存offset由于Consumer未close缓存持续增长G1的Mixed GC始终没清理这部分老年代Region最终OOM。解决方案不是调JVM参数而是确保Consumer.close()在finally块里执行。所以理解GC机制的关键在于GC是回收工具不是泄漏检测器。它只按规则干活不会主动找“不该活的对象”。你的责任是确保引用链符合业务生命周期——该断的时候断该清的时候清。3. 典型泄漏场景与实战诊断全流程光懂原理不够得知道泄漏长什么样、怎么揪出来。我整理了6类最高频泄漏场景每类都附真实代码片段、复现步骤、MAT分析截图逻辑文字描述以及一线工程师的避坑口诀。这些不是教科书理论而是我在3个大型项目里亲手填过的坑。3.1 静态集合类最隐蔽的“内存黑洞”场景还原某金融系统需要实时计算用户持仓盈亏开发写了静态CacheManagerpublic class CacheManager { private static final MapString, Position positionCache new HashMap(); public static void updatePosition(String userId, Position pos) { positionCache.put(userId, pos); // 永远不remove } }问题Position对象包含BigDecimal、List 每个约2KB。日均百万用户请求positionCache涨到2GBFull GC无效。诊断步骤监控先行用JConsole或VisualVM连JVM观察“堆内存使用率”曲线——如果是平缓上升非锯齿状大概率泄漏触发dumpjmap -dump:formatb,fileheap.hprof pidMAT分析打开heap.hprof → “Dominator Tree” → 按Shallow Heap排序 → 找到java.util.HashMap→ 右键“Merge Shortest Paths to GC Roots” → 勾选“exclude weak/soft references” → 看到CacheManager.positionCache是Root确认泄漏展开positionCache → 查看Value类型确认是业务对象而非基础类型。避坑口诀静态集合必设界LRU缓存配TTL放进去时想出来remove逻辑写进业务流宁用ConcurrentHashMap不用static HashMap——后者连size()都可能阻塞。实操技巧用Guava Cache替代手动MapCacheBuilder.newBuilder().maximumSize(1000).expireAfterWrite(10, TimeUnit.MINUTES).build()若必须用static Map加监控positionCache.size() 10000 System.currentTimeMillis() - lastAlert 300000时发告警。3.2 内部类与匿名类Android开发者的头号杀手场景还原Android Activity里写Handler更新UIpublic class MainActivity extends AppCompatActivity { private Handler handler new Handler(Looper.getMainLooper()) { Override public void handleMessage(Message msg) { textView.setText(done); // 持有Activity引用 } }; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); handler.postDelayed(() - {}, 60000); // 1分钟后执行 } }问题Activity finish后Handler仍持有其引用Activity无法回收View树、Context全滞留。诊断步骤LeakCanary接入Android专用添加依赖后App自动检测并弹窗提示“MainActivity leaked”MAT验证dump后“Histogram” → 输入android.app.Activity→ 右键“Merge Shortest Paths to GC Roots” → 发现MainActivity$1匿名类→this$0指向MainActivity关键线索GC Roots路径里出现java.lang.Thread→target→handler→this$0。避坑口诀内部类慎持外部静态嵌套保安全Handler用StaticWeakReference包一层Activity销毁时removeCallbacksAndMessages(null)别偷懒。实操技巧正确写法static class SafeHandler extends Handler { private final WeakReferenceMainActivity activityRef; SafeHandler(MainActivity activity) { this.activityRef new WeakReference(activity); } Override public void handleMessage(Message msg) { MainActivity act activityRef.get(); if (act ! null !act.isFinishing()) { act.updateUI(); } } }更推荐用ViewModel LiveDataJetpack生命周期自动绑定。3.3 资源未关闭数据库、网络、文件IO的“慢性失血”场景还原某后台服务批量导出报表用JDBC写CSVpublic void exportToCsv() { Connection conn dataSource.getConnection(); // 未try-with-resources PreparedStatement ps conn.prepareStatement(SELECT * FROM orders); ResultSet rs ps.executeQuery(); while (rs.next()) { writeRow(rs); // 写文件 } // 忘了rs.close(), ps.close(), conn.close() }问题Connection池耗尽新请求超时ResultSet未关Oracle驱动会缓存结果集元数据内存持续上涨。诊断步骤JDBC监控Druid连接池配置stat-view-servlet看activeCount是否持续增长线程堆栈jstack pid→ 搜索BLOCKED状态线程常卡在getConnection()MAT查ResourceHistogram →java.sql.ResultSet→ 看数量是否异常正常应≤10泄漏时数百文件句柄lsof -p pid→ 查看open files数量Linux默认1024超限报“Too many open files”。避坑口诀IO操作三件套try-with-resources是王道数据库连接池maxActive设上限防雪崩文件流关顺序先子后父莫颠倒BufferedWriter → FileWriter。实操技巧强制规范所有DAO方法签名加throws SQLException逼开发者处理用LombokCleanup注解需编译期处理Cleanup Connection conn dataSource.getConnection(); Cleanup PreparedStatement ps conn.prepareStatement(sql); Cleanup ResultSet rs ps.executeQuery();3.4 监听器与回调事件驱动架构的“悬挂绳索”场景还原某IoT平台设备管理页注册WebSocket监听public class DeviceMonitor { private WebSocketClient client; public void startMonitor() { client new WebSocketClient(uri); client.addListener(new WebSocketAdapter() { Override public void onMessage(String message) { updateDeviceStatus(message); // 持有DeviceMonitor实例 } }); client.connect(); } public void stopMonitor() { client.disconnect(); // 但没removeListener } }问题页面关闭后WebSocketAdapter仍注册在client里client持有AdapterAdapter持有DeviceMonitor整条链存活。诊断步骤代码审计全局搜索addListener检查对应removeListener是否成对出现MAT查ListenerHistogram →WebSocketAdapter→ “Merge to GC Roots” → 发现client.listeners集合持有动态追踪用Arthaswatch命令监控addListener调用栈确认注册位置。避坑口诀监听注册必配销生命周期要对齐Fragment/Activity销毁时onDestroy里unregister第三方SDK查文档有些监听器需主动remove。实操技巧封装监听器管理器public class ListenerManager { private final ListCloseable listeners new CopyOnWriteArrayList(); public void addListener(WebSocketListener l) { listeners.add(() - client.removeListener(l)); client.addListener(l); } public void cleanup() { listeners.forEach(Closeable::close); } }在Spring Bean销毁时调用cleanup()PreDestroy。3.5 线程与线程池后台任务的“幽灵进程”场景还原某订单系统用Executors.newFixedThreadPool(10)处理异步通知public class OrderService { private static final ExecutorService executor Executors.newFixedThreadPool(10); public void sendNotification(Order order) { executor.submit(() - { // 业务逻辑 notifyUser(order); }); } }问题应用重启时executor未shutdown线程池里任务堆积ThreadLocal变量滞留JVM无法退出。诊断步骤线程数监控JConsole → “Threads”页签 → 看“Total threads”是否持续增长线程堆栈jstack pid→ 搜索RUNNABLE状态的pool-1-thread-*MAT查ThreadHistogram →java.lang.Thread→ 看数量是否超预期如固定10线程池却有50个Thread实例关键线索Thread的threadLocals字段非空且指向业务对象。避坑口诀线程池勿staticSpring管理交BeanshutdownNow()要配awaitTermination()等收尾自定义ThreadFactory命名UncaughtExceptionHandler。实操技巧Spring Boot标准写法Bean(destroyMethod shutdown) public ExecutorService asyncExecutor() { return new ThreadPoolTaskExecutor() .setCorePoolSize(5) .setMaxPoolSize(10) .setQueueCapacity(100) .getObject(); }手动管理时JVM关闭钩子Runtime.getRuntime().addShutdownHook(new Thread(() - { executor.shutdown(); try { if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { executor.shutdownNow(); } } catch (InterruptedException e) { executor.shutdownNow(); Thread.currentThread().interrupt(); } }));3.6 Android特有泄漏Context滥用与Bitmap陷阱场景还原某新闻App用Application Context加载图片public class ImageLoader { private static Context context; // Application Context public static void init(Context appContext) { context appContext.getApplicationContext(); // OK } public static void loadImage(String url, ImageView iv) { Glide.with(context) // 错应该用Activity Context .load(url) .into(iv); } }问题Glide.with(Activity)会绑定Activity生命周期自动cancel请求用Application Context则请求永存Activity销毁后ImageView仍持有引用。诊断步骤LeakCanary必开Android Studio插件一键接入Memory ProfilerAndroid Studio → Profiler → Memory → Capture heap dump → “Analyzer Tasks” → “Detect Leaked Activities”MAT交叉验证Histogram →android.app.Activity→ “Show objects by class” → 看是否有已destroyed的Activity实例。避坑口诀Context分两种Application安全Activity危险Glide/ Picasso with()Activity Context是首选Bitmap记得recycleinBitmap复用省内存。实操技巧正确用法Glide.with(activity).load(url).into(imageView)大图加载加限制Glide.with(context).load(url).override(1000, 1000).into(imageView)使用inBitmap复用内存options.inBitmap reusedBitmap。4. 工具链实战从监控预警到根因定位的完整闭环诊断泄漏不能靠猜得有一套趁手的工具链。我用过的工具按“轻量→重型”排序每类都说明适用场景、参数配置、避坑要点。记住工具是眼睛人是大脑没有人工分析再好的工具也只会给你一堆数字。4.1 实时监控JVM自带三剑客JConsole/VisualVM/JMCJConsoleJDK自带零配置启动jconsole→ 本地进程列表选目标PID关键页签Overview看堆内存曲线重点关注Old Gen是否持续上涨Memory强制GC按钮测试回收效果、生成heap dumpThreads查线程数、死锁点击“Detect Deadlock”避坑远程连接需加JVM参数-Dcom.sun.management.jmxremote但生产环境慎开——有安全风险。VisualVM推荐功能最强下载https://visualvm.github.io/支持插件扩展核心插件Visual GC实时显示Eden/Survivor/Old Gen占比YGC/Mixed GC频率VisualVM-MBeans读取JMX指标如Druid连接池活跃数实操技巧右键进程 → “Heap Dump” → 自动生成hprof文件“Sampler”页签 → “Memory” → “Start profiling” → 记录对象分配热点比MAT更轻量。JMCJava Mission ControlJDK7u40内置启动jmc→ 连接目标JVM优势低开销飞行记录Flight Recording可录制1小时GC、内存、线程事件关键配置Recording → “Settings” → 选“Profiling”模板“Memory”事件 → 勾选“Object Allocation in New TLAB”避坑默认只记录10分钟需手动调长录制文件.jfr用JMC打开看“Allocations”页签找高频分配对象。4.2 堆转储分析MATMemory Analyzer Tool深度指南MAT是泄漏分析的核武器但很多人用错。核心不是“看谁占内存多”而是“看谁不该活却活着”。安装与启动下载https://www.eclipse.org/mat/解压即用内存要求分析2GB heap dump需至少4GB物理内存否则OOM。关键操作流程打开hprof→ “Leak Suspects Report”自动生成报告但常不准仅作参考Histogram直方图输入类名如java.util.HashMap→ 右键 → “List objects” → “with incoming references”看“Retained Heap”该对象及其所有引用对象总大小比Shallow Heap更有价值Dominator Tree支配树按Retained Heap排序 → 找最大对象 → 右键 → “Merge Shortest Paths to GC Roots”关键设置勾选“exclude all phantom/weak/soft references”否则看到全是无用路径OQL对象查询语言如查所有ActivitySELECT * FROM android.app.Activity查泄漏的ContextSELECT * FROM java.lang.ref.WeakReference WHERE value.className LIKE %Activity%。避坑要点不要迷信“Leak Suspects Report”它基于启发式算法误报率高“Path to GC Roots”里如果路径含java.lang.Thread或java.util.concurrent.ThreadPoolExecutor基本确定是线程相关泄漏看“Retained Heap”时注意单位MAT默认KB大对象显示为MB别看错数量级。4.3 Android专项LeakCanary与Memory ProfilerLeakCanaryv2.0推荐接入debugImplementation com.squareup.leakcanary:leakcanary-android:2.12原理在Activity.onDestroy()后用WeakReference监测对象是否被回收10秒后dump堆分析报告解读“excluded refs”排除的弱引用可忽略“shortest path to GC Roots”重点看路径里是否有static、Thread、Handler避坑Release版本自动禁用无需手动移除。Android Studio Memory Profiler启动Run → Profile → 选App → “Memory”页签关键操作点击“Record memory allocations” → 操作App → 停止 → 查看分配对象“Capture heap dump” → “Analyzer Tasks” → “Detect Leaked Activities”实操技巧对比两次dump第一次操作前第二次操作后用“Compare Heap Dumps”看新增对象点击对象 → “References” → 查看谁持有它。4.4 生产环境利器Arthas与PrometheusGrafanaArthas阿里开源线上诊断神器启动curl -O https://arthas.aliyun.com/arthas-boot.jar→java -jar arthas-boot.jar核心命令dashboard实时CPU/内存/线程概览vmtool --action getInstances --className java.util.HashMap --limit 10查HashMap实例watch com.xxx.CacheManager updatePosition returnObj监控方法返回值避坑vmtool命令需JDK8且目标类必须已加载。PrometheusGrafana监控告警闭环配置JVM Exporter-javaagent:/path/to/jmx_prometheus_javaagent.jar8080:/path/to/config.yaml关键指标jvm_memory_used_bytes{areaheap}堆内存使用量jvm_gc_collection_seconds_count{gcG1 Young Generation}Young GC次数jvm_threads_live_threads活跃线程数Grafana看板设置告警规则rate(jvm_memory_used_bytes{areaheap}[5m]) 10MB/s持续增长“Memory Usage”面板叠加GC次数曲线看是否GC失效。5. 预防胜于治疗从编码规范到CI/CD的全链路防控诊断是救火预防才是消防体系。我推动团队落地的“泄漏防控四层防线”覆盖从写代码到上线的每个环节实施后线上OOM下降92%。5.1 编码层强制规范与模板代码静态检查SonarQube/Checkstyle规则配置squid:S2259禁止未关闭的资源InputStream等squid:S1168禁止返回null数组/集合自定义规则static Map必须声明为final且初始化为空禁止直接赋值CI集成Git Push触发Sonar扫描违规代码阻断合并。模板代码库Template Code Library提供安全模板SafeAsyncTask.java封装线程池try-catchshutdownSafeBroadcastReceiver.java自动register/unregisterSafeCursorLoader.javaCursor自动close开发者只需继承不用思考生命周期。避坑清单贴在团队Wiki首页✅ 用try-with-resources代替手动close✅ 静态集合加SuppressWarnings(static-method)注释注明清理逻辑❌ 禁止在Activity里new Handler必须用static嵌套类❌ 禁止new Thread().start()必须用线程池❌ 禁止Bitmap.createBitmap()不recycle必须配if (bmp ! null !bmp.isRecycled()) bmp.recycle()。5.2 测试层自动化泄漏检测单元测试注入泄漏检测使用LeakCanary的测试版Test public void testActivityLeak() { ActivityScenario.launch(MainActivity.class); // 执行操作 InstrumentationRegistry.getInstrumentation().runOnMainSync(() - { // 模拟Activity finish activity.finish(); }); // LeakCanary自动检测 }压力测试内存监控JMeter脚本模拟1000用户登录→操作→登出持续30分钟监控指标JVM堆内存增长率jstat -gc pid每10秒采样Full GC次数超过3次/分钟告警报告生成jmap -histo:live pid对比前后对象数。5.3 构建层CI/CD流水线卡点流水线阶段设计CompileCheckstyle/Sonar静态扫描TestJUnitLeakCanary测试Build生成带JFR参数的JAR-XX:FlightRecorder -XX:StartFlightRecordingduration60s,filenamerecording.jfrDeploy-Pre部署到预发环境Arthas自动执行dashboard快照Post-DeployPrometheus告警静默10分钟无OOM告警则放行。卡点策略Sonar漏洞等级≥Blocker流水线失败LeakCanary检测到泄漏测试阶段失败预发环境JFR分析发现内存增长率5MB/min自动回滚。5.4 运维层生产环境主动防御JVM参数黄金组合# 基础参数 -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -Xms2g -Xmx2g \ # 避免动态扩容减少碎片 -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/opt/app/logs/heap.hprof \ -XX:PrintGCDetails \ -XX:PrintGCDateStamps \ -Xloggc:/opt/app/logs/gc.log \ # 防泄漏增强 -XX:UnlockDiagnosticVMOptions \ -XX:PrintConcurrentLocks \ -XX:PrintClassHistogramBeforeFullGC \告警分级机制P0级立即响应jvm_memory_used_bytes{areaheap} 0.9 * jvm_memory_max_bytes{areaheap}P1级2小时内处理rate(jvm_gc_collection_seconds_count{gc~G1.*}[5m]) 10P2级日常优化jvm_threads_live_threads 500线程数超阈值。应急SOP标准操作流程收到告警 → Arthasdashboard确认内存趋势jmap -dump生成heap dump同步下载dump到分析机 → MAT分析定位泄漏点 → 临时方案如重启服务根因修复 → 回归测试 → 上线。最后分享一个真实教训去年双十一流量高峰我们一个服务突然OOM。按SOP操作MAT分析发现是Kafka Consumer未close但奇怪的是代码里明明写了close。深入查才发现close()被包在try-catch里而catch里只打印日志没抛异常——上游调用方没感知到失败。后来我们强制规定所有close()必须放在finally块且catch里必须rethrow或log.error(close failed, e)。泄漏防控的本质是把“人会犯错”的假设变成“系统不允许犯错”的设计。你不需要记住所有陷阱只需要让代码在写错时立刻报错而不是悄悄埋下炸弹。