「如何排查java内存问题」java内存泄露怎么查
本篇文章给大家谈谈如何排查java内存问题，以及java内存泄露怎么查对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
- 1、如何检查和解决java虚拟机内存溢出的问题
- 2、java的内存异常问题，怎么解决
- 3、java内存诊断软件？
- 4、如何排查Java内存泄露
- 5、记一次线上内存溢出问题排查过程
- 6、java内存溢出的问题如何排查
如何检查和解决java虚拟机内存溢出的问题
一，jvm内存区域
1， 程序计数器
一块很小的内存空间，作用是当前线程所执行的字节码的行号指示器。
2， java栈
与程序计数器一样，java栈（虚拟机栈）也是线程私有的，其生命周期与线程相同。通常存放基本数据类型，对象引用（一个指向对象起始地址的引用指针或一个代表对象的句柄），reeturnAddress类型（指向一条字节码指令的地址）
栈区域有两种异常类型：如果线程请求的栈深度大于虚拟机所允许的深度，将抛StrackOverflowError异常；如果虚拟机栈可以动态扩展（大部分虚拟机都可动态扩展），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
3， 本地方法栈
与虚拟机栈作用很相似，区别是虚拟机栈为虚拟机执行java方法服务，而本地方法栈则是为虚拟机用到的Native方法服务。和虚拟机栈一样可能抛出StackOverflowError和OutOfMemoryError异常。
4， java堆
java
Heap是jvm所管理的内存中最大的区域。JavaHeap是被所有线程共享的一块内存区域，在虚拟机启动时创建。主要存放对象实例。JavaHeap
是垃圾收集器管理的主要区域，其可细分为新生代和老年代。如果在堆中没有内存完成实例分配，并且也无法再扩展时，会抛出OutOfMemoryError
异常。
5， 方法区
与javaHeap一样是各个线程共享的内存区域，用于存放已被虚拟机加载的类信息、常量、静态变量、及时编译器编译后的代码等数据。当方法区无法满足内
存分配的需求时，将抛出OutOfMemoryError异常。方法同时包含常听说的运行时常量池，用于存放编译期生成的各种字面量和符号引用。
6， 直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是java虚拟机规范中定义的内存区域，是jvm外部的内存区域，这部分区域也可能导致OutOfMemoryError异常。
二，jvm参数
-Xss（StackSpace）栈空间
-Xms ，-Xmx（heap memory
space）堆空间：Heap是大家最为熟悉的区域，他是jvm用来存储对象实例的区域，Heap在32位的系统中最大为2G，其大小通过-Xms和
-Xmx来控制，-Xms为jvm启动时申请的最小Heap内存，默认为物理内存的1/64，但小于1G，-Xmx为jvm可申请的最大的Heap内存，
默认为物理内存的1/4,一般也小于1G，默认当空余堆内存小于40%时，jvm会最大Heap的大小到-Xmx指定大小，可通过
-XX:MinHeapFreeRatio来指定这个比例，当空余堆内存大于70%时，JVM会将Heap的大小往-Xms指定的大小调整，可通过
-XX:MaxHeapFreeRatio来指定这个比例，但通常为了避免频繁调整HeapSize的大小，将-Xms和-Xmx的值设为相同。
-XX:PermSize -XX:MaxPermSize ：方法区持久代大小： 方法区域也是全局共享的，在一定的条件下它也会被 GC ，当方法区域需要使用的内存超过其允许的大小时，会抛出 OutOfMemory 的错误信息。
三，常见内存溢出错误解决办法
1， OutOfMemoryError异常
除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能，
Java Heap 溢出
一般的异常信息：java.lang.OutOfMemoryError:Java heap spacess
java堆用于存储对象实例，我们只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，就会在对象数量达到最大堆容量限制后产生内存溢出异常。
出现这种异常，一般手段是先通过内存映像分析工具(如Eclipse Memory
Analyzer)对dump出来的堆转存快照进行分析，重点是确认内存中的对象是否是必要的，先分清是因为内存泄漏(Memory
Leak)还是内存溢出(Memory Overflow)。
如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。
如果不存在泄漏，那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。
2， 虚拟机栈和本地方法栈溢出
如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常
这里需要注意当栈的大小越大可分配的线程数就越少。
3， 运行时常量池溢出
异常信息：java.lang.OutOfMemoryError:PermGen space
如果要向运行时常量池中添加内容，最简单的做法就是使用String.intern()这个Native方法。该方法的作用是：如果池中已经包含一个等于
此String的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String
对象的引用。由于常量池分配在方法区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接限制其中常量
池的容量。
4， 方法区溢出
方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。
异常信息：java.lang.OutOfMemoryError:PermGen space
方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。
java的内存异常问题，怎么解决
Java常见的几种内存溢出及解决方法【情况一】：
java.lang.OutOfMemoryError:Javaheapspace：这种是java堆内存不够，一个原因是真不够（如递归的层数太多等），另一个原因是程序中有死循环；
如果是java堆内存不够的话，可以通过调整JVM下面的配置来解决：
-Xms3062m
-Xmx3062m
【情况二】
java.lang.OutOfMemoryError:GCoverheadlimitexceeded
【解释】：JDK6新增错误类型，当GC为释放很小空间占用大量时间时抛出；一般是因为堆太小，导致异常的原因，没有足够的内存。
【解决方案】：
1、查看系统是否有使用大内存的代码或死循环；
2、通过添加JVM配置，来限制使用内存：
-XX:-UseGCOverheadLimit
【情况三】：
java.lang.OutOfMemoryError:PermGenspace：这种是P区内存不够，可通过调整JVM的配置：
-XX:MaxPermSize=128m
-XXermSize=128m
【注】：
JVM的Perm区主要用于存放Class和Meta信息的,Class在被Loader时就会被放到PermGenspace，这个区域成为年老代，GC在主程序运行期间不会对年老区进行清理，默认是64M大小，当程序需要加载的对象比较多时，超过64M就会报这部分内存溢出了，需要加大内存分配，一般128m足够。
【情况四】：
java.lang.OutOfMemoryError:Directbuffermemory
调整-XX:MaxDirectMemorySize=参数，如添加JVM配置：
-XX:MaxDirectMemorySize=128m
【情况五】：
java.lang.OutOfMemoryError:unabletocreatenewnativethread
【原因】：Stack空间不足以创建额外的线程，要么是创建的线程过多，要么是Stack空间确实小了。
【解决】：由于JVM没有提供参数设置总的stack空间大小，但可以设置单个线程栈的大小；而系统的用户空间一共是3G，除了Text/Data/BSS/MemoryMapping几个段之外，Heap和Stack空间的总量有限，是此消彼长的。因此遇到这个错误，可以通过两个途径解决：1.通过-Xss启动参数减少单个线程栈大小，这样便能开更多线程（当然不能太小，太小会出现StackOverflowError）；2.通过-Xms-Xmx两参数减少Heap大小，将内存让给Stack（前提是保证Heap空间够用）。
【情况六】：
java.lang.StackOverflowError
【原因】：这也内存溢出错误的一种，即线程栈的溢出，要么是方法调用层次过多（比如存在无限递归调用），要么是线程栈太小。
【解决】：优化程序设计，减少方法调用层次；调整-Xss参数增加线程栈大小。
java内存诊断软件？
对于每一个java进程来说都有自己的内存池和使用空间，而这也就意味着会出现内存使用错误等问题，而这时候我们就需要对java内存进行诊断分析，今天云南java培训就一起来了就一下，在进行内存诊断上都有哪些软件可以使用。
Java堆：分析诊断数据
堆转储分析
堆转储可以使用如下的工具进行分析：
EclipseMAT(内存分析工具，MemoryAnalyzerTool)是一个社区开发的分析堆转储的工具。它提供了一些很棒的特性，包括：
可疑的泄漏点：它能探测堆转储中可疑的泄露点，报告持续占有大量内存的对象;
直方图：列出每个类的对象数量、浅大小(shallow)以及这些对象所持有的堆。直方图中的对象可以很容易地使用正则表达式进行排序和过滤。这样有助于放大并集中我们怀疑存在泄露的对象。它还能够对比两个堆转储的直方图，展示每个类在实例数量方面的差异。这样能够帮助我们查找Java堆中增长快的对象，并进一步探查确定在堆中持有这些对象的根;
不可达的对象：MAT有一个非常棒的功能，那就是它允许在它的工作集对象中包含或排除不可达/死对象。如果你不想查看不可达的对象，也就是那些会在下一次GC周期中收集掉的对象，只关心可达的对象，那么这个特性是非常便利的;
重复的类：展现由多个类加载器所加载的重复的类;
到GC根的路径：能够展示到GC根(JVM本身保持存活的对象)的引用链，这些GC根负责持有堆中的对象;
OQL：我们可以使用对象查询语言(ObjectQueryLanguage)来探查堆转储中的对象。它丰富了OQL的基础设施，能够编写复杂的查询，帮助我们深入了解转储的内部。
JavaVisualVM：监控、分析和排查Java语言的一站式工具。它可以作为JDK工具的一部分来使用，也可以从GitHub上下载。它所提供的特性之一就是堆转储分析。它能够为正在监控的应用创建堆转储，也可以加载和解析它们。从堆转储中，它可以展现类的直方图、类的实例，也能查找特定实例的GC根;
jhat命令工具(在/bin文件夹中)提供了堆转储分析的功能，它能够在任意的浏览器中展现堆转储中的对象。默认情况下，Web服务器会在7000端口启动。jhat支持范围广泛的预定义查询和对象查询语言，以便于探查堆转储中的对象;
Java任务控制(JavaMissionControl)的JOverflow插件：这是一个实验性的插件，能够让Java任务控制执行简单的堆转储分析并报告哪里可能存在内存浪费;
Yourkit是一个商业的Javaprofiler，它有一个堆转储分析器，具备其他工具所提供的几乎所有特性。除此之外，YourKit还提供了：
可达性的范围(reachabilityscope)：它不仅能够列出可达和不可达的对象，还能按照它们的可达性范围显示它们的分布，也就是，强可达、弱/软可达或不可达;
内存探查：YourKit内置了一组全面的查询，而不是使用ad-hoc查询功能，YourKit的查询能够探查内存，查找反模式并为常见的内存问题分析产生原因和提供解决方案。
如何排查Java内存泄露
1、首先我把JVM内存调小，便于在最短的时间内发现问题，利用jstat观察JVM内存回收的情况和使用情况，期间发现旧生代内存的申请在一直进行，但是GC基本回收不回来内存，所以很坚信如果JVM没有BUG的情况下，肯定是存在内存泄漏的地方，应该是代码有问题。但是如何在不翻遍整个代码的情况下，定位问题呢？
2、我查阅几个JVM内存导出工具，并利用JMAP把JVM全部导出来，但是发现悲催的温斗士下，这些工具根本打不开一个G左右的导出文件，直接报乱七八糟的错误，可能也是我的PC硬件配置不高吧，无奈之下只好找了一台Linux服务器，在其上装了MAT工具，然后把JVM导出文件放到这台服务器上进行分析，结果迅速定位到了存在问题的代码
JMAP导出JVM命令格式如下：
jmap -dump:live,format=b,file=heap.bin pid
MAT使用比较简单，不再介绍，只要选择打开导出的文件即可对哪些对象、类等对内存的使用情况一目了然，从而帮助把有可能出问题的代码范围尽量缩小，不用像大海捞针一样采用人海战术逐行代码排查。
记一次线上内存溢出问题排查过程
业务反馈后台管理页面打不开，报错。通过后台日志发现zookeeper连不上，找不到dubbo服务提供者。因为之前线上另外的服务也出现过zookeeper连不上的问题，当时是内存溢出，日志有OutOfMemory错误，所以直接到服务器上查看内存使用情况。使用ps -ef | grep java命令找出Java进程号，然后再用jmap -heap pid 命令查看jvm堆内存使用情况，结果如下图：
可以看到，堆内存使用率100%。
既然知道是由于内存溢出导致服务崩溃，那么需要将堆内存镜像导出分析。使用ps -ef | grep java命令查看当堆内存溢出时保持日志文件路径。这里说一下，在java程序启动时需要添加参数，这样在发生堆内存溢出时才会自动生成hprof文件。参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=文件路径 。获取到堆内存镜像后，第一时间重启并恢复线上服务。接下来才是分析过程，我是使用 Eclipse Memory Analysis Tools (MAT)这个工具来分析的。Mac OS第一次使用工具时出现了两个小问题：
1、打开工具时报错，The platform metadata area could not be written: /private/var/folders/8m/tgf，解决办法：右键mat工具显示包内容，找到MemoryAnalyzer.ini并修改，添加参数：-data 下一行是数据保存路径
2、打开镜像文件报错：An internal error occurred during: "Parsing heap dump from XXX，因为我的镜像文件有2个多G，但是MemoryAnalyzer.ini文件里参数-Xmx1024m，默认只有1G，所以修改此参数为-Xmx4096m。
成功打开文件后，选择查看Leak Suspects Report，自动分析到可能存在泄漏的对象，长这个样子：
java内存溢出的问题如何排查
java程序大家都知道，内存溢出是经常见的错误，下面从基本的开始分析！
内存溢出是由于没被引用的对象（垃圾）过多造成JVM没有及时回收，造成的内存溢出。如果出现这种现象可行代码排查：
一）是否App中的类中和引用变量过多使用了Static修饰 如public staitc Student s；在类中的属性中使用 static修饰的最好只用基本类型或字符串。如public static int i = 0; //public static String str;
二）是否App中使用了大量的递归或无限递归（递归中用到了大量的建新的对象）
三）是否App中使用了大量循环或死循环（循环中用到了大量的新建的对象）
四）检查App中是否使用了向数据库查询所有记录的方法。即一次性全部查询的方法，如果数据量超过10万多条了，就可能会造成内存溢出。所以在查询时应采用“分页查询”。
五）检查是否有数组，List，Map中存放的是对象的引用而不是对象，因为这些引用会让对应的对象不能被释放。会大量存储在内存中。
六）检查是否使用了“非字面量字符串进行+”的操作。因为String类的内容是不可变的，每次运行"+"就会产生新的对象，如果过多会造成新String对象过多，从而导致JVM没有及时回收而出现内存溢出。
如String s1 = "My name";
String s2 = "is";
String s3 = "xuwei";
String str = s1 + s2 + s3 +.........;这是会容易造成内存溢出的
但是String str = "My name" + " is " + " xuwei" + " nice " + " to " + " meet you"; //但是这种就不会造成内存溢出。因为这是”字面量字符串“，在运行"+"时就会在编译期间运行好。不会按照JVM来执行的。
在使用String,StringBuffer,StringBuilder时，如果是字面量字符串进行"+"时，应选用String性能更好；如果是String类进行"+"时，在不考虑线程安全时，应选用StringBuilder性能更好。
知道原因了，解决起来就非常简单了。
如何排查java内存问题的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java内存泄露怎么查、如何排查java内存问题的信息别忘了在本站进行查找喔。