Java开发中的常见问题:
- 依赖版本冲突问题
- OOM
- 机器负载很高
- 方法调用速度异常的慢
- 代码逻辑不符合预期，该执行的代码没有执行到
依赖版本冲突问题
表现形式: 服务启动或执行过程中出现ClassNotFoundException，NoClassDefFoundError, NoSuchMethodError
JVM加载jar包的顺序:
- 如果是maven或者gradle， shadowJar的时候优先使用最浅(依赖深度)的依赖
- classpath中包括多个版本的依赖，这种情况加载顺序是不定的，可以通过jinfo pid命令查看:
java.class.path = /home/qiniu/platform/zookeeper/bin/../build/classes:/home/qiniu/platform/zookeeper/bin/.. com.sun.management.jmxremote = java.vm.specification.version = 1.8
解决思路:
- gradle dependencies > /tmp/dpe.text 或者 mvn dependency:tree -dverbose > /tmp/dpe.text 查看依赖数，exclude掉冲突的依赖包
- 利用arthas sc命令，查看线上具体执行的方法是从哪个jar包加载的，然后exclude掉多余的依赖, 参考: https://alibaba.github.io/arthas/sc.html
- shaded plugin，package relocation改变包名， 比如:
<relocations>
<relocation>
<pattern>org.apache</pattern>
<shadedPattern>hidden.org.apache</shadedPattern>
<includes>
<include>org.apache.maven.*</include>
</includes>
<excludes>
<exclude>org.apache.maven.Public*</exclude>
</excludes>
</relocation>
</relocations>
参考: https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html
1，2基本上可以解决大部分问题，3是终极方法
OOM
属于最常见的问题，Java的一大优点是其垃圾回收机制，但是也因为GC导致了容易出先内存溢出问题
java.lang.OutOfMemoryError:Java heap space
原因就是应用程序需要的堆空间是XXL号的，但是JVM提供的却是S号。解决方法也很简单， 通过设置-Xmx参数提供更大的堆空间即可。
除了前面的因素还有更复杂的成因：
- 流量/数据量峰值：应用程序在设计之初均有用户量和数据量的限制，某一时刻，当用户数量或数据量突然达到一个峰值，并且这个峰值已经超过了设计之初预期的阈值，那么以前正常的功能将会停止，并触发java.lang.OutOfMemoryError: Java heap space异常。
2 内存泄漏：特定的编程错误会导致你的应用程序不停的消耗更多的内存，每次使用有内存泄漏风险的功能就会留下一些不能被回收的对象到堆空间中，随着时间的推移，泄漏的对象会消耗所有的堆空间，最终触发java.lang.OutOfMemoryError: Java heap space错误。 - 非常多的打印异常堆栈信息，也容易造成此类OOM
第1种可以dump内存中的对象，分析那个对象占用内存最多， 然后再进一步结合代码分析
第2种最常见的是Map的使用，Map的key必须同时重载equals和hasCode方法，否则很容易造成内存泄漏
java.lang.OutOfMemoryError:GC overhead limit exceeded
默认情况下，当应用程序花费超过98%的时间用来做GC并且回收了不到2%的堆内存时，会抛出java.lang.OutOfMemoryError:GC overhead limit exceeded错误。具体的表现就是你的应用几乎耗尽所有可用内存，并且GC多次均未能清理干净。
这个异常是一个信号，示意应用程序在垃圾收集上花费了太多时间但却没有什么卵用。默认超过98%的时间用来做GC却回收了不到2%的内存时将会抛出此错误。那如果没有此限制会发生什么呢？GC进程将被重启，100%的CPU将用于GC，而没有CPU资源用于其他正常的工作。
可以通过-XX:-UserGCOverheadLimit参数关闭这个功能，但是这样只会推迟真正的OOM，不建议这么做
java.lang.OutOfMemoryError:Permgen space
明持久代所在区域的内存已被耗尽，持久代主要存储的是每个类的信息，比如：类加载器引用、运行时常量池（所有常量、字段引用、方法引用、属性）、字段(Field)数据、方法(Method)数据、方法代码、方法字节码等等。我们可以推断出，PermGen的大小取决于被加载类的数量以及类的大小，可以 通过-XX:MaxPermSize=5m或者Metaspace（JDK1.8）来配置
java.lang.OutOfMemoryError:Unable to create new native thread
表示Java应用程序已达到其可以启动线程数量的极限了, 当JVM向OS请求创建一个新线程时，而OS却无法创建新的native线程时就会抛出Unable to create new native thread错误.
总体上来说，抛出此错误会经过以下几个阶段：
- 运行在JVM内的应用程序请求创建一个新的线程
- JVM向OS请求创建一个新的native线程
- OS尝试创建一个新的native线程，这时需要分配内存给新的线程
- OS拒绝分配内存给线程，因为32位Java进程已经耗尽内存地址空间（2-4GB内存地址已被命中）或者OS的虚拟内存已经完全耗尽
- Unable to create new native thread错误将被抛出
当然可以通过在OS级别增加线程数限制来绕过这个错误。如果你限制了JVM可在用户空间创建的线程数，那么你可以检查并增加这个限制：ulimit -u， 但是系统的资源是有限的，不是线程数越多处理速度就越快。那么到底起多少个线程比较最优呢，后面再单独讨论
java.lang.OutOfMemoryError:Out of swap space
Java应用程序在启动时会指定所需要的内存大小，可以通过-Xmx和其他类似的启动参数来指定。在JVM请求的总内存大于可用物理内存的情况下，操作系统会将内存中的数据交换到磁盘上去，这个错误表示交换空间也将耗尽，并且由于缺少物理内存和交换空间，再次尝试分配内存也将失败。
这个问题往往发生在Java进程已经开始交换的情况下，现代的GC算法已经做得足够好了，当时当面临由于交换引起的延迟问题时，GC暂停的时间往往会让大多数应用程序不能容忍。
这些往往是由操作系统级别的问题引起的，例如：
- 操作系统配置的交换空间不足。
- 系统上的另一个进程消耗所有内存资源。
还有可能是本地内存泄漏导致应用程序失败，比如：应用程序调用了native code连续分配内存，但却没有被释放。
解决办法: 增加交换空间
但是操作的时候需要谨慎一点，交换空间运行垃圾回收算法会使GC暂停的时间增加几个数量级，也因为这个原因，好多服务组件都直接建议将交换空间关掉，从而提高性能
java.lang.OutOfMemoryError:Requested array size exceeds VM limit
该错误由JVM中的native code抛出的，意味着应用程序试图分配大于Java虚拟机可以支持的数组，但是这种情况很少见，因为Java中的最大正整数为2 ^ 31 - 1 = 2,147,483,647。 并且平台特定的限制可以非常接近这个数字。
Out of memory:Kill process or sacrifice child
操作系统是建立在进程的概念之上，这些进程在内核中作业，其中有一个非常特殊的进程，名叫“内存杀手（Out of memory killer）”。当内核检测到系统内存不足时，OOM killer被激活，然后选择一个进程杀掉。哪一个进程这么倒霉呢？选择的算法和想法都很朴实：谁占用内存最多，谁就被干掉。
有时候自己的服务进程莫名其妙的被kill掉了，可能就是它干的，可以通dmesg -t 查看系统日志
解决办法:
- 调整OOM Killer配置
- 升级内存
- 优化自己的程序
不建议调大交换空间，原因上面已经说过了
查看JVM启动参数的方法有很多，最常见的是jinfo， 例如: jinfo [pid]， 当然arthas的dashboard/jvm命令也可以比较直观的查看
几个常用的命令:
jmap -heap 1234 查看进程号为1234的Java程序的整个jvm内存状态 jmap -histo 1234 查找进程号为1234的java程序的jvm堆中对象详细占用情况 jmap -dump:``format``=b,``file``=``/my``.dump 1234 导出1234进程的java程序的整个JVM信息
监控GC的工具: GC日志
- -XX:+PrintGCDetails
- -XX:+PrintGCTimeStamps
- -XX:+PrintHeapAtGC
- -XX:+PrintGCDateStamps (from JDK 6 update 4)
通过jstat 查看内存和GC: https://www.cnblogs.com/yjd_hycf_space/p/7755633.html
