dump文件

前提概要： JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。 现实企业级Java开发中，有时候我们会碰到下面这些问题： OutOfMemoryError，内存不足 内存泄露 线程死锁 锁争用（Lock Contention） Java进程消耗CPU过高 ...... 这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。 一、 jps(Java Virtual Machine Process Status Tool) ： 基础工具 实际中这是最常用的命令，下面要介绍的小工具更多的都是先要使用jps查看出当前有哪些Java进程，获取该Java进程的id后再对该进程进行处理。 jps主要用来输出JVM中运行的进程状态信息。语法格式如下： Java代码 jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： Java代码

Thread Dump 日志的线程信息 以上依次是： "resin-22129" 线程名称： 如果使用 java.lang.Thread 类生成一个线程的时候，线程名称为 Thread-( 数字 ) 的形式，这里是 resin 生成的线程； daemon 线程类型： 线程分为守护线程 (daemon) 和非守护线程 (non-daemon) 两种，通常都是守护线程； prio=10 线程优先级： 默认为 5 ，数字越大优先级越高； tid=0x00007fbe5c34e000 JVM 线程的 id ： JVM 内部线程的唯一标识，通过 java.lang.Thread.getId() 获取，通常用自增的方式实现； nid=0x4cb1 系统线程 id ： 对应的系统线程 id （ Native Thread ID) ，可以通过 top 命令进行查看，现场 id 是十六进制的形式； waiting on condition 系统线程状态： 这里是系统的线程状态，具体的含义见下面 系统线程状态 部分； [0x00007fbe4ff7c000] 起始栈地址： 线程堆栈调用的其实内存地址； java.lang.Thread.State: WAITING (parking) JVM 线程状态： 这里标明了线程在代码级别的状态，详细的内容见下面的 JVM 线程运行状态 部分。 线程调用栈信息：

fsdbDumplimit - 限制FSDB文件size -- $fsdbDumpvars([<level>], <scope | signal>*) fsdbDumpfile - 指定FSDB文件名 -- $fsdbDumpfile(“<FSDB name>”) fsdbDumpvars - Dump指定的变量 -- fsdbDumpSingle - Dump指定的信号 fsdbDumpvariable - Dump指定的VHDL变量 fsdbSwitchDumpFile - 将dumping切换到另一个FSDB文件 -- $fsdbSwitchDumpFile(“<new FSDB name>”) fsdbAutoSwitchDumpfile - 限制文件大小并在数据量过大时自动创建新的FSDB文件 -- $fsdbAutoSwitchDumpfile(<file size>, “<FSDB name>”,< number of file>) fsdbDumpflush - Force to Dump Result to FSDB file fsdbDumpMem - Dump 指定的memory的内容 -- $fsdbDumpMem(<reg name>, [<start addr>, [<size>]]) $fsdbDumpon - 打开 FSDB dumping

在上一篇文件文章中讲到了jhap的用法： https://www.cnblogs.com/cheng21553516/p/11223615.html ，既然jhap可以转储堆的快照文件， 那么用什么来分析堆的快照文件，这个分析命令就是jhat 生成堆的快照文件：jmap -dump:live,format=b,file=e:\\test.bin 17312 用jhat命令来打开：jhat test.bin ， 显示"Server is ready"时，就表示jhat已经把这个快照文件解开了。我们可以在浏览器中输入http://localhost:7000来查看分析结果。 这个程序在堆中的相关信息，例如 All Class,代表JVM在启动这个类时要加载哪些类。以及一些其他的信息等等。 在实际工作中，一般都不会去直接使用jhat命令来分析dump文件，主要原因有二：一是一般不会在部署应用程序的服务器上直接分析dump文件，即使可以这样做，也会尽量将dump文件复制到其他机器上进行分析， 因为分析工作是一个耗时而且消耗硬件资源的过程，既然都要在其他机器进行，就没有必要受到命令行工具的限制了；另一个原因是jhat的分析功能相对来说比较简陋， 后文将会介绍到的VisualVM，以及专业用于分析dump文件的Eclipse MemoryAnalyzer、IBM HeapAnalyzer等工具

