Red5作为多媒体的开源框架，实现了RTMP协议，完成了视频，音频和多媒体数据的传输和解析，很多产品都在用它。我们也在用他们的服务，但是遇到了内存泄漏的问题，这个内存泄漏是怎么发现的呢：
现象：服务器跑了两天左右，出现了两种情况：
1.内存溢出
2.内存没有溢出，但是无法提供任何服务，服务器无法接收任何请求
分析：
1.扩大跑虚拟机的内存，结果服务器长了点时间，照样内存溢出
2.Dump出Heap快照，并用Eclispse Memory Analyzer进行分析，发现RTMPMinaConnection对象大量存在ConcurrentHashMap对象里面，为什么会出现大量的连接？即使是大量的客户端请求，内存没有释放？
3.分成三个问题考虑：
1)为什么会出现大量的连接？连接从哪里来的
2 ）大量的连接为什么会没有释放？
3）为什么连接达到一定的数量，即使服务器在内存充裕的情况下，仍然无法提供任何服务？
根据大量的连接首先，发现red5服务器，我们用Haproxy代理了rtmp请求，而HA即使没有请求的情况下，仍然尝试连接，以探测代理的服务器是否已经，而red5的keepalive时间过了，会尝试关闭连接，之后关闭，通过查看源代码发现，连接虽然关闭了，但是没有从 concurrentHashupMap 里面删除，而真是这种哈的不间断的通过创建心跳连接来探测 red5 是否有一个活动的状态，而 red5 关闭连接之后，并没有从concurrentHashMap里面删除，从而造成了最终的内存溢出，同时由于没有删除不活动的连接达到了red5设定的最大允许的不活动连接的数量，默认为60000个连接，从而造成我们刚才看到的即使现象-内存充裕的情况下，仍然提供不了任何服务的情况。
查找这个错误的过程是痛苦的，甚至没有一点头绪，还好通过大量的测试和源代码分析，发现了这个问题。我们现在已经升级到red5 0.9.1的版本了，目前情况良好，同时为了保证服务器的稳定性，我们也查阅了相关的源代码，可以确定0.9.1版本中已经修复了这个问题。相信red5服务器在我们的产品上线后会处于一个非常稳定的状态。
这个问题，一些工具的使用是关键的：
首先，要会分析堆快照，而eclipse内存分析器确实是很强大的工具。帮助我们提供大量有用的信息。
其次，开源软件是不可靠的，只有我们对他们的代码有深入的分析才会得出了好的结果。还好，源代码开放也为我们提供了查找问题来龙去脉的根据。而我们也可以对开源软件进行优化，在以后的内容里，我也记录了我们优化red5服务器的整个过程，相信还有很多地方，我们仍然可以优化它。
网上找的~~