《企业实战分享 · 内存溢出分析》

已于 2024-07-04 00:34:00 修改
阅读量510 收藏 6
点赞数 6
分类专栏： 企业实战分享 文章标签： java 内存溢出
于 2024-07-03 23:59:54 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/syb513812/article/details/140165180
版权

📢 大家好，我是 【战神刘玉栋】，有10多年的研发经验，致力于前后端技术栈的知识沉淀和传播。 💗
🌻 近期刚转战 CSDN，会严格把控文章质量，绝不滥竽充数，如需交流，欢迎留言评论。👍

文章目录

写在前面的话

书写背景

博主所在公司采用的是技术栈为：后端 SpringCloud，前端 Nuxt，部署 K8S。（看过前面文章的应该知道）
由于涉及服务较多，代码量也随着需求研发不断增加，难免出现一些臭鱼烂虾的隐患代码。
最终导致的是，线上服务的内存溢出问题屡见不鲜，每次排查都要依靠架构等少数人员，现着手整理了一份分析内存溢出问题的流程文档，方便研发主管人员可以自行排查，而不需要依赖架构部门。
此篇博文将以上述文档为基础略为调整，发布到博客，若出现一些未及时调整的话术，希望理解。

知识补充

Tips：这部分纯属知识补充，可以跳过。

关于内存泄漏和内存溢出
一般来说内存异常问题分为内存泄漏和内存溢出。
内存泄漏：对象已经不使用了，但是还占用着内存空间，没有被释放。
内存溢出：堆空间不够用了，通常表现为 OutOfMemoryError，内存泄漏通常会导致内存溢出。
再看一下“内存泄漏”的定义：一个不再被程序使用的对象或变量还在内存中占有存储空间。
一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。
“内存溢出”：指程序申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储 int 类型数据的存储空间，但是你却存储 long 类型的数据，那么结果就是内存不够用，此时就会报错OOM,即所谓的内存溢出。
二者的关系：内存泄漏的堆积最终会导致内存溢出
**内存泄漏 ：**是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。就相当于你租了个带钥匙的柜子，你存完东西之后把柜子锁上之后，把钥匙丢了或者没有将钥匙还回去，那么结果就是这个柜子将无法供给任何人使用，也无法被垃圾回收器回收，因为找不到他的任何信息。
**内存溢出：就是你要的内存空间超过了系统实际分配给你的空间，此时系统相当于没法满足你的需求，就会报内存溢出的错误。

内存溢出种类与解决
JVM 管理的内存大致包括三种区域：Heap space（堆区域）、Java Stacks（Java 栈）、Permanent Generation space（永久保存区域）。由此，OOM 简单的分为堆溢出、栈溢出、永久代溢出(常量池/方法区)。Java 程序的每个线程中都有一个独立的堆栈。

PS：我们日常开发中，遇到最后的就是堆内存溢出，这里重点介绍这块，其他两块自行了解。

Java 堆内存溢出
Java 堆是线程共有的区域，主要用来存放对象实例，几乎所有的 Java 对象都在这里分配内存，也是 JVM 内存管理最大的区域。Java堆内存分年轻代和年老代，堆内存溢出一般是年老代溢出。当程序不断地创建大量对象实例并且没有被GC回收时，就容易产生内存溢出。当一个对象产生时，主要过程是这样的：
1、JVM首先在年轻代的Eden区为它分配内存；
2、若分配成功，则结束，否则JVM会触发一次Young GC，试图释放Eden区的不活跃对象；
3、如果释放后还没有足够的内存空间，则将Eden区部分活跃对象转移到Survivor区，Survivor区长期存活的对象会被转移到老年代；
4、当老年代空间不够，会触发Full GC，对年老代进行完全的垃圾回收；
5、回收后如果Suvivor和老年代仍没有充足的空间接收从Eden复制过来的对象，使得Eden区无法为新产生的对象分配内存，即溢出。
由此可见，当程序不断地创建大量对象实例并且没有被GC回收时，就容易产生内存溢出。如下：

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

