9、知道了问题所在后那么就容易解决了，问题是因为单个缓存过大造成的，那么只需要把缓存减小就行了，这里只需要把缓存以页的粒度进行缓存就行了，每个key缓存10条作为返回给前端1页的数据，这样的话每次查询新闻信息只会从缓存拿出10条数据，就避免了此问题的 产生。
8.4、CPU经常100% 问题定位问题分析：CPU高一定是某个程序长期占用了CPU资源。
1、所以先需要找出那个进行占用CPU高。
top 列出系统各个进程的资源占用情况。2、然后根据找到对应进行里哪个线程占用CPU高。
top -Hp 进程ID 列出对应进程里面的线程占用资源情况3、找到对应线程ID后，再打印出对应线程的堆栈信息
printf "%x\n" PID 把线程ID转换为16进制。 jstack PID 打印出进程的所有线程信息，从打印出来的线程信息中找到上一步转换为16进制的线程ID对应的线程信息。4、最后根据线程的堆栈信息定位到具体业务方法,从代码逻辑中找到问题所在。
查看是否有线程长时间的watting 或blocked 如果线程长期处于watting状态下， 关注watting on xxxxxx，说明线程在等待这把锁，然后根据锁的地址找到持有锁的线程。 8.5、内存飚高问题定位分析： 内存飚高如果是发生在java进程上，一般是因为创建了大量对象所导致，持续飚高说明垃圾回收跟不上对象创建的速度，或者内存泄露导致对象无法回收。
1、先观察垃圾回收的情况
jstat -gc PID 1000 查看GC次数，时间等信息，每隔一秒打印一次。 jmap -histo PID | head -20 查看堆内存占用空间最大的前20个对象类型,可初步查看是哪个对象占用了内存。如果每次GC次数频繁，而且每次回收的内存空间也正常，那说明是因为对象创建速度快导致内存一直占用很高；如果每次回收的内存非常少，那么很可能是因为内存泄露导致内存一直无法被回收。
2、导出堆内存文件快照
jmap -dump:live,format=b,file=http://www.likecs.com/home/myheapdump.hprof PID dump堆内存信息到文件。3、使用visualVM对dump文件进行离线分析,找到占用内存高的对象，再找到创建该对象的业务代码位置，从代码和业务场景中定位具体问题。
8.6、数据分析平台系统频繁 Full GC平台主要对用户在 App 中行为进行定时分析统计，并支持报表导出，使用 CMS GC 算法。
数据分析师在使用中发现系统页面打开经常卡顿，通过 jstat 命令发现系统每次 Young GC 后大约有 10% 的存活对象进入老年代。
原来是因为 Survivor 区空间设置过小，每次 Young GC 后存活对象在 Survivor 区域放不下，提前进入老年代。
通过调大 Survivor 区，使得 Survivor 区可以容纳 Young GC 后存活对象，对象在 Survivor 区经历多次 Young GC 达到年龄阈值才进入老年代。
调整之后每次 Young GC 后进入老年代的存活对象稳定运行时仅几百 Kb，Full GC 频率大大降低。
8.7、业务对接网关 OOM网关主要消费 Kafka 数据，进行数据处理计算然后转发到另外的 Kafka 队列，系统运行几个小时候出现 OOM，重启系统几个小时之后又 OOM。
通过 jmap 导出堆内存，在 eclipse MAT 工具分析才找出原因：代码中将某个业务 Kafka 的 topic 数据进行日志异步打印，该业务数据量较大，大量对象堆积在内存中等待被打印，导致 OOM。
8.8、鉴权系统频繁长时间 Full GC系统对外提供各种账号鉴权服务，使用时发现系统经常服务不可用，通过 Zabbix 的监控平台监控发现系统频繁发生长时间 Full GC，且触发时老年代的堆内存通常并没有占满，发现原来是业务代码中调用了 System.gc()。
参考：
【1】：周志明编著《深入理解Java虚拟机：JVM高级特性与最佳实践》
【2】：《实战JAVA虚拟机 JVM故障诊断与性能优化》
【3】：JVM性能调优详解
【4】：如何合理的规划一次jvm性能调优
【5】：关于GC原理和性能调优实践，看这一篇就够了
【6】：Java 应用性能调优实践
【7】：JVM实战：JVM调优策略
【8】：一般的Java项目需要JVM调优吗？
【9】：Java8 JVM参数解读
【10】：JVM参数设置-jdk8参数设置
【11】：JVM面试问题系列：JVM 配置常用参数和常用 GC 调优策略
【12】：Java1.8的jvm参数官方网站地址