今天给大家分享一次生产上遇到的内存问题。
生产上的一个应用经常运行一段时间后就内存告警，在一次告警中，先 dump 了内存下来，然后再重启了应用。
dump 命令：
jmap -dump:format=b,file=memory.pro {pid}
用 VisualVM 打开文件，看了一下，发现占用很高的是 java.nio.ByteBuffer[]，点击多层引用进去发现是 Hbase 连接，看起来很明显，大概知道是什么问题了，有 6 万多个连接对象，肯定是连接未释放导致的。
到底是什么导致连接未释放？ 看了公司内部封装的框架代码，操作 Hbase 有使用 HTablePool，配置了队列数是 10，这就奇了怪了。为啥连接数还那么高？
只能通过 Hbase 源代码来看个究竟，直到看了 Hbase 的 HTablePool#getTable()，取出为空的话还会自动创建 HTable，说明配置队列数不是固定死的，还会自动创建的。当 Hbase 操作慢的时候，存 HTable 的队列很容易就为空了，这个时候会额外创建 HTable，这时候怀疑额外创建的 HTable 没有释放资源，再继续看代码。
既然可以无限创建 HTable，那就得关注下存 HTable 到队列的代码了。看了 HTablePool#putTable() 代码发现，只是简单判断了队列没满，就把 HTable 放到队列，多余的 HTable 竟然啥都没处理，就这样堆积在内存中。
看了 Hbase 版本，是可怜的 0.89 古老版，在新的版本这个问题都不存在了，下面是 0.98 版本，已经解决了这个问题，把多余的 HTable 回收了。
这个坑也是公司一直没升级 Hbase 导致的。所以要跟得上开源的脚步，尽量用高的版本的开源框架。在没升级 Hbase 的时候，只能根据业务，把 HTablePool 队列配置配高些，才会减少自动创建的 HTable。
