某个线上服务在凌晨开始陆续出现接口超时堆内存监控曲线一路向上从2GB爬到3.8GB只用了几个小时随后接连抛出OutOfMemoryError: Java heap space。容器重启后过了一会儿又反复。打开GC日志和堆转储一看老年代里堆满了同一个类名com.mysql.cj.jdbc.ConnectionImpl对象数量达到六位数。这就是典型的“JVM内存溢出-数据库连接对象大量累积”问题。数据库连接本身不算庞然大物但成千上万个连接对象叠加在一起足以把堆内存榨干。真正有价值的不只是知道“发生了什么”而是搞清楚连接对象为什么只增不减、怎样在不影响线上业务的情况下把它定位出来、修完之后又怎么防止同类问题再次出现。这篇文章就按这个脉络写给同样被内存溢出和连接池问题折磨的人一份可复用的排查手册。1. 先搞清楚连接对象累积与堆溢出是什么关系在动手抓堆转储之前一定要先把问题定性。很多人一看到内存溢出第一反应是堆太小或者GC参数不对实际上连接对象累积类的问题根因往往藏在业务代码和连接池策略里。可以把这类故障从两个层面拆开看一个是单条连接在JVM里到底占多少内存一个是这些连接究竟是怎么积累起来的。1.1 一条数据库连接在JVM里到底占多大地方“一条Connection能占多大顶多几百字节”这是对数据库连接对象的典型误解。连接在JVM堆里的内存占用远不止接口对象本身。以最常见的MySQL客户端连接器为例一个Connection对象背后至少包含这样几块内容Socket通道的输入缓冲区和输出缓冲区每块默认就是8KB到16KB两个加起来已经有十几KB协议解析层、编码转换层、事务状态机等内部对象预编译Statement缓存如果打开useServerPrepStmts每条SQL对应一个对象连接上下文、字符集元数据、用户权限相关的缓存把这些叠加起来一条空闲连接在MySQL 8.x连接器下实测常常是150KB往上。要是连接上执行过较多SQL产生了较多预编译缓存单条连接突破200KB到300KB也不奇怪。做道算术题堆内存设4GB按单条连接200KB估算累积到2万条连接就是4GB左右。也就是说堆里躺上2万个连接对象整个堆就基本废了。而且连接数量越多GC扫描这些对象的时间越长Full GC停顿会越来越明显服务表现为周期性卡顿一直到OOM彻底爆发。1.2 两类累积泄漏型累积与池容量型累积“大量连接对象”这个描述太笼统实际要分成两类来看排查方向完全不同。第一类是泄漏型累积。连接从池里借出来之后关闭动作因为异常、提前return、分支遗漏等原因没有执行连接对象就一直被某个线程栈或者静态容器引用着永远回不到池里。池本身有上限但借出的连接只要还没有归还池的数据结构里就一直持有它的状态记录。于是连接对象数量只增不减堆内存持续爬升。这种在堆转储里的特征是连接对象被某条业务线程的栈帧、或者某个全局容器持久引用而不是挂在连接池的空闲队列上。第二类是池容量型累积。这种更隐蔽代码没有泄漏但连接池配置的maximumPoolSize本身极大池策略又允许大量空闲连接长期存活。比如把池上限设成500系统实际日常只需要20个连接剩下的480个连接一直活着堆里躺着大量空闲连接纯属浪费。每个空闲连接的内存虽然不如活跃连接那么高但架不住数量多。更麻烦的是池创建连接的速度远大于释放速度高峰期内存占用会迅速膨胀。两类问题都会让你在堆转储里看到大量ConnectionImpl对象但前者要改代码后者改配置加监控就能解决。如果在第一步就把问题归错类后面所有的排查动作都会跑偏。2. 根因在哪里常见的连接对象累积路径把这些年遇到过的线上事故叠在一起看连接对象累积基本逃不出下面几种模式。2.1 手动管理连接关闭路径被异常跳过有些老项目里存在不少手写JDBC的场景开发对连接池的理解停留在“调用getConnection就能拿连接”但关闭逻辑写得非常随意。Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql); ResultSet rs ps.executeQuery(); while (rs.next()) { // 业务处理 } // 这里没有close连接池里永远少一个连接这种代码在低并发下长期不炸因为连接池会自动扩容你总觉得连接够用。可流量一旦上来池里的连接被借光新请求就开始排队超时。同时泄漏一直在发生池在扩容到上限之后也无法满足需求堆内存被新连接和等待队列不断撑大量变积累成质变OOM就来了。还有一种更容易被忽视的写法明明写了finally块做close但方法里catch块把异常吞了而close操作又依赖前面某个资源的中间状态。比如在try里初始化PreparedStatement时就抛了异常对象还是nullfinally却直接调用ps.close()空指针把关闭动作彻底打断。这种问题在代码评审时极易漏掉因为正常路径看起来是完整关闭的只有异常路径才露馅。2.2 连接池参数配置与业务容量严重失配另一类常见情况是代码逻辑没有明显泄漏问题出在连接池容量规划上。我见过有团队一遇到“连接池耗尽”的报错就简单粗暴把maxPoolSize从10改成1000。从工程角度讲这不是在解决问题而是给数据库下毒。连接池的上限不只是内存问题1000个连接同时建到数据库实例上数据库端的线程、内存、锁全都会被拖垮整体吞吐量不升反降。更合理的做法是估算连接需求。经验公式大概是需要连接数 接口QPS × 单次操作持有连接的平均秒数举个例子某接口QPS是200每次请求大约占用连接200毫秒那么需要的连接数就是200 × 0.2 40再留20%到30%余量设置50就非常宽裕。如果QPS和平均耗时不变硬把池上限设成500大部分时间池里躺着450条空闲连接对JVM堆是纯浪费对数据库是无谓压力。2.3 Spring事务与MyBatis会话的隐性持有还有一类比显式泄漏更隐蔽的问题连接并没有丢失但被长时间占用数量一多效果等同于泄漏。Spring的Transactional会把数据库连接绑定到当前线程的ThreadLocal资源管理器只有事务提交或回滚之后才释放绑定。如果方法内部嵌套了耗时很长的本地缓存操作、大批量文件处理、或者一次外部HTTP调用连接就会一直被线程攥着不放。消息队列消费逻辑套事务注解是重灾区。一条消息被消费时触发了复杂的业务链路处理10秒连接就被绑定10秒。消费线程池32个连接池上限30瞬时并发上来池里可用连接直接归零。这类问题的特征是堆转储里的连接对象数量可能并不夸张但连接池的active指标一直顶满pending指标持续上涨。修复方向不是调大连接池而是收缩事务边界把远程调用、耗时操作全部挪到事务方法外面去。2.4 多数据源场景下的DataSource重复创建动态数据源也是一个高频坑位。为了做读写分离或者多租户隔离有些项目用Map缓存了多个DataSource实例每次切换数据源就new一个旧的实例却没有关闭。HikariDataSource创建后池后台线程会一直存活。堆转储里不只是ConnectionImpl数量多还能看到多个HikariPool实例以及成倍增长的池控制线程。这种场景下连接对象是被多个连接池对象分开持有的单看数量可能没到吓人的程度但加上线程对象、队列对象、缓冲区对象以后内存占用依然非常可观。定位后处理方式也很明确要么统一走路由层整个JVM只保留真正在用的数据源实例要么为动态数据源设计完整的生命周期管理确保切换后旧实例能被正常关闭和回收。3. 从现象到定位一次完整的在线排查这一章是整个排查过程最实操的部分按我当时处理事故的顺序写。3.1 第一步用jstat观察GC与堆内存趋势定位JVM内存问题最忌讳一上来就抓堆转储。正确的第一步是先看趋势。登录到报警机器先通过jps找到进程PID然后执行jstat -gcutil pid 1000 2000这条命令每秒采样一次持续2000秒。输出里重点看E、O、FGC这三列。E代表Eden区使用率O代表老年代使用率FGC是Full GC次数。如果你看到O列持续上涨Full GC之后O列也不回落说明确实有对象在老年代不断累积。再配合系统负载和接口监控就能把问题范围先从“整台JVM内存溢出”压缩到“某类对象只增不减”。这一步的目的有两个一是确认堆转储有没有必要抓二是为后续分析提供内存使用基线。如果老年代稳定不动Full GC正常单纯是堆参数设太小那调整-Xmx就行跟连接对象没关系。如果像当时那样O列一路爬升就可以放心进入下一步了。3.2 第二步抓堆转储确认对象构成确认老年代在持续上涨后需要抓一份堆转储jcmd pid GC.heap_dump /tmp/heap-pid.hprof用jcmd而不是jmap -dump抓是因为jcmd默认不带live参数不会先触发一次Full GC能保留堆现场的原始状态。抓堆之前先确认磁盘剩余空间堆如果配置4GBhprof文件通常也会有接近4GB的大小别把磁盘写爆了。抓完堆之后先用快速命令看对象分布jmap -histo pid | head -40这段输出的价值在于给出对象数量的Top N。在连接泄漏事故里你经常会在最前面看到这样几个类名com.mysql.cj.jdbc.ConnectionImplMySQL 8.x连接器com.zaxxer.hikari.pool.PoolEntryHikariCP池条目com.alibaba.druid.pool.DruidPooledConnectionDruid池包装连接当ConnectionImpl的对象数量达到几十万级时基本可以确定方向。但我必须提醒一句对象数量多只是信号不直接等于泄漏。继续往下看引用链才是真正的判定依据。3.3 第三步用MAT定位GC Root持有链路把hprof文件下载到本地用Eclipse MAT打开。操作步骤是先看Histogram按对象个数排序过滤出ConnectionImpl这类类名右键选择List objects - with outgoing references看这些连接都引用了什么再右键选择Path to GC Roots - exclude weak references把GC Root路径完整显示出来。CG Root路径通常会呈现三种典型情况连接被HikariPool内部的ConcurrentBag引用这是连接池自己在持有的正常连接。如果数量已经明显超过池配置的上限说明池被撑爆需要回到池配置审查。连接被某条线程栈的局部变量引用这是正在使用中的连接算不上异常。但如果这些线程都停留在同一个业务方法里而且数量持续上涨说明这条方法大概率在泄漏连接。连接被某个实例字段或静态容器引用这是最典型的泄漏实锤。代码把Connection对象塞进了数组、Map、ThreadLocal之类容器里使用完没有清理导致GC Root能一路找到它。通过MAT的引用路径可以直接对应到具体类名和字段名再结合源码仓库就能定位到方法行号比在代码里瞎搜快得多。3.4 第四步结合业务代码确认泄漏点拿到MAT的结论后回到代码仓库打开对应的类。我在实际项目里遇到的漏法主要有三种catch分支里没有释放连接只有正常try路径执行了close方法返回前提前return跳过了统一释放逻辑在循环体里多次调getConnection最后只关闭了一个前面的全部漏掉修好泄漏点之后先别急着扩堆。部署新版本观察连接池的活跃连接数和JVM内存曲线。如果active数能随着流量回落内存曲线走平才算真正修好。这里还要提个建议修复一个泄漏点往往不够建议在代码库全局搜索getConnection的调用点把所有手工获取连接的代码统一审一遍把同类型的隐患一次性清理掉。4. 修复方案与参数调优落地定位到根因之后修复方案要落在三个层面代码写法、连接池配置、监控告警。缺一不可。4.1 代码层修复连接获取与释放的规范写法如果项目还在使用原生JDBC或者裸连接管理务必统一成try-with-resources写法try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql); ResultSet rs ps.executeQuery()) { while (rs.next()) { // 业务处理 } } catch (SQLException e) { log.error(query failed, e); }这种写法的好处是资源关闭顺序由语言层面保证无论正常执行还是抛出异常都会按逆序调用close方法。对于从连接池取出的代理Connection这个close的语义是“归还连接池”并不是真正断开物理连接所以不用担心频繁开关连接带来的性能损耗。如果项目Java版本受限无法用try-with-resources也要遵守一个原则close动作只写在finally里不要分散到try和catch的多个位置否则极易漏掉分支。还有一个实用技巧是给连接操作写一个统一的工具方法把连接获取、关闭逻辑收敛到一处。业务代码只调用工具方法从源头杜绝写法混乱。4.2 连接池参数调整以HikariCP为例Spring Boot默认使用的连接池是HikariCP配置文件可以这样调整spring: datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 30000 max-lifetime: 1800000 idle-timeout: 600000 leak-detection-threshold: 60000每个参数为什么要这样设背后都有逻辑maximum-pool-size池上限。不要拍脑袋设一个整数按前面说的QPS × 平均连接占用时间估算留20%到30%余量。连接数过大对数据库本身也是一种压力。minimum-idle池保持的最小空闲连接数。如果服务空闲期不想保留太多空闲连接可以把值调低配合idle-timeout使用如果日常流量波动大建议设置成与maximum-pool-size一致避免池频繁扩缩容导致性能抖动。connection-timeout客户端等待连接的时间线上建议30秒。设太短突发流量时大量请求直接超时设太长用户侧等待感过强。max-lifetime连接最大存活时间必须小于数据库的wait_timeout。MySQL默认wait_timeout是28800秒HikariCP默认30分钟。保持默认值是安全的只要低于数据库端即可。idle-timeout空闲连接最大存活时间。注意它只在池中连接数超过minimumIdle时才生效如果minimumIdle和maximumPoolSize相等空闲连接不会被销毁。leak-detection-threshold连接被借出超过这个时间没有归还HikariCP会输出警告日志。设成60000毫秒可以较早捕获泄漏点。前提是它必须小于max-lifetime否则配置会冲突。这组参数改完后连接数曲线通常两三个发布周期就能看到明显收敛。参数本身不是越多越好而是要和业务容量的真实需求匹配。4.3 Druid的特殊兜底手段removeAbandoned如果你用的是Druid连接池它提供了一套针对连接泄漏的兜底配置spring: datasource: druid: initial-size: 5 min-idle: 5 max-active: 50 max-wait: 30000 remove-abandoned: true remove-abandoned-timeout-millis: 300000 log-abandoned: trueremove-abandoned的意思是连接被借出超过remove-abandoned-timeout-millis指定的毫秒数后还没归还Druid会从代码里强制回收这个连接。log-abandoned打开后Druid会打印包含调用栈的告警日志定位泄漏非常方便。但这把双刃剑要用得谨慎。如果业务里存在合法的长事务比如一个20分钟的大批量导入任务而你设置的回收阈值是300秒事务后段的数据操作会被强制回收打断引发数据一致性问题。因此这类兜底配置只建议在确实存在泄漏、且业务里没有超过阈值的正常长任务时才启用。更稳妥的顺序是先用log-abandoned定位泄漏分支修复代码再决定是否保留remove-abandoned作为最后防线。4.4 建立三层监控防线排查和修复都完成后最后一步是把防线建立起来避免同类问题在无人值守的深夜再次爆发。我一般分三层来做第一层JVM内存层。使用Spring Boot Actuator加Micrometer把指标暴露给Prometheus重点监控jvm_memory_used_bytes和Full GC次数。一旦老年代内存持续增长连续多个采集周期环比为正立刻告警。第二层连接池层。HikariCP会输出hikaricp_connections_active、hikaricp_connections_idle、hikaricp_connections_pending这几个关键指标。建议给active占总容量比例设置80%阈值pending持续大于0且维持5分钟以上就触发告警。Druid也可以打开监控页但生产环境一定要做访问鉴权。第三层SQL与事务层。开启数据库慢查询日志把超过1秒的SQL记录下来。应用侧记录每个事务方法的耗时超过阈值就预警。一条慢SQL执行5秒就有一个连接被占用5秒。慢SQL一旦集中出现连接池很快见底。三层指标互相配合连接对象的任何异常累积都能在早期被捕捉到。5. 常见问题排查与避坑记录这一路排查下来有些错误和坑值得单独记录下来以后遇到类似问题能少走弯路。现象可能原因排查或处理建议堆内存持续上涨连接对象数量庞大连接泄漏或池配置过大先看GC Root引用链区分泄漏型还是容量型HikariCP连接池请求超时池耗尽多与慢SQL或长事务有关查数据库慢日志收缩事务边界日志显示连接一直未归还方法提前return或异常分支漏close用try-with-resources重写复查catch分支连接池频繁扩缩容minimumIdle与maximumPoolSize差距过大把minimum-idle调高接近maximum-pool-sizeDruid强制回收后事务中断长任务超过回收阈值调大回收时间或去掉兜底优先修代码再分享三个实际踩过的坑第一个坑不要在业务高峰期直接抓dump并立刻重启实例。抓dump本身会给服务增加一次内存快照和磁盘写入如果堆已经接近装满可能直接触发又一次Full GC。更稳妥的顺序是先记录现场指标把实例从负载均衡上摘掉流量再抓dump最后重启。先留证据再补救否则重启完现场没了根因也找不到了。第二个坑不要只盯着ConnectionImpl类名就下结论。之前看一个案例dump里ConnectionImpl数量非常多我差点判定是代码泄漏。但顺着GC Root追下去发现这些连接几乎全部被HikariPool自己持有原来是某次扩容把maximumPoolSize冲到了800代码本身反而没问题。引用链才是判官类名数量只是线索。第三个坑连接池参数修完之后不要直接撒手。一个泄漏点往往只在一类流量场景下才触发比如某个爬虫任务、某个特殊的对账流程。修完连接池配置把内存压下来不代表所有场景都安全了。只要代码库里还存在手工获取连接的调用点建议花时间统一改造让连接回收路径经得起评审。我个人在处理这类问题时的习惯是一开始就拒绝调堆参数。加大-Xmx只是把症状往后推不会让泄漏消失。正确路径永远是把GC趋势、堆转储、GC Root引用链走完让证据说话。如果你也被JVM内存溢出和连接池累积问题缠住按这套流程走一遍大部分事故都能在几小时内锁定根因。最后送一句实操口诀连接泄漏看GC Root连接池容量看指标修复之后看曲线。