JAVA内存分析
JAVA内存分析一：基于dump内存溢出快照分析

JAVA内存分析二：idea集成jprofiler查看JVM内存使用情况

JAVA内存分析三：使用JDK自带工具进行内存和CPU分析及垃圾回收
引言
Java程序在服务端运行的时候，在长时间运行或者访问量较大的时候，会遇见内存溢出的情况。

这时如果我们没有进行JVM的内存分析，将无法对问题进行定位，那么我们即使对服务端进行重启，在后续的运行过程中，还是会预见内存溢出的情况。

那么我们结合实际情况，通过一些实例来模拟内存溢出的情况，及如何去分析。
正文
1，模拟内存溢出
1.1 新建一个bean对象
package com.moonl.jvm.beans;

public class MemoryOverflow {
}

1.2 建一个main方法来进行程序的运行
package com.moonl.jvm;

import com.moonl.jvm.beans.MemoryOverflow;
import org.springframework.boot.test.context.SpringBootTest;

import java.util.ArrayList;
import java.util.List;

@SpringBootTest
public class MemoryOverflowTest {


    public static void main(String[] args) {
        List<MemoryOverflow> list = new ArrayList<>();
        while (true){
            list.add(new MemoryOverflow());
        }

    }
}

1.3 设置运行时的内存


这里我们设置运行时的内存为21M



现在我们开始运行程序

这时一段很简单的代码，无限循环，不断的将创建一个对象，并加入到list当中，此时我们发现报错提示，内存溢出了。

我们生产环境，系统后台的运行时内存溢出，就这样模拟出来了。


2，定位问题
当我们生产环境，出现内存溢出之后，面对量级比较大的系统，一般是无法通过日志进行定位内存溢出的位置，那么就需要在运行时，加上一段参数，生成运行时内存溢出的快照。

-Xms21m -Xmx21m -XX:+HeapDumpOnOutOfMemoryError

如图所示：


运行后，会出现如图所示:



在程序的工程目录报里面，我们就可以找到，刚生成的文件快照，但该文件的阅读方式，需要单独下载单独的工具进行查询。

这里我使用的是：Jprofiler 大家可以去下载，安装过程不再累述。


3，分析内存溢出的原因
打开Jprofiler—Session—open Snapshot



弹出对话框后，选择要进行分析的文件



就可以看到是什么原因造成内存溢出的，当然在进行生产环境的内存溢出分析时，需要排查和分析的地方更多


后记
总结一下，本文所述的方法是在采用在vm options：-Xms21m -Xmx21m -XX:+HeapDumpOnOutOfMemoryError，中

添加HeapDumpOnOutOfMemoryError，生成快照日志完成的，下一期，我们将讲解通过idea和jprofiler进行整合，查看

内存运行情况。
希望大家给个关注


关注下我的个人公众号，可以获取更多的资讯

【前言】

        最近将Java的内存分析进行了再次学习并进行了总结；Java内存分析一方面对现有系统的优化有着十分重要的指导意义，同时可以让我们以后在进行开发时写出高性能的代码有着重要的借鉴意义。

