之前已经介绍过处理Java虚拟机内存问题的知识与工具，在处理实际项目的问题时，除了知识与工具外，经验同样是一个很重要的因素。本章会介绍一些具有代表性的案例。

本章的内容推荐还是原文全篇看完的好，实在不方便摘取重点做记录。

重中之重就是：多动手使用虚拟机工具监控系统的内存分配、GC情况

一.案例分析

1.　　高性能硬件上的程序不熟策略（控制Full FC频率是关键。也深夜定时任务的方式触发Full GC）

2.　　集群间同步导致的内存溢出（集群同步时，可以允许读操作频繁，但不应当有过于频繁的写操作）

3.　　堆外内存导致德溢出错误（Direct Memory 不能像新生代、老年代那样，发现空间不足了就通知收集器进行垃圾回收，只能等待老年代内存满了后执行Full GC。也可以手动catch异常，执行“System.gc”。需要注意“-XX:+DisableExplicitGC”开关）

4.　　外部命令导致系统缓慢（Java的Runtime.getRuntime().exec()方法的执行过程，首先克隆一个和当前虚拟机拥有一样环境变量的进程，再用这个新的进程去执行外部命令，最后退出这个进程。如果频繁操作的话，系统消耗会很大）

5.　　服务器JVM进程崩溃（当系统中出现大量等待的线程和Socket连接，超过虚拟机承受能力使JVM崩溃时，解决使线程等待的等待源的速度，将异步调用改为生产者/消费者模式）

6.　　不恰当数据结构导致内存占用过大（HashMap<long,long>的空间使用率为 16B/88B）

　　　　88B的由来：在HashMap<long,long>结构中，只有Key和Value所存放的两个长整型数据为有效数据，工16B。这两个长整型数据包装成java.lang.Long对象之后，分别具有8B的MarkWord、8B的Klass指针，再加8B存储数据的long值。

　　　　在这两个Long对象组成Map。Entry之后，又多了16B的对象头，然后一个8B的next字段和8B的int型hash值，为了对齐还必须添加4B的空白填充，最后在再HashMap中对这个Entry的8B引用，这样增加两个长整型数字，

　　　　实际消耗的内存为： Long(24B * 2) + Entry(32B) + HashMap Ref(8B) = 88B

7.　　由Windows虚拟内存导致德长时间停顿（）

二.Eclipse运行速度调优

1.　　使用VisualGC查看Eclipse启动信息（......Full GC 触发19次，耗时3.166秒，Minor GC 触发378次，耗时0.983秒......）

2.　　JDK升级（）

3.　　编译时间和类加载时间的优化（）

4.　　调整内存设置控制垃圾收集频率（查看GC日志。老年代空间耗尽时，会发生一次Full GC，并且老年代容量扩容。可以设置老年代的初始容量，避免自动扩容。新生代也相同）

　　　　（使用jstat-gccause查看，发现代码中有调用System.gc()显式触发GC，我们可以加入 -XX:+DisableExplicitGC 屏蔽掉System.gc()）

5.　　选择收集器减低延迟（选择并发收集器，降低延迟）