堆内存溢出很可能伴随内存泄漏，应首先排查可能泄露的对象，再通过工具检查 GC roots 引用链，从而发现泄露对象是由于何种引用关系使得GC无法回收他们；若不存在内存泄漏，换句话说就是内存中的对象还都需要继续存活，则可通过修改虚拟机的堆参数将堆内存增大。

补充说明：
堆区域用来存放 Class 的实例(即对象)，对象需要存储的内容主要是非静态属性。每次用 new 创建一个对象实例后，对象实例存储在堆区域中，这部分空间也被 JVM 的垃圾回收机制管理。
java.lang.OutOfMemoryError: Java heap space 此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。原因是 JVM 创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与 Heap space 有关。
解决这类问题有两种思路：
1、对于内存泄露，可以通过内存监控软件查找程序中的泄露代码。检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。
2、增加 JVM 中 Xms(初始堆大小)和 Xmx(最大堆大小)参数的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024
PS：JVM大小通常运维人员会考虑一个合适的值，研发要注意的就是第一点。

常见原因

首先排除Java程序的JVM配置问题，代码有哪些常见问题会导致内存溢出：
1、内存中加载的数据量过大，一次从数据库取出过多数据导致内存溢出；
2、集合类中有对对象的引用，使用完后没有及时清空，使得 JVM 不能回收；
3、代码中存在死循环或循环产生过多重复的实体对象；
4、未完待续。。。

排查方式

凭经验肉眼扫描代码
针对上述列的常见导致内存溢出的代码，日常排查代码可以遵循如下轨迹：
1、检查对数据库查询中，是否有一次获得全部数据的查询，一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽且有潜伏性，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。所以可以使用分页查询数据库；
2、检查代码中是否有死循环或递归调用导致有大循环重复产生新对象实体；
3、检查 List、MAP 等集合对象是否有使用完后未清除的问题，集合中存在对对象的引用会导致这些对象不能被 GC 回收；

借助工具定位问题
1、服务启动的时候，设置其参数，使其支持在发生内存溢出时自动dump内存快照；

PS：也就是通常说的dump文件，这步运维那边会做好。

2、内存快照文件是后缀为 .hprof 的文件，内存溢出的时候产生，可以从服务器下载到本地；

PS：找运维拿到这个文件，或者从SpringBootAdmin尝试下载。

3、借助内存溢出排查工具 VisualVM、Jprofiler 等，直接加载hprof文件，按步骤定位问题代码；

PS：安装一款你顺手的工具，排查一下。

研发人员如何手动操作
1、进入到对应的容器里面去
docker exec -it 容器id /bin/bash
2、ps -ef | grep java 查看java进程id
3、保存堆和栈的现场快照 ，jstack命令用于打印指定Java进程、核心文件或远程调试服务器的Java线程的Java堆栈跟踪信息
jstack pid > stack.log
jmap -dump:format=b,file=heap.hprof pid
4、退出容器
5、看情况是否重启容器
docker restart 容器id
6、将文件从容器导出到宿主机
docker cp 容器id:要导出的文件路径 宿主机路径
7、再次进入容器删掉 相关文件
8、下载文件导本地进行分析并且删除
9、接下来使用具体工具分析

使用 JProfiler 排查

具体步骤

选择指定的 dump 文件（后缀是hprof），使用 Jprofiler 加载，第一次可能较慢。

文件范例：D:\cjwmy1013\devlop\zoe-optimus-dia-dc-8157.hprof

image.png
如图点击大对象
image.png
image.png
image.png
image.png
image.png

补充说明
若软件提示内存不够，可以加大内存，如下：
C:\Users\cjwmy1013.jprofiler11\jprofiler.vmoptions
-Xmx4036m
-Xss2m

使用 VisualVM 排查

VisualVM是jdk自带的jvm监测工具，主要用来监测cpu、线程和堆内存的使用情况，使用简单，不需要额外配置，可以支持本地和远程环境，软件的位置在jdk的bin目录下，找到jvisualvm.exe，双击打开。
image.png
image.png
image.png