转载： https://www.cnblogs.com/bodhitree/p/5850212.html core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core dump. (linux中如果内存越界会收到SIGSEGV信号，然后就会core dump) 在程序运行的过程中，有的时候我们会遇到Segment fault(段错误)这样的错误。这种看起来比较困难，因为没有任何的栈、trace信息输出。该种类型的错误往往与指针操作相关。往往可以通过这样的方式进行定位。 一 造成segment fault，产生core dump的可能原因 1.内存访问越界 2 多线程程序使用了线程不安全的函数。 3 多线程读写的数据未加锁保护。对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成core dump 4 非法指针 a) 使用空指针 b) 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为bus error而core dump. 5

core dump 调试： gdb + 可执行文件名 + core dump 文件 gdb Searcher core.8159 bt 查看 来源： https://www.cnblogs.com/xinping-study/p/11757476.html

OutOfMemoryError，内存不足 内存容量 螺纹死锁 锁争用（锁争用） Java进程消耗CPU过高 A，jps（Java虚拟机进程状态工具） jps主要用于输出JVM中运行的进程状态信息。语法格式如下： jps [选项] [主机ID] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： -q不输出类名，Jar名和纳入主方法的参数 -m输出预设主方法的参数 -l输出main类或Jar的全限名 -v输出JVM的参数 例如下面： root @ ubuntu：/＃jps -m -l 2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2.2.5/etc/jetty.xml 29920 com.sun.tools.hat.Main主端口9998 /tmp/dump.dat 3149 org.apache.catalina.startup.Bootstrap启动 30972 sun.tools.jps.Jps -m -l 8247 org.apache.catalina.startup.Bootstrap启动 25687 com.sun.tools.hat.Main-端口9999 dump.dat 21711 mrf-center.jar B，jstack

其他调试参考文章 centos7使用lldb调试netcore应用转储dump文件 centos7 lldb 调试netcore应用的内存泄漏和死循环示例(dump文件调试) 生成dump文件 如何在docker容器里面创建dump文件请参考： dotnet core调试docker下生成的dump文件 构建一个dotnet，lldb的docker image dockerfile 文件，基于microsoft/dotnet:2.2-sdk安装lldb， docker builder -f dockerifle --pull -t dotnet-lldb build出来image FROM microsoft/dotnet:2.2-sdk RUN apt-get update && apt-get install -y \ cmake llvm-3.9 \ clang-3.9 \ lldb-3.9 \ liblldb-3.9-dev \ libunwind8 \ libunwind8-dev \ gettext \ libicu-dev \ liblttng-ust-dev \ libcurl4-openssl-dev \ libssl-dev \ uuid-dev \ libnuma-dev \ libkrb5-dev 安装dotnet-sos插件 dotnet

安装 1.下载工具windbg 地址： https://www.microsoft.com/zh-cn/p/windbg-preview/9pgjgd53tn86?SilentAuth=1&rtc=1&activetab=pivot:overviewtab 2.Dump文件：任务管理；选择w3wp.exe；右键；创建转储文件 WinDbg加载分析步骤 1.打开Dump文件找到上个步骤生成的dmp文件，点击打开，并等待加载完成（即命令行没有显示BUSY字样） 2.打开文件后，进行环境初始化，先创建目录 D:\Symbol，然后在WinDbg里执行如下命令 从微软下载Symbol档，并缓存到D盘的Symbol下： .sympath srv*D:\Symbol*https://msdl.microsoft.com/download/symbols 3.指定显示完整的Symbol下载信息： !sym noisy 自动加载CLR诊断相关模块，如果要分析其它机器的dump文件时，比较好用： 4. .cordll -ve -u -l 需要注意的是：有时加载其它机器的文件还是会无法加载，可以在dmp文件所在的机器上安装windbg进行诊断。 5.加载.net core版的sos扩展插件。输入： .load C:\Program Files\dotnet\shared\Microsoft

死循环、死锁、阻塞、页面打开慢等问题，打线程dump是最好的解决问题的途径。所谓线程dump也就是线程堆栈，获取到线程堆栈有两步： （1）获取到线程的pid，可以通过使用jps命令，在Linux环境下还可以使用ps -ef | grep java （2）打印线程堆栈，可以通过使用jstack pid命令，在Linux环境下还可以使用kill -3 pid 另外提一点，Thread类提供了一个getStackTrace()方法也可以用于获取线程堆栈。这是一个实例方法，因此此方法是和具体线程实例绑定的，每次获取获取到的是具体某个线程当前运行的堆栈 来源： https://www.cnblogs.com/Yanss/p/11686816.html