java service wrapper 级别为info导致内存剧增直至溢出
上周,公司某一环境发生java service wrapper内存剧增导致最后被自动killed的情况,经过分析,确定导致java service wrapper(后续简称wrapper)守护进程内存快速增长直至被killed的最根本原因是应用程序到mysql数据库的jdbc可用连接远远小于java应用并发线程数,导致报了很多的连接异常(这些异常在至少三种情况下会发生:应用程序启动时mysql未启动,应用程序启动期间mysql被正常或异常关闭,mysql负载过高无响应或者超时,三者均可重现wrapper内存无限增长直至溢出),无论是dbcp 1.x,2.x还是c3p0,该问题均会发生,这些未被捕获的异常堆栈被传递到了wrapper守护进程,进而导致wrapper进程内存激增而溢出。而这些错误仅仅会在wrapper的日志级别为INFO或者更低时会被传递给wrapper;如果设置为ERROR或者更高,则不会(至于为何在这种情况下错误堆栈会被传递给wrapper,尚未找到具体的原因)。它与应用程序设置的log4j级别并无直接关系。同时dbcp连接池1.4以及以下版本因对无效的连接自动回收存在bug,会加速该问题的发生。
PS:上述问题仅在出问题的环境centos 7.0.1406版本下wrapper 3.5.29已验证可重现,不保证在其他版本下一定可重现。
解决方法:
1、使用wrapper,需设置conf/osm-runtime.conf中下列参数为ERROR:
wrapper.console.loglevel
wrapper.logfile.loglevel
wrapper.syslog.loglevel
这么更改的副作用是后续主应用程序中的异常将被suppressed,事后无法查找非显示打印的异常。
2、使用tomcat或者其他应用程序比如自己编写shell脚本作为主容器。
建议:统一将jdbc连接池调整为dbcp 2.1.1。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!