监视视图

选择本地的运行的某个进程双击，选择监视tab按钮就可以查询到当前进程的cpu、内存、类、线程运行信息
image.png

点击堆Dump用来生成某一时刻的堆转储文件快照（.hprof），并且把堆转储信息转换成堆转储标签内，我们可以看到摘要、类、实例数等信息以及通过 OQL 控制台执行查询语句功能，帮助我们分析对象的引用关系、是否有内存泄漏情况的发生。
image.png
堆转储的概要包括转储的文件大小、路径等基本信息，运行的系统环境信息，也可以显示所有的线程信息。
image.png
从类视图可以获得各个类的实例数和占用堆大小数，分析出内存空间的使用情况，找出内存的瓶颈，避免内存的过度使用。
image.png
对两个堆转储文件进行比较，通过比较我们能够分析出两个时间点哪些对象被大量创建或销毁。
image.png
image.png
打开实例数视图需要指定一个类，即在类视图中双击某一个类进入该类的实例数视图，通过下图可以看出主要的信息包含该类的实例（对象）总数，单个实例、总实例占堆内存的大小，单个实例在堆内存中的所有字段、值，以及对象与引用对象之间的依赖关系。
image.png

线程视图

线程视图显示当前进程包含的所有线程，类型分为User Thread(用户线程)、Daemon Thread(守护线程)，任何一个守护线程都是整个JVM中所有非守护线程的保姆，Daemon的作用是为其他线程的运行提供便利服务，守护线程最典型的应用就是 GC (垃圾回收器)
image.png
image.png

  • 运行状态:线程正在运行
  • 休眠状态:线程在休眠
  • 等待状态:调用Object.wait的线程，此处要注意，condtion.await并不是此状态,而是下面的状态。
  • 驻留状态:调用了LockSupport.park的线程就是此状态，常见的有如下：
Lock lock = new ReentrantLock();
lock.lock();
Condition condition = lock.newCondition();
condition.await();
  • 监视状态:synchrnoiezed获取锁被阻塞时的状态

如果想保存某个时间节点的线程快照信息，就点击右上角的线程Dump，其实就是执行jstack命令，jstack命令可以生成JVM当前时刻的线程快照。线程快照是当前JVM内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。
image.png

抽样器

抽样器可以对该进程的某个时间段的CPU使用情况进行抽样，即点击CPU样例的快照按钮。
image.png
image.png
image.png
抽样器同样可以对内存使用情况进行实时监测，以及保存快照信息，根据内存大小（字节数）降序排序就能快速定位出占用内存较多的类，下图可以看出是byte[]数组占用了大量内存，如果此时还不能定位到程序哪里的问题，那就通过保存内存的快照，然后分析这个dump。
image.png
根据下图可以看出byte[]数组实例很少，但是占用的内存很多，继续向上查找引用它的实例，最后发现是arrayList中引用了byte[]，既然问题找到了，后续的解决方法就是在程序中进行定位，优化现有代码。
image.png
image.png

Visual GC插件

visual gc插件可以清晰的看到堆的使用情况以垃圾收集信息，工具栏选择插件，可用插件搜索visual gc点击安装，
image.png
image.png
安装完毕后，重启visualVM，会出现如下图：
image.png
visual gc分为两个板块：
1、visual gc window（即spaces区域）
Metaspace ：方法区的内存，如果JDK1.8之前的版本，就是Perm，JDK7和之前的版本都是以永久
Old：老年代
新生代：由Eden、S0、S1组成

每个方框都使用不同的颜色表示，有颜色的区域是占用的空间，空白的是剩余的空间，当程序运行时，会动态的显示
image.png

