记一次 OutOfMemoryError GC overhead limit exceeded的处理

问题表现：
文件下载接口请求缓慢，在运行一段时间后程序报java.lang.OutOfMemoryError: GC overhead limit exceeded

分析过程

1. 查看访问日志：没有发现明显异常，访问日志次数也不多，业务日志也没有异常
2. 异常点：前一天有大量的资源被新加载到内存做为缓存

定位问题
通过jconsole 观察内存年轻代、年老代始终接近100%，说明年轻代的垃圾一直不能回收完整，都转到年老代了。通过jstat命令进一步印证此问题，发现一直在做full GC，stop the world。

[root@Test-02 ~]# jstat -gcutil 3227 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 99.75 99.98 99.36 17 4.793 160 32.739 37.531
0.00 0.00 99.20 99.98 99.36 17 4.793 161 32.882 37.674
0.00 0.00 99.36 99.98 99.36 17 4.793 161 32.882 37.674
0.00 0.00 99.43 99.98 99.36 17 4.793 161 32.882 37.674
0.00 0.00 99.64 99.98 99.36 17 4.793 161 32.882 37.674
0.00 0.00 99.26 99.98 99.36 17 4.793 163 33.166 37.959
0.00 0.00 99.38 99.98 99.36 17 4.793 163 33.166 37.959
0.00 0.00 99.44 99.98 99.36 17 4.793 163 33.166 37.959
0.00 0.00 99.51 99.98 99.36 17 4.793 163 33.166 37.959
0.00 0.00 99.81 99.98 99.36 17 4.793 163 33.166 37.959

问题找到了，就要进行优化了，方案如下：
将资源缓存到REDIS中，同时为了减少读取REDIS的网络开销简单写了一个本地LruHashmap,只保存最长用的200个资源大概10M左右。优化后保证访问速度的同时也大大减少了full gc发生的频率，程序正常响应。

LRUMap的实现方式

private static final int LOCAL_CACHE_SIZE = 200;
private final Map<String,byte[]> localLruCache = 
      new LinkedHashMap<String,byte[]>(LOCAL_CACHE_SIZE, .75F, true) {
          private static final long serialVersionUID = 4267176411845948333L;
          @Override
          protected boolean removeEldestEntry(Map.Entry<String,byte[]> eldest) {
            return size() > LOCAL_CACHE_SIZE;
          }
    };

实现很简单就是重写LinkedHashMap的removeEldestEntry的方法，LinkedHashMap对于put或get操作的Entry放在链表的尾部，这样当超编的时候只要把头结点删除掉就ok了。