64位JDK应用内存问题
- 内存回收导致的长时间停顿
- 现阶段，64位JDK的性能测试结果普遍低于32位JDK
- 需要保证程序足够稳定，因为这种应用要是产生堆溢出几乎就无法产生堆转储快照（因为要产生几十GB乃至更大的Dump文件），哪怕产生了快照也几乎无法进行分析
- 相同程序在64位JDK消耗的内存一般比32位JDK大，这是由于指针膨胀，以及数据类型对齐补白等因素导致的
集群优化
- 尽量避免节点竞争全局的资源，最典型的就是磁盘竞争，各个节点如果同时访问某个磁盘文件的话（尤其是并发写操作容易出现问题），很容易导致IO异常
- 很难最高效率地利用某些资源池，譬如连接池，一般都是在各个节点建立自己独立的连接池，这样有可能导致一些节电池满了而另外一些节点仍有较多空余。尽管可以使用集中式的JNDI，d但这个有一定复杂性并且有可能带来额外的性能开销
- 各个节点仍然不可避免地受到32位的内存限制，在32位Windows平台中每个进程只能使用2GB的内存，考虑到堆以外的内存开销，堆一般最多只能开到1.5GB。
- 大量使用本地缓存(如大量使用HashMap作为K/V缓存)的应用，在逻辑集群中会造成较大的内存浪费，因为每个逻辑节点上都有一份缓存，这时候可以考虑把本地缓存改为集中式缓存。
堆外内存导致的溢出错误
- Direct Memory:可通过-XX：MaxDirectMemorySize调整大小，内存不足时抛出OutOfMemoryError或者OutOfMemoryError：Direct buffer memory
- 线程堆栈：可通过-Xss调整大小，内存不足时抛出StackOverflowError(纵向无法分配，即无法分配新的栈帧)或者OutOfMemory:unable to create new native thread（横向无法分配，即无法建立新的线程）
- Socket缓存区：每个Socket连接都Receive和Send两个缓存区，分别占大约37KB和25KB内存，连接多的话这块内存占用也比较可观。如果无法分配，则可能会抛出IOException: too many open files异常
- JNI代码：如果代码中使用JNI调用本地库，那本地库使用的内存也不在堆中
- 虚拟机和GC：虚拟机、GC的代码执行也要消耗一定的内存
外部命令导致系统缓慢
如频繁调用Java的Runtime.getRuntime().exec()方法
不恰当数据结构导致内存占用过大
如HashMap<Long,Long>结构来存储数据文件空间效率太低。
在HashMap<Long,Long>结构中，只有key和value所存放的两个长整型数据是有效数据，共16B。这两个长整型数据包装成java.lang.Long对象之后，就分别具有8B的MarkWord、8B的Klass指针，在加8B存储数据的long值。在这两个Long对象组成Map.entry之后，又多了16B的对象头。然后一个8B的next字段和4B的int型的hash字段，为了对齐，还必须添加4B的空白填充，最后还有HashMap中对这个Entry的8B引用，这样增加两个长整型数字，实际消耗的内存为（Long(24B)*2）+Entry(32B)+Hash Ref(8B)=88B，空间效率为16B/88B=18%
调整内存设置控制垃圾收集频率
如eclipse启动时，Full GC大多数是由于老年代容量扩展而导致的，由永久代空间扩展导致的也有一部分。为了避免这些扩展导致的性能浪费，我们可以把-Xms和-XX:PermSize参数值设置为-Xmx和-XX:MaxPermSize参数值一样，这样就强制虚拟机在启动时就把老年代和永久代的容量固定下来，避免运行时自动扩展。
