BlogJava-PS，1880后程序员-随笔分类-我爱内存泄露

内存泄漏 - 开篇数据库应用

amenglai — Fri, 18 Jan 2013 03:14:00 GMT

最近都在读那个该死的猪小弟写的代码，原因还不是因为压力测试后，发现TMD的内存泄漏啦！
边看代码边在心中鄙视这个猪小弟，该死的猪小弟，说你比猪笨，猪觉得这是对自己的侮辱都不乐意，
很多心得哦，慢慢整理出来。
先说说JDBC吧。
不关闭Connection

这是最常见的错误，数据库增删改操作后，没有关闭数据库连接，导致占用大量内存，如果是用连接池，那么系统很快就木有可用的数据库连接了；如果是直接连接数据库，很快系统内存就耗尽了，要知道数据库连接很费资源的，否则要连接池干吗？而且这种错误很难查，一个系统上百个DB操作，就一个没关闭，惨了！
不关闭Statement,ResultSet

这是另一种错误，数据库连接关闭了，但是Statement,ResultSet没关闭。谁说的关闭了数据库连接其它就不用关闭的。只关闭连接，那些Statement,ResultSet就如同孤坟野鬼一样占据你的Heap，而且还是阴魂不散的说，最后系统耗尽内存气绝身亡。

频繁数据库连接
大多数业务系统，一个业务操作可能会关联多张表的增删改。麻烦不要每操作一张表，就请求一次数据库连接。麻烦把请求数据库连接看做是请你学妹吃饭好不好，小学妹很矜持，请一次也不容易。这样想，你请求数据库连接时，就会谨慎些，尽可能一次数据库连接，对多张表进行操作。
经验
不要把代码写成connection.close(); 或者 datasource.getConnection();把他们都封装到工具类里面，这样测试的时候加进去debug代码，很容易就找到那个该死的连接没有关闭了。Statement, ResultSet也是这样。

最后，猪小弟是谁？
呵呵，猪小弟是5年前的我，或者是8年前的我。当年，年幼无知，无知者无畏，犯下无数的错误，感谢老板，感谢客户，你们太有牺牲精神了。

amenglai 2013-01-18 11:14 发表评论

使用Eclipse Memory Analyzer对Tomcat进行内存分析

amenglai — Thu, 17 Jan 2013 02:55:00 GMT

测试环境

Java ： JDK1.6

Tomcat： Tomcat 5.5

Eclipse Memory Analyzer：EMA 1.2.1（直接去Eclipse下载，无需安装哈）

获得Heap Dump文件

Eclipse Memory Analyzer是针对Heap Dump文件进行分析的，因此第一步就是要获得Heap Dump文件。

步骤：

获得线程ID。启动jconsole.exe,它位于jdk目录下的bin目录，jconsole是jdk自带的一个内存分析工具，它提供了图形界面。可以查看到被监控的jvm的内存信息，线程信息，类加载信息，MBean信息。

此处我们可以找到需要检测的Tomcat的线程ID。

获得Heap Dump文件。使用jmap来获得Heap Dump文件，命令行如下：

jmap -dump:format=b,file=heap.bin 3888

此处3888就是Tomcat对应的线程ID

生成分析报告

启动MemoryAnalyzer.exe，打开指定的Heap Dump文件。File -> Open Heap Dump

MAT针对指定的Heap Dump文件进行分析，生成内存泄露检测报告

看懂分析报告

要想看懂EAT的报告，与其到网上去找各种神贴，不如老老实实找本书，先简单复习下JVM的Heap是怎么工作滴？gc的大概一个工作机制。否则EAT的报告就像天书一样。EAT只是工具，不是目的。

amenglai 2013-01-17 10:55 发表评论

web应用中常出现的内存泄露

amenglai — Wed, 16 Jan 2013 03:32:00 GMT

企业级管理软件的web应用和普通的web站点，B2C等有很大的不同。内存泄露的检查点也会不同。
检查点一：什么信息需要缓存在session中
在各种管理软件中，最常见的是把当前用户的权限等信息缓存在session中。好啦，问题来了，如果系统的权限很复杂：操作权限，管理权限，数据权限，字段权限，巴拉巴拉一大堆的话，那么把这大堆信息放到session中，一个用户就要占掉20M+的内存。访问用户一多，系统就挂了。而且管理软件一般都会把session的timeout设置的很多，除非用户手动的注销，否则即使木有操作也会吊在系统上很久。因此要评估此部分的设计，把不必要的或者访问不频繁的数据拖出session，放过session TA老人家吧。
检查点二：session数据传递

管理系统很多都会采用帧结构，常见的上帧查询条件，下帧显示结果。问题来了，采用帧结构如果传递数据到页面，就要通过session。开发的时候，一般都是后台开发负责业务逻辑，前台开发负责数据展示。前后开发一脱节，后台向前台传递了一个集合对象，前台木有用，也不管清除。这堆垃圾数据全部都驻留内存，所以系统跑着跑着就宕机了。

检查点三：不要试图通过页面来实现分页

管理系统由于业务复杂性等要求，大家都把注意力首先放在实现业务功能上，有时对数据的量级不是很关注。有的系统刚开始好好的，用着用着不不爽了，原因就是数据量一增加，很多相关的问题都会暴露出来。最常见的是分页处理，先把数据都取过来，在前台分页显示。千万不要这样，100条数据木有问题，1000条，10000条呢，结果就是前台很忙，然后就挂掉了。

amenglai 2013-01-16 11:32 发表评论

BlogJava-PS，1880后程序员-随笔分类-我爱内存泄露

内存泄漏 - 开篇 数据库应用

使用Eclipse Memory Analyzer对Tomcat进行内存分析

web应用中常出现的内存泄露

内存泄漏 - 开篇数据库应用