2、Graph区域，包含了以时间轴为横坐标的状态面板
Compile Time：编译情况，1407 compoles - 2.644s 表示编译总数为1407，编译总耗时为2.644s。
一个脉冲表示一次JIT编译，脉冲越宽表示编译时间越长。
Class Loader Time：类加载情况，1709 loaded，0 unloaded - 696.184ms表示已加载的数量为1709，卸载的数量为0，耗时为696.184ms。
GC Time：总的（包含新生代和老年代）gc情况记录 52 collections，708.580ms Last Cause：Allocation Failure表示一共经历了52次gc，总共耗时708.580ms。
Eden Space：新生代Eden区内存使用情况
Survivor 0和Survivor 1：新生代的两个Survivor区内存使用情况
Old Gen：老年代内存使用情况
Metaspace：方法区内存使用情况（最大容量，当前容量）
image.png

使用Eclipse Memory Analyzer排查

工具介绍

Java VisualVM只提供了一些基本的功能，所以我们一般不使用Java VisualVM来分析，而是使用Eclipse Memory Analyzer（MAT）来分析，MAT工具是一款强大的Java堆内存分析工具，特点是免费使用，无需安装解压即用，可用于查找内存泄露以及查看内存消耗情况，便于开发或运维人员快速定位内存溢出或内存泄露问题。
需要注意必须安装jdk1.8环境才能使用
下载地址：https://www.eclipse.org/mat/previousReleases.php
解压后，双击MemoryAnalyzer.exe打开
image.png
界面效果如下：
image.png

这边写一个小案例来演示内存不断增加的场景：

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

然后设置启动参数，让程序内存溢出时自动生成Dump文件
image.png

-Xmx30m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump

-Xmx30m：最大堆内存为30m -XX:+HeapDumpOnOutOfMemoryError：当JVM发生OOM时，自动生成DUMP文件。 -XX:HeapDumpPath：指定文件路径，例如：-XX:HeapDumpPath=${目录}/java_heapdump.hprof。如果不指定文件名，默认为：java_pid.hprof

image.png
当内存溢出的时候自动在指定的目录下生成了一个hprof文件，然后用Eclipse Memory Analyzer打开这个文件：
image.png

点击File-》Open Heap Dump，选择内存溢出生产的.hprof文件，默认选择Leak Suspects Report泄漏可疑报告
image.png
导入成功之后首先来看这个界面，我们先不着急如何分析问题，先快速了解下面板上各个组件的用法，方便后面的学习。
image.png

Overview组件

