HBase Committer胡争提出的issue：
[HBASE-21551]Memory leak when use scan with STREAM at server side
https://issues.apache.org/jira/browse/HBASE-21551
问题摘要
通常顺序扫描的时候。为了可以避免频繁的Position Read，服务端采用STREAM类型。如果出现以下任何一种情况，由于泄漏导致的内存不足错误，HBase集群将遇到Region Server故障：
1.用户发起设置为使用STREAM读取类型的Scan操作；
2.用户发起设置为使用默认读取类型，读取扫描中涉及的超过4倍列族块大小（例如，默认为4 * 64KiB）的Scan操作；
3.运行Compaction。
问题描述
我们使用STREAM打开RegionServerScanner，如下所示：
RegionScannerImpl#initializeScanners
|---> HStore#getScanner
|----------> StoreScanner()
|-------> StoreFileScanner#getScannersForStoreFiles
|------> HStoreFile#getStreamScanner #1
在＃1中，将StoreFileReader放入ConcurrentHashMap streamReaders，但是在关闭StoreFile之前不会从streamReaders中删除StreamReader。
因此，如果使用流扫描很多次，则会展开HashMap streamReaders，通过heap-dump查看堆存储情况：
胡争发现此错误，因为当通过在集群中使用YCSB（RS的堆大小为50g）对扫描性能进行基准测试时，RS很容易在很长时间内Full GC（~110秒）。
根本原因
当有长时间运行的扫描时，Region Server进程会尝试使用面向顺序访问的不同API来优化访问。由于HBASE 2.0+的HBASE-20704错误，因此当扫描完成时Region Server无法释放相关资源。 HBase内部文件压缩过程始终使用相同的优化路径。
解决方法
升级到最新版本。通过将配置值“hbase.storescanner.pread.max.bytes”设置为MAX_INT可以最大限度地减少对此错误的影响，以避免对默认用户扫描进行优化。并且应该检查客户端以确保它们不会将STREAM读取类型传递给Scan API。这将对长时间Scan的性能产生严重影响。
压缩总是使用这种顺序优化的读取机制，因此下游用户需要在压缩发生后定期重新启动Region Server角色。
修复实现
https://github.com/apache/hbase/commit/3b854859f6fad44cbf31164374569a6ab23f3623
https://github.com/apache/hbase/commit/67ab8b888f8b393979624a2bd7d527fefd9dd6d7
在此感谢HBase Committer胡争Review细节。