【内容】

           一、代码在内存中一步一步是如何执行的?

                在进行内存分析学习的时候，自己脑海首先出现便是这个疑问；通过在网上查找以及参考一些书籍，得到如下步骤：

               1、执行总体流程图：



               2、执行步骤：

                    （1）编译代码：用javac将源码文件编译为*.class文件；

                    （2）类加载：将.class文件加载到JVM，并形成Class对象的机制，方便对Class对象实例化并调用；

                    （3）执行代码（分为两种）：

                            ①解释执行（运行期解释字节码并执行）

                               A、优点：节省内存

                               B、缺点：速度慢、效率低

                            ②编译为机器码执行（将字节码编译为机器码并执行，这个编译过程发生在运行期）

                               A、优点：速度快

                               B、缺点：占用内存多                   

           二、内存模型

               1、五部分：



               2、五部分作用：

                    （1）程序计数器

                            一个处理器，在一个确定的时刻都只会执行一条线程中的指令，一条线程中有多个指令，为了线程切换可以恢复到正确执行位置，每个线程都需有独立的一个程序计数器，不同线程之间的程序计数器互不影响，独立存储;

                    （2）虚拟机栈

                            每个方法被执行的时候都会创建一个栈帧用于存储局部变量表，操作栈，动态链接，方法出口等信息。

                            每一个方法被调用的过程就对应一个栈帧在虚拟机栈中从入栈到出栈的过程;

                            ①栈帧: 是用来存储数据和部分过程结果的数据结构。

                            ②栈帧的位置:  内存 -> 运行时数据区 -> 某个线程对应的虚拟机栈 -> here[在这里]

                            ③栈帧大小确定时间: 编译期确定，不受运行期数据影响。

                    （3）本地方法栈

                            与虚拟机栈发挥的作用十分相似,区别是虚拟机栈执行的是Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的native方法服务，可能底层调用的c或者c++,我们打开jdk安装目录可以看到也有很多用c编写的文件，可能就是native方法所调用的c代码。

                    （4）堆

                           java虚拟机管理内存最大的一块内存区域，因为堆存放的对象是线程共享的，所以多线程的时候也需要同步机制

                    （5）方法区

                           用于存储已被虚拟机加载的类信息、常量、静态变量，如static修饰的变量加载类的时候就被加载到方法区中

【总结】

         本篇文章是内存分析的代码执行流程，以及五大区域的作用，在接下来的文章中会为大家分享更多实用技巧以及如何指导系统进行优化。

jmap内存分析



查找对象数，内存占用 -histo

在遇到jvm内存泄漏问题(java heap space)，如果需要借助工具分析内存，可以使用jmap。

测试代码:



public class HeapStats {


        public static void main(String[] args) {

            List<TestCase> cases = new ArrayList<TestCase>();
            while(true){
                cases.add(new TestCase());
            }
        }
    }

class TestCase {
    private List<String> li;

}



查找java进程号pid

tasklist /SVC|findstr java 

java.exe                     31516 暂缺 

java.exe                     20148 暂缺 

java.exe                     31748 暂缺

jmap -histo  31748 > histro1.txt



 num     #instances         #bytes  class name
