JVM---问题集

1-高性能硬件上的部署策略（实战链接）
2-集群间同步导致的内存溢出
应用场景：部分数据在不同节点之间共享。读写频繁并且竞争激烈。可以多读，但是不能多写，多写就会导致集群各个节点之间网络交互非常频繁，当网络情况不能满足传输要求，重发数据在内存中不断堆积，很快产生内存溢出。
3-堆外内存导致的溢出错误
Direct Memory，当内存固定，比如8g，而堆内存分配过高7.6g,剩余0.4g分配给栈和其他空间使用。那么直接内存最大0.4g如果不够，就通知收集器回收，但是收集器只能等待老年代满了full gc否则只能看着空闲内存堆内存用不了，而抛出内存溢出异常。

实践经验总结：
直接内存（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：如果代码中使用调用本地库，则本地库内存也不在堆中

虚拟机和GC:虚拟机、GC的代码也要消耗一定内存

4-外部命令导致系统缓慢
shell命令fork进行，比如Runtime.getRuntime().exec()方法来调用。它的过程是：首先克隆一个和当前虚拟机拥有一样环境变量的进程，再用这个新的进程去执行外部命令，最后再退出这个进程。如果频繁执行这个操作，系统的消耗会很大，不仅是CPU，内存负担也很重。

5-服务器JVM进程奔溃
异步方式消费，如果A/B两个系统，A处理业务逻辑快，B处理业务逻辑慢，则当高并发用户上来之后，开启多个异步调用，B系统没能及时处理完毕，积累的等待线程和Socket连接越来越多，最终超过虚拟机的承受能力，奔溃。那么如果高并发场景下，可以改为消息队列来避免这种情况。

6-不恰当数据结构导致内存使用大

比如数据结构的使用考虑牺牲空间还是时间，那么HashMap<Long,Long>结构中是牺牲空间的。因为key和Value所存放的两个长整型数据是有效数据，共16B(2*8B)。这两个长整型数据包装成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)+HashMap Ref(8B)=88B,空间效率16B/88B=18%.

7-虚拟内存导致的长时间停顿
假设工作内存被自动交换到磁盘的页面文件之中，这样发生GC时候就有可能因为恢复页面文件的操作而导致不正常的GC停顿。

可以加入参数-Dsun.awt.keepWorkingSetOnMinimize=true解决。用于保证程序在恢复最小化时候能够立即响应。

8-Java代码问题
代码引起的内存泄露、连接泄露