OverView功能是导入了dump文件之后，对可能出现的问题做了一个整体性的分析概述，首先呈现在眼前的是以一个形状图的方式，快速展现了该文件中dump文件大小，以及类、对象和类加载器的数量，当光标移动到蓝色区域时候，会呈现该日志文件的主要线程，类加载器信息。
image.png
![4E3B`I)FS4I4}B3NN%Z_OQ.png
总共使用的内存为24M Thread对象占用了23M，类加载器占用了206kb，其他对象占用了752kb。

Top consumers组件

展示的是占用内存比较多的对象的分布，下面是具体的一些类和占用
![MSN(4598`T$JEKW~H4RT_]5.png](https://img-blog.csdnimg.cn/img_convert/9b754529578285828253081bd16d22f1.png)

Histogram组件

Histogram 可以列出内存中的对象，对象的个数以及大小
Objects：对象的个数
Shallow Heap：对象所占用的本身内存大小（不包含引用对象）
Retained Heap：对象以及它所持有的其它引用（包括直接和间接）所占的总内存大小

当点击进去之后，为我们呈现出dump文件中，已经创建的主要的对象信息，默认按照对象的个数进行排序，而这个排序，多少也反映出在当前的dump文件中，那些排在前面的数量最多的对象可能是我们分析问题的关键入口
image.png
顶部的可以支持对象名称的模糊匹配，比如搜索Picture，可以快速找到我们需要的对象名称。
image.png
MAT还提供了分组查看功能，方便快速定位类的信息，默认视图就是Group by class根据类分组。
image.png
Group by superclass根据父类分组，所有类的父类都是Object，所以会生成树形结构。
![F`3TDHG8CHI5J3`ZLLPSVM.png
Group by class loader根据类加载器分组
2)3VWXHT23V{~HXP1)N%5Y.png Group by package根据包目录分组 image.png 除了分组功能，还支持按照字段排序，右键某个对象可以选择按照类名、对象个数、浅堆数量、深堆数量排序，这也是快速定位到需要查找到的对象的一种方式 ![(`X]0DS7UYQ4H163JJJ7HE5.png

这里需要了解浅堆、深堆的概念，因为这两个参数是分析OOM的一个关键点。
浅堆：指的是一个对象所消耗的内存（不包括内部引用的对象大小）
深堆：指的是一个对象直接访问或者间接访问到的所有对象的浅堆之和，即对象被回收后，可以释放的真实空间。
浅堆、深堆总结：对象的深堆个数总是多于浅堆，实际开发过程中，可能因为编码的习惯不好，导致某些类中，对象的引用链条特别长，层级也很深，搞不清楚那些对象是实际在使用的，假如正好有那么一些对象实际上并没有使用，但是在某些循环中大量创建，尤其是大对象，在这种情况下，很容易造成GC过程的失败最终引发OOM，所以分析这两个参数对于快速定位那些数量较多的对象还是很有帮助的。

对象引用链：
查看引用当前对象的外部对象可以点击这个右键—》show objects by class-》by incomming references
![KJ(783)WBOKYAUZ4VV({~7.png
查看当前对象引用的外部对象可以点击这个右键—》show objects by class-》by outgoing references
![3[1)Q}RY_M]R}LKQ)KaTeX parse error: Expected 'EOF', got '}' at position 190: …问题的一个很好的点。 ![PP}̲EW~X44IIRB7O03)…W.png

Thread Overview组件

Thread Overview展示出当前dump文件中，所有的线程信息，展示出了所有的线程，主线程，以及各个线程中的浅堆和深堆占用的大小，类加载器，是否守护线程等信息。
![9PZQ%HKT$Y2FYPSGMQ84AM.png
以main线程为例，列举出了里面的成员变量的信息，比如在当前的main线程中，有一个成员变量包含了很多对象，并且浅堆和深堆的大小都很大。
@`_300N$3Q7(VTH4{54)77P.png

Domainator Tree组件

Domainator Tree指的是支配树的对象图，支配树体现了对象实例之间的支配关系，理解支配树的目的是，在我们分析dump文件时，可以通过支配树，清楚的知道某个对象引用的对象情况。
N2OV1)MOJLALB0WC@1OD~4B.png
Retained Heap表示这个对象以及它所持有的其它引用（包括直接和间接）所占的总内存，因此从上图中看，前两行的Retained Heap是最大的，我们分析内存泄漏时，内存最大的对象也是最应该去怀疑的。

Leak Suspects组件

点击Leak Suspects查看具体的内存泄露报告，MAT分析工具会根据你导入的dump文件，快速生成一份怀疑报告，将可能出现内存泄露的点展示出来，便于开发或运维人员进行问题定位。
O_B4E(Q0%(FEJ8VPONHD)NY.png
~M8D57C2KA[9]CC.png
在内存泄漏报告中Thread Stack可以清晰的看到内存溢出代码的位置，对于快速定位程序问题非常方便友好
YW69@($6G}KL5VZPSB1WQ.png

常用分析技巧

第一种：通过Thread Overview线程视图，按照Retained Heap深堆大小排序，展开线程查看，从调用栈中找到当前服务的代码。
第二种：通过histogram内存大小直方图，选择group by package按照包路径分组，再按照Retained Heap深堆大小排序，找到当前服务的代码。
第三种：通过Dominator Tree 支配树，按照Retained Heap深堆大小排序，然后查看深堆最大的线程在持有哪些大对象，接着在该对象右键查看线程详细堆栈信息。

战神刘玉栋
关注
  • 6
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
C++开发值得推荐的十大高效软件分析工具
dvlinker的技术专栏
06-16 1万+
本文详细讲述在Windows C++软件的日常开发和维护的过程中用到的一些常用工具，借助这些工具，可以高效快速地分析和排查软件开发调试过程中遇到的各种问题。
JVM内存溢出分析：堆内存溢出+虚拟机
m0_69379068的博客
04-20 206
Exception in thread “Thread-0” java.lang.StackOverflowError 的异常。 （2）OutOfMemoryError：如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出 OutOfMemoryError。 我们可以这样理解，虚拟机中可以供栈占用的空间≈可用物理内存 - 最大堆内存 - 最大方法区内存，比如一台机器内存为 4G，系统和其他应用占用 2G，虚拟机可用的物理内存为 2G，最大堆内存为 1G，最大方法区内存为 512M，那可供栈占有的内存大约.
JVM发生内存溢出的8种原因：java高并发实战
m0_57205780的博客
07-05 168
一般来说，零基础从入门到就业，所学学习内容如下，今天划重点的内容是第一个文件夹：001基础（se） 二、其中第一个文件夹，001基础（se）作为整个java的语法思想等基础，下面我来进行划分下内容重点及删除不必要的学习内容（绝不影响后面工作），大纲如下，原本学时一个月 开始划重点 打— 横线的内容，为中速看（播放速度调成1.6倍），知道即可，有兴趣可以敲 框起来的为必须看，慢速1.3倍看，理解，并一定要敲代码，且做笔记！ 一、语言基础（这是最基础的东西，其实没什么好划的，都要会，学时五天）
【JVM】Java内存溢出分析（堆溢出、栈溢出、方法区溢出、直接内存溢出）
小明的Java问道之路
11-14 2019
Java内存溢出的原因为程序在申请内存（堆/栈/方法区/直接内存等等）时，没有足够的内存空间。
完美收官！java程序内存溢出找原因
m0_58397123的博客
07-02 725
原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 如上，微服务的应用场景和核心竞争力： 降低耦合：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署：由于微服务具备独立的运行进程，所以
《企业实战分享 · MyBatis 使用合集》
最新发布
山人行
06-30 1065
对于Java程序猿而言，MyBatis应该是企业开发中再熟悉不过的技术了，通常搭配Spring使用。笔者所在公司也采用了作为持久层框架，这边汇总分享若干MyBatis日常使用场景及应对方案，希望与君共勉。Tips：这里不介绍MyBatis的基础用法，默认大家都熟悉了。上文分享若干企业实际开发中，MyBatis的日常使用场景及应对方案，希望对大家有帮助。💗 后续会逐步分享企业实际开发中的实战经验，有需要交流的可以联系博主。
JVM发生内存溢出的8种原因：java提取文档注释
m0_57081368的博客
07-24 175
第一个 分布式：限流 1.1 ZooKeeper+Nginx面试常备题（附答案） ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括:配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 ZooKeeper 是什么？ ZooKeeper 提供了
系统内存溢出解决办法
weixin_33884611的博客
01-14 182
2019独角兽企业重金招聘Python工程师标准>>> ...
Redis Sorted Set 实战案例分析
Wildwolf_的博客
03-28 3334
本文通过企业实战案例分析，讲解业务需求设计思路和方案演进，以及Redis Sorted Set数据结构的使用场景。
Tomcat内存溢出分析及解决方法
09-05
1. 监控和分析内存使用情况，使用工具如VisualVM、JProfiler等。 2. 调整JVM内存参数，确保堆和非堆内存大小适中，同时考虑服务器的硬件资源。 3. 优化代码，避免创建大量临时或无用的对象，减少内存压力。 4. 对于...
WAS 内存溢出分析
12-04
Websphere Application Server WAS 内存溢出分析，帮助分析内存问题
android内存及内存溢出分析详解
09-05
Android开发者应定期使用工具如MAT（Memory Analyzer Tool）或Android Studio的内存分析工具进行内存监控，以便尽早发现并修复内存问题。 总的来说，理解Android内存机制和内存溢出的原因，以及采取适当的预防措施...
Java常见内存溢出异常分析
01-20
下面我们通过一段代码来模拟一下此种情况的内存溢出。 　import java.util.*; 　import java.lang.*; 　public class OOMTest{ 　public void stackOverFlowMethod(){ 　stackOverFlowMetho
Java内存溢出及分析
12-22
对于内存溢出，首先想到...既然分析内存溢出，那从这几种内存逐一分析。 　1，程序计数器：是一个较小的内存空间，是但钱线程的字节码行号指示器，这个不会出现内存溢出。 　2，虚拟即栈：虚拟即栈抛出的异常叫做Sta
配置系统PATH环境变量
weixin_44626980的博客
06-29 629
PATH环境变量在操作系统中起着非常重要的作用，特别是在命令行或脚本中执行程序时，系统会根据PATH环境变量中定义的路径查找可执行文件。当用户在命令行或脚本中输入一个命令时，系统会根据PATH环境变量中定义的路径依次查找对应的可执行文件，如果找到则执行。本文详细介绍了如何配置系统的PATH环境变量，包括在Windows和Linux系统中的操作步骤。在Linux系统中，可以通过编辑shell配置文件来配置PATH环境变量，常用的shell配置文件包括.bashrc、.bash_profile等。
【C#】找不到属性集方法。get只读属性用了反射设置setValue肯定报错
小5聊的博客
06-26 1802
找不到属性集方法。get只读属性用了反射设置setValue肯定报错
基于weixin小程序智慧物业系统的设计
ing65768的博客
06-27 455
管理员账户功能包括：系统首页，个人中心，管理员管理，用户管理，员工管理，房屋管理，缴费管理，车位管理，报修管理。主要技术：Java,Spring,mybatis,mysql,jquery,html。工作人员账号功能包括：系统首页，维修管理，维修指派，公告管理，轮播图信息。服务器：SpringBoot自带 apache tomcat。JDK版本：Java JDK1.8。数据库可视化工具： navicat。数据库版本： mysql5.7。开发工具：IDEA(推荐)开发系统：Windows。
解决Java中的数组越界异常的技术
weixin_44627014的博客
06-26 842
通过本文的讨论，我们了解了如何有效地处理Java中的数组越界异常。预防异常的发生，合理使用异常处理机制以及考虑使用集合类来替代数组，是确保Java应用程序稳定性和可靠性的关键步骤。
arthas 栈内存溢出分析
09-07
arthas 是一款 Java 生态下的开源应用性能诊断工具，它可以帮助开发者分析和排查应用程序的性能问题。当出现栈内存溢出的情况时，arthas 提供了一些分析方法帮助我们定位问题的根源。 首先，可以使用 arthas 的 thread 命令查看当前线程的栈信息，包括线程名、线程状态、调用栈等。通过查看栈信息，可以确定哪个线程的栈内存溢出。 其次，arthas 的 jvm 命令可以查看虚拟机的内存使用情况。我们可以使用该命令查看 JVM 的堆栈信息、GC 日志等信息，以便分析哪些对象占用了较大的栈内存。 此外，arthas 还提供了 watch 命令，可以监控某个方法的执行情况。我们可以使用该命令监控可能导致栈内存溢出的方法，并观察其参数、返回值以及方法执行的时间等信息。 最后，arthas 还支持对线程进行 profiling 和 trace。profiling 可以帮助我们查看线程的 CPU 使用情况，从而确定是否存在 CPU 耗尽导致栈内存溢出的问题；trace 可以帮助我们追踪方法的调用路径，进一步确定栈内存溢出异常的发生位置。 总而言之，arthas 提供了丰富的功能和命令，可以帮助我们分析栈内存溢出的问题。通过查看线程栈信息、JVM 内存使用情况、以及监控方法的执行等手段，我们可以定位和排查栈内存溢出的原因，并进行针对性的优化和调试。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

战神刘玉栋

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值