----------------------------------------------
   1:      74080662     1185290592  demo.test.TestCase
   2:           492      347853264  [Ljava.lang.Object;
   3:          6333         867320  <methodKlass>
   4:          6333         802360  <constMethodKlass>
   5:         10313         602688  <symbolKlass>
   6:           447         508280  <constantPoolKlass>
   7:          2820         412120  [C
   8:           416         352896  <constantPoolCacheKlass>
   9:           447         324776  <instanceKlassKlass>
  10:           560         109184  [B
  11:          2842          90944  java.lang.String
  12:           531          55224  java.lang.Class
  13:           680          45072  [S
  14:           690          42840  [[I
  15:            55          32120  <objArrayKlassKlass>

在实际生产环境，会复杂很多，可以每隔一段时间用jmap产生一个dump文件，然后进行对比，如果某个对象占用的空间过大，就需要仔细分析了。



产生dump文件线下分析 -dump

jmap -dump:live,format=b,file=output.hprof pid

使用jhat可以查看

jhat output.hprof 

之后可以使用浏览器在页面观察dump情况。



遇到问题


当执行时遇到 拒绝访问，需要以管理员打开cmd，然后执行命令。


测试程序参考: http://www.cnblogs.com/dingyingsi/p/3760447.html

今天项目组其他同事遇到内存泄露的问题。我记得之前在Eclipse中有Eclipse自带的插件某某version查看Dump文件

现在换成了IDEA工具，同事使用JProfiler文件进行内存分析，记录一笔

使用JProfiler进行内存分析

在最近的工作中，通过JProfiler解决了一个内存泄漏的问题，现将检测的步骤和一些分析记录下来，已备今后遇到相似问题时可以作为参考。

 

运行环境：

Tomcat6，jdk6，JProfiler8

 

内存泄漏的现象：

1. 在服务器中执行某些批量操作的时候，发现内存只升不降；就算gc后，内存也不能被完全释放；

2. 除非重启tomcat服务器，内存永远不会被释放，反复执行这些操作，会导致无可用内存，tomcat死掉；

使用JProfiler检查内存泄漏的步骤：

1. 初始化检验环境：

切换到“Live Memory-->All Objects”标签，可以看到当前tomcat中的对象情况,注意jprofiler其他版本可能位置不一样.



在执行操作前，需要先F4,运行“Run GC”，使jvm进行内存回收清理无效的对象.为了便于比较内存的增长情况，可以点击右键--->"Mark Current",

来将当前内存使用情况作为参照；点击后会显示“Difference”列，该列会列出对象数量的变化和变化比率



2.打开内存记录： 

点击“Start Recordings”按钮，开始记录。执行这步的主要目的是为下面“Heap Walker”设置一个监控区间；如果不记录的话“Heap Walker”将分析jvm虚拟机的所有内存，即耗时又不能准确的发现内存泄漏的原因。

3. 执行操作，执行gc；

 使用压力工具访问被测应用，执行完之后再次F4进行GC----这样是为了消除可以回收的对象。执行内存回收后，仍然存在于内存中的对象有可能是泄漏的对象。如下图instance count中红色的部门为不能回收的对象，difference列列出了增加的对象数量和增。以String为例，在该操作中增加了31751个对象增幅达到了14%，随后会在HeapWalker中观察这些对象，分析哪些对象是泄漏的。一般引起泄漏的对象包括：String、char[]、HashMap、Concurrenthashmap等，这类对象需要重点关注下；

4. 关闭内存记录：

点击“Stop Recordings”关闭内存记录，告诉jProfiler把这段记录作为分析对象；

5. 找到增加迅速的对象类型，打开HeapWalker：

在视图中找到增长快速的对象类型，本例Concurrenthashmap的增长速度很快。在memory视图中找到Concurrenthashmap---点右键----选择“Show Selectiion In Heap Walker”，切换到HeapWarker 视图；切换前会弹出选项页面，注意一定要选择“Select recorded  objects”，这样Heap Walker会在刚刚的那段记录中进行分析；否则，会分析tomcat的所有内存对象，这样既耗时又不准确；



6. 在HeapWalker中，找到泄漏的对象；

HeapWarker 会分析内存中的所有对象，包括对象的引用、创建、大小和数量；

 

 

HeapWarker视图下方可以进行页面切换：

通过切换到References页签，可以看到这个类的具体对象实例。



 为了在这些内存对象中，找到泄漏的对象（应该被回收），可以在该对象上点击右键，选择“Use Selected Instances”缩小对象范围；



单击OK按钮

7. 通过引用分析该对象：

在References引用页签中，可以看到该对象的的引用关系，可以切换incoming/outcoming，显示引用的类型：

incoming  表示显示这个对象被谁引用；

outcoming 表示显示这个对象引用的其他对象；



 

选择“Show In Graph”将引用关系使用图形方式展现；



选中该对象，点击“Show Paths To GC Root”，会找到引用的根节点；



在上图中，我们可以发现，这个HashMap Segment对象最终的引用是在ConcurrentHashMap和ReentranLock对象中；

8. 通过创建分析该对象：

如果第7步还不能定位内存泄露的地方，我们可以尝试使用Allocations页签，该页签显示对象是如何创建出来的；

我们可以从创建方法开始检查，检查所有用到该对象的地方，直到找到泄漏位置；



 

转载于：https://www.cnblogs.com/onmyway20xx/p/3963735.html