一个因为SQL join引发的内存泄露
来源:互联网 发布:域名交易新闻 编辑:程序博客网 时间:2024/05/01 13:24
最近公司的一个系统频繁的发生内存泄露,把server上的dump文件下载下来打开却是损坏的。用Jconsle监控server发现,线程的数量和内存的使用率都在不断上升。服务器重启后还好,运行一天之后就会发现线程数量很多,内存使用率很高,监控GC的日志发现full GC一直被调用,然后空间不能得到释放,主要是metaspace。
然后这个版本和上个版本之间唯一的区别就是几个native sql。在Jconsle的线程页面可以看到一些错误是关于其中一个修改过的方法的,这个方法以前是调用Hibernate的get方法,现在改成了native sql。
后来发现在内存变高的瞬间确实有一个对这个方法的调用,查看request后看到这条数据的返回很大。这个方法被调用的时候内存一直激增,然后降低,重复出很大锯齿形,应该是GC被频繁调用,然后该方法却一直不结束。查看内存的分区发现,老年代的大小在一直升高,不能得到释放。从Thread页面还是可以看到hibernate在处理这个native sql的时候发生了一定的错误,但是不能判断是什么问题。
拿这个native sql和特点的id到数据库查询后发现,这个sql返回了4491672条数据,这显然就是问题的所在了。这个SQL使用了很大left join,一共left join了8张表,其中3张对于主表是多对多或者多对一的关系。sql 语句如下:
SELECT * FROM 主表LEFT JOIN aLEFT JOIN bLEFT JOIN cLEFT JOIN dLEFT JOIN eLEFT JOIN fLEFT JOIN ddLEFT JOIN eeWHERE id=:id
其中a,b,c都返回多条数据,a返回101条,b返回218条,c返回204条,其它表返回一条,相乘之后正好返回4491672条数据。虽然众所周知join是笛卡尔集,但是因为开发中往往用到这种many-to-one的join比较少所以容易忽略。虽然每一张表只返回一两百条数据,但是笛卡尔集就是几百万。
通过这个事情至少让我们学到一点就是不要为多对一或者多对多的关系写太多的jion,以免发生这种内存泄露问题,排查起来相当困难。另外一个启发就是不要在同一个方法里面企图返回太多的东西,API要尽量细粒度。
0 0
- 一个因为SQL join引发的内存泄露
- Message引发的内存泄露
- 因为一个调用疏忽引发的问题
- 一个因为time/datetime引发的血案
- java finalize 方法引发的内存泄露
- 继承threading.local引发的内存泄露
- 内存泄露可以引发的问题
- 使用Handler引发内存泄露的改进
- 错误使用Handler引发的内存泄露
- handler引发内存泄露
- leakcanary作者发现的一个Dialog的各种listener容易引发的内存泄露问题
- drools规则引擎因为内存泄露导致的内存溢出
- 【内存泄露】由Handler引发的内存泄漏的思考
- 【内存泄露】由Handler引发的内存泄漏的思考
- GLIBC内存分配机制引发的“内存泄露”
- GLIBC内存分配机制引发的“内存泄露”
- GLIBC内存分配机制引发的“内存泄露”
- 转载-------GLIBC内存分配机制引发的“内存泄露”
- Hadoop使用学习笔记(4)
- LeetCode 7 有几个坑踩得还是很有价值的
- 权限系统与RBAC模型概述
- 常用 Git 命令清单
- Android 属性动画详解,属性动画基本用法!
- 一个因为SQL join引发的内存泄露
- Android layout布局属性、标签属性总结大全
- 24节气算法
- SSM框架搭建
- 【CDOJ】柱爷与咸鱼神功
- 什么是优秀的用户体验:解读40个优秀界面设计
- HDU_5783_DivideTheSequence(贪心)
- Android解压缩
- 文章标题