1 案例分析
① 高性能硬件上的程序部署策略
在高性能硬件上部署程序，目前主要有两种方式：
通过64位JDK来使用大内存。
使用若干个32位虚拟机建立逻辑集群来利用硬件资源。
使用64位JDK来管理大内存，还需要考虑下面可能面临的问题：
- 内存回收导致的长时间停顿。
- 现阶段，64位JDK的性能测试结果普遍低于32位JDK。
- 需要保证程序足够稳定，因为这种应用要是产生堆溢出几乎就无法产生堆转储快照（因为要产生十几GB乃至更大的Dump文件），哪怕产生了快照也几乎无法进行分析。
- 相同程序在64位JDK消耗的内存一般比32位JDK大，这是由于指针膨胀，以及数据类型对齐补白等因素导致的。
使用逻辑集群的方式来部署程序，可能会遇到下面一些问题：
- 尽量避免节点竞争全局的资源，最典型的就是磁盘竞争，各个节点如果同时访问某个磁盘文件的话（尤其是并发写操作容易出现问题），很容易导致IO异常。
- 很难最高效率地利用某些资源池，譬如连接池，一般都是在各个节点建立自己独立的连接池，这样有可能导致一些节点池满了而另外一些节点仍有较多空余。
- 各个节点仍然不可避免地受到32位的内存限制
- 大量使用本地缓存（如大量使用HashMap作为K/V缓存）的应用，在逻辑集群中会造成较大的内存浪费，因为每个逻辑节点上都有一份缓存，这时候可以考虑把本地缓存改为集中式缓存。
②集群间同步导致的内存溢出
③堆外内存导致的溢出错误
除了Java堆和永久代之外，我们注意到下面这些区域还会占用较多的内存，这里所有的内存总和受到操作系统进程最大内存的限制。
- Direct Memory：可通过-XX：MaxDirectMemorySize调整大小，内存不足时抛出OutOfMemoryError或者OutOfMemoryError：Direct buffer memory。
- 线程堆栈：可通过-Xss调整大小，内存不足时抛出StackOverflowError（纵向无法分配，即无法分配新的栈帧）或者OutOfMemoryError：unable to create new native thread（横向无法分配，即无法建立新的线程）。
- Socket缓存区：每个Socket连接都Receive和Send两个缓存区，分别占大约37KB和25KB内存，连接多的话这块内存占用也比较可观。如果无法分配，则可能会抛出IOException：Too many open files异常。
- JNI代码：如果代码中使用JNI调用本地库，那本地库使用的内存也不在堆中。
- 虚拟机和GC：虚拟机、GC的代码执行也要消耗一定的内存。
④外部命令导致系统缓慢
⑤服务器JVM进程崩溃
⑥不恰当数据结构导致内存占用过大
⑦由Windows虚拟内存导致的长时间停顿
2. 实战：Eclipse运行速度调优
- 升级JDK的性能变化
对Eclipse进行调优的第一步就是先把虚拟机的版本进行升级，希望能先从虚拟机版本身上得到一些“免费的”性能提升。
- 编译时间和类加载时间的优化
参数-Xverify：none禁止掉字节码验证过程也可作为一项优化措施。
编译时间是指虚拟机的JIT编译器（Just In Time Compiler）编译热点代码（Hot Spot Code）的耗时。
Java的运行期编译最大的缺点就是它进行编译需要消耗程序正常的运行时间，即编译时间
虚拟机提供了一个参数-Xint禁止编译器运作，强制虚拟机对字节码采用纯解释方式执行。
- 调整内存设置控制垃圾收集频率
参数-XX：+DisableExplicitGC屏蔽掉System.gc（）
- 选择收集器降低延迟