当前位置: 首页 > news >正文

解密JVM崩溃(Crash)-学习笔记

JVM崩溃例子

代码

import sun.misc.Unsafe;import java.lang.reflect.Field;/*** @title Crash* @description 虚拟机崩溃异常代码:* author zzw* version 1.0.0* create 2024/8/17 21:03**/
public class Crash {public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");unsafeField.setAccessible(true);Unsafe unsafe = (Unsafe) unsafeField.get(null);unsafe.getInt(-1);}
}

异常日志头部信息

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xf6e6fb3a, pid=16371, tid=0xf6543b40
#
# JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0_401-b10)
# Java VM: Java HotSpot(TM) Server VM (25.401-b10 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x8e9b3a]  Unsafe_GetNativeInt+0xda
#
# Core dump written. Default location: /root/test/core or core.16371
#
# An error report file with more information is saved as:
# /root/test/hs_err_pid16371.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

崩溃日志详解

文件路径

Java程序崩溃时,默认在当前进程运行目录下生成hs_err_pid进程PID.log日志文件。

自定义文件生成位置:-XX:ErrorFile=/Users/zzw/Documents/sourcecode/jvmdir/hs_err_pid%p.log

需要注意的是,如果由于一些异常原因在工作目录无法存储(比如写入权限不足),则该文件会被存储在操作系统的临时目录下。在Linux操作系统环境下,这个地址是**/tmp**。

概要信息

崩溃日志包含系统崩溃时获取到的相关信息,包括但不限于:

  • 导致进行崩溃的异常操作或信号
  • 版本和配置信息
  • 导致进程崩溃的线程的详细信息和线程的堆栈跟踪
  • 正在运行的线程队列及其状态
  • 关于堆的摘要信息
  • 加载的本地库列表
  • 命令行参数
  • 系统变量
  • 关于操作系统和CPU的详细信息

Java虚拟机崩溃时,生产的崩溃日志文件默认会分为4大部分内容

  1. 提供崩溃简要描述的头部信息
  2. 线程信息
  3. 进程信息
  4. 系统信息
头部信息
崩溃原因
SIGSEGV (0xb) at pc=0xf6e6fb3a, pid=16371, tid=0xf6543b40
  • SIGSEGV:信号名称
  • (0xb):信号编号
  • 0xf6e6fb3a:程序计数器
  • 16371:进程ID
  • 0xf6543b40:线程ID
问题栈帧

代码崩溃发生的位置

# Problematic frame:
# V  [libjvm.so+0x8e9b3a]  Unsafe_GetNativeInt+0xda

**栈帧(frame)**表示程序运行时函数调用栈中的某一帧。

栈帧前面大写字母的特点含义

栈帧(frame)类型说明场景
大写字母CNative帧如第三方动态链接库
小写字母jJava帧多指未经JIT编译的Java代码
大写字母JJava帧多指JIT编译后的帧
小写字母v虚拟机运行时自动生成的帧如JNI调用、反射、异常处理等部分场景下,虚拟机生成的一小段兼容或优化的桥接代码
大写字母V虚拟机内部帧虚拟机内部函数帧
核心转储文件
# Core dump written. Default location: /root/test/core or core.16371
  • 完整性和全局视角:操作系统的coredump包含了整个进程的内部转储,包括了JVM本身的内存以及JVM进程所依赖的操作系统资源的状态。这提供了更全面的视角,有助于诊断问题的根源。
  • 内存信息:操作系统的coredump包含了进程的完整内存镜像,包括了堆和栈的信息,这对于分析内存状态以及发现内存相关的问题非常重要。
  • 操作系统资源状态:coredump还可以提供操作系统级别的资源状态信息,比如打开的文件、网络连接等。这些信息可以帮助诊断和解决一些与操作系统资源相关的问题。
  • 与调试器的兼容性:一些调试器可能更喜欢使用操作系统的coredump进行分析和调试。在某些情况下,使用coredump可能更容易进行深入的调试和分析。
线程信息
线程概要
---------------  T H R E A D  ---------------Current thread (0xf6307400):  JavaThread "main" [_thread_in_vm, id=16372, stack(0xf64f4000,0xf6544000)]
  • 0xf6307400:pointer(线程内存指针)

  • JavaThread:type(线程类型)

    • JavaThread
    • VMThread
    • CompilerThread
    • GCTaskThread
    • WatcherThread
    • ConcurrentMarkSweepThread
    • JvmtiAgentThread
    • ServiceThread
    • CodeCacheSweeperThread
  • main:name(线程名称)

  • _thread_in_vm:线程状态(仅限Java线程)

    线程状态说明
    _thread_uninitialized虚拟机内部创建线程异常状态(可不要关注)
    _thread_new线程已创建,但是还未执行
    _thread_in_native线程正在执行native代码
    _thread_in_vm线程正在执行虚拟机内部代码
    _thread_in_java线程正在执行Java代码(包括JIT)
    _thread_blocked线程被阻塞

    极限场景下的一些瞬时中转状态

    线程状态说明
    _thread_new_trans正在转变为_thread_new状态
    _thread_in_native_trans正在转变为_thread_in_native状态
    _thread_in_vm_trans正在转变为_thread_in_vm状态
    _thread_in_Java_trans正在转变为_thread_in_java状态
    _thread_blcoked_trans正在转变为_thread_blocked状态
  • 37696:线程ID

  • stack:线程栈的范围

信号量概要

导致线程终止的意外信号

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0xffffffff

异常码11,它对应的信号量是**SIGSEGV,这是崩溃时最为常见的一种信号量,意味着当前进程正在从非法内存值读取内容(si_addr)。简单来说,每个进程所能读写的内存是有一定范围的,如果超出这个范围进行内存读写是会被操作系统认为是非法的操作。SIGSEGV同时下面有2种不同的si_code,分别是SEGV_MAPERR(未映射的地址)、SEGV_ACCERR**(无效的访问许可)。

寄存器
Registers:
EAX=0xf714cbdc, EBX=0xf711aff4, ECX=0xf7157ee0, EDX=0xf6307400
ESP=0xf6542fd0, EBP=0xf6542ff8, ESI=0xf6307400, EDI=0xffffffff
EIP=0xf6e6fb3a, EFLAGS=0x00010a07, CR2=0xffffffff
栈地址
Top of Stack: (sp=0xf6542fd0)
0xf6542fd0:   f6307400 f711aff4 f7148688 f6a9fdab
0xf6542fe0:   a3516210 a3516210 f6e6fa6b a3516210
0xf6542ff0:   a3516210 f6307400 f6543034 e730f084
0xf6543000:   f6307540 f654304c ffffffff ffffffff
0xf6543010:   e730ee5b f6543014 a3516210 f654304c
0xf6543020:   a353a130 00000000 a3516210 00000000
0xf6543030:   f6543044 f6543070 e7304b60 00000000
0xf6543040:   e730aad9 ffffffff ffffffff d18c7a88 
指令上下文
Instructions: (pc=0xf6e6fb3a)
0xf6e6fb1a:   e4 c7 86 7c 01 00 00 06 00 00 00 89 e2 c1 ea 0c
0xf6e6fb2a:   8d 8b ec ce 03 00 8b 14 91 c6 82 94 01 00 00 01
0xf6e6fb3a:   8b 3f c6 82 94 01 00 00 00 89 7d e4 8b 7e 28 8b
0xf6e6fb4a:   4f 08 8b 57 04 83 39 00 74 28 89 45 d8 50 50 89 
寄存器内容
Register to memory mapping:EAX=0xf714cbdc: <offset 0xbc6bdc> in /root/seckill_server/java/jdk8/jre/lib/i386/server/libjvm.so at 0xf6586000
EBX=0xf711aff4: <offset 0xb94ff4> in /root/seckill_server/java/jdk8/jre/lib/i386/server/libjvm.so at 0xf6586000
ECX=0xf7157ee0: <offset 0xbd1ee0> in /root/seckill_server/java/jdk8/jre/lib/i386/server/libjvm.so at 0xf6586000
EDX=0xf6307400 is a thread
ESP=0xf6542fd0 is pointing into the stack for thread: 0xf6307400
EBP=0xf6542ff8 is pointing into the stack for thread: 0xf6307400
ESI=0xf6307400 is a thread
EDI=0xffffffff is an unknown value
栈帧明细
Stack: [0xf64f4000,0xf6544000],  sp=0xf6542fd0,  free space=315k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x8e9b3a]  Unsafe_GetNativeInt+0xda
j  sun.misc.Unsafe.getInt(J)I+0
j  Crash.main([Ljava/lang/String;)V+26
v  ~StubRoutines::call_stub
V  [libjvm.so+0x521d49]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0xb59
V  [libjvm.so+0x520fde]  JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x2e
V  [libjvm.so+0x5766f0]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .constprop.1]+0x260
V  [libjvm.so+0x578239]  jni_CallStaticVoidMethod+0xc9
C  [libjli.so+0x72bc]  JavaMain+0x46c
C  [libpthread.so.0+0x6bbc]  start_thread+0xcc
C  [libc.so.6+0xfe27e]  clone+0x5eJava frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.misc.Unsafe.getInt(J)I+0
j  Crash.main([Ljava/lang/String;)V+26
v  ~StubRoutines::call_stub
进程信息
进程里的线程

展示了虚拟机内部的Java线程以及其他线程信息。**=>**标识了那个线程是当前的线程

---------------  P R O C E S S  ---------------Java Threads: ( => current thread )0xa2fae000 JavaThread "Service Thread" daemon [_thread_blocked, id=16403, stack(0xa3201000,0xa3252000)]0xa2f99400 JavaThread "C1 CompilerThread3" daemon [_thread_blocked, id=16402, stack(0xa23ff000,0xa247f000)]0xa2f97c00 JavaThread "C2 CompilerThread2" daemon [_thread_blocked, id=16401, stack(0xa2480000,0xa2500000)]0xa2f96400 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=16400, stack(0xa2780000,0xa2800000)]0xa2f94800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=16399, stack(0xa291b000,0xa299b000)]0xa2f92c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=16398, stack(0xa5e2e000,0xa5e7f000)]0xa2f78c00 JavaThread "Finalizer" daemon [_thread_blocked, id=16385, stack(0xa622e000,0xa627f000)]0xa2f75c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=16383, stack(0xa642e000,0xa647f000)]
=>0xf6307400 JavaThread "main" [_thread_in_vm, id=16372, stack(0xf64f4000,0xf6544000)]Other Threads:0xa2f70400 VMThread [stack: 0xa3253000,0xa32d3000] [id=16381]0xa2fb1800 WatcherThread [stack: 0xa237e000,0xa23fe000] [id=16404]
虚拟机安全状态
VM state:not at safepoint (normal execution)
  • not at safepoint:正常状态
  • at safepoint:所有线程处于安全点等待VM进行一些重要的操作,比如GC、Debug等
  • synchronizing:这是一个瞬时的状态。VM等待所有线程到达safepoint,已经达到safepoint的线程会挂起
锁&监视器
VM Mutex/Monitor currently owned by a thread: None

当前线程所用于的互斥锁Mutex和监视器Monitor列表。这些互斥锁和监视器是虚拟机内部的锁和监视器,而不是与Java对象相关的锁和监视器。所以却大多数的崩溃文件下,这里输出都是None

内存使用摘要
Heap:PSYoungGen      total 19200K, used 665K [0xd18c0000, 0xd2e00000, 0xe6e00000)eden space 16640K, 4% used [0xd18c0000,0xd19666a0,0xd2900000)from space 2560K, 0% used [0xd2b80000,0xd2b80000,0xd2e00000)to   space 2560K, 0% used [0xd2900000,0xd2900000,0xd2b80000)ParOldGen       total 43776K, used 0K [0xa6e00000, 0xa98c0000, 0xd18c0000)object space 43776K, 0% used [0xa6e00000,0xa6e00000,0xa98c0000)Metaspace       used 1735K, capacity 2202K, committed 2328K, reserved 4400K
GC辅助模型
Card table byte_map: [0xa6bff000,0xa6e00000] byte_map_base: 0xa66c8000Marking Bits: (ParMarkBitMap*) 0xf714c080Begin Bits: [0xa3d00000, 0xa4d00000)End Bits:   [0xa4d00000, 0xa5d00000)

卡表是一个标准的空间换时间的解决方案。卡表通常在 JVM 中实现为单字节数组。当我们把 JVM 划分成不同区域的时候,每一个区域(通常是4k字节)就得到了一个标志位。每一位为 1 的时候,表明这个区域为 dirty,持有新生代对象,否则这个区域不持有新生代对象。这样,新生代垃圾收集器在收集live set 的时候,可以通过以下两个操作:

  • 从栈/方法区出发,进入新生代扫描。
  • 从栈/方法区出发,进入老年代扫描,且只扫描 dirty 的区域,略过其他区域。
polling page
Polling page: 0xf7768000
  • JIT下虚拟机在指定代码位置完成安全点代码的放置,代码的内容是读取一小块内存(就是这里的polling page)
  • GC时设置这块内存不可读
  • 其他线程代码运行到安全点发现代码不可读,操作系统层面抛出SIGSEGV信号
  • 虚拟机在启动是就完成SIGSEGV信号注册,来监听本次SIGSEGV的内存代码是否是polling page位置
  • 如果是,进程不终止,当前线程进入安全点,线程挂起为后续GC做准备
CodeCache
CodeCache: size=245760Kb used=681Kb max_used=681Kb free=245078Kbbounds [0xe7300000, 0xe7540000, 0xf6300000]total_blobs=170 nmethods=13 adapters=72compilation: enabled

首先日志给出了整个CodeCahe的使用情况,第一行给出了总大小(245760kb),已使用(681Kb),空闲(245078kb)。第二行用更直观的方式给出了内存上下界(bounds)。以上图为例,这里的0xe7300000代表了CodeCache内存区域的下界,对应的0xf6300000则是内存上界,0xe7540000代表的是已使用内存的边界(可以理解这个边界就是已使用的指针)。

CodeCache内部本质上是各种大小不一的内存块。有的是方法经由JIT编译后的代码,有的是动态生成的元数据等等。当前系统一共有170个内存块,其中13个JIT编译过的方法,以及72个adapters。这些adapters其实是虚拟机内部在解释模式和编译模式下的一种适配,所有方法的默认入口都是解释模式,虚拟机内部会判断当前方法是否已经编译过了,如果已编译则基于adapter路由到已编译的方法,否则继续解释执行

事件分析
编译事件
Compilation events (10 events):
Event: 0.036 Thread 0xa2f99400    5       3       java.lang.AbstractStringBuilder::ensureCapacityInternal (27 bytes)
Event: 0.037 Thread 0xa2f99400 nmethod 5 0xe73ab608 code [0xe73ab760, 0xe73aba98]
Event: 0.037 Thread 0xa2f99400   10       1       java.lang.ref.Reference::get (5 bytes)
Event: 0.037 Thread 0xa2f99400 nmethod 10 0xe73ab408 code [0xe73ab500, 0xe73ab5a0]
Event: 0.038 Thread 0xa2f99400   11       1       java.lang.ThreadLocal::access$400 (5 bytes)
Event: 0.038 Thread 0xa2f99400 nmethod 11 0xe73ab208 code [0xe73ab300, 0xe73ab380]
Event: 0.038 Thread 0xa2f99400   12       3       java.lang.AbstractStringBuilder::append (50 bytes)
Event: 0.039 Thread 0xa2f99400 nmethod 12 0xe73aa808 code [0xe73aa980, 0xe73aaf10]
Event: 0.039 Thread 0xa2f99400   13       3       java.lang.String::getChars (62 bytes)
Event: 0.039 Thread 0xa2f99400 nmethod 13 0xe73aa188 code [0xe73aa2e0, 0xe73aa5f0]

Compilation events 显示了最近10次从Java字节码编译为机器码的方法。这里有一个需要关注的点:**如果你的机器多次崩溃看到的编译事件都相同,可能意味着JVM正在错误的编译当前方法。**如果不明白为何虚拟机会出现这种错误,你可以尝试重写方法将其简化、拆分等,这将有助于你避免相关的崩溃问题。或者也可以利用虚拟机提供的命令来禁止指定方法的编译,比如:

-XX:CompileCommand="exclude java.util.ArrayList::add"

GC历史事件(GC Heap History)

这里会列举出了系统在崩溃时出现的近10次GC

GC Heap History (0 events):
No events
逆优化事件(Deoptimization events)
Deoptimization events (0 events):
No events

JIT基于特定条件和假设完成代码编译后,在一些场景下,虚拟机突然发现当前的特定条件和假设不满足,当前编译好的方法如果继续执行会发生一些意料之外的情况,此时虚拟机就会触发自动逆优化,针对已经编译好的方法做特定处理,确保整体运行准确。

内存映射明细
f7746000-f775d000 r-xp 00000000 fd:01 2122494                            /usr/lib/libpthread-2.17.so
f775d000-f775e000 r--p 00016000 fd:01 2122494                            /usr/lib/libpthread-2.17.so
f775e000-f775f000 rw-p 00017000 fd:01 2122494                            /usr/lib/libpthread-2.17.so
f775f000-f7762000 rw-p 00000000 00:00 0 
f7762000-f7764000 rw-p 00000000 00:00 0 
f7767000-f7768000 rw-p 00000000 00:00 0 
f7768000-f7769000 r--p 00000000 00:00 0 
f7769000-f776a000 rw-p 00000000 00:00 0 
f776a000-f776b000 r-xp 00000000 00:00 0                                  [vdso]
f776b000-f778d000 r-xp 00000000 fd:01 2122461                            /usr/lib/ld-2.17.so
f778d000-f778e000 r--p 00021000 fd:01 2122461                            /usr/lib/ld-2.17.so
f778e000-f778f000 rw-p 00022000 fd:01 2122461                            /usr/lib/ld-2.17.so
ffbb8000-ffbd9000 rw-p 00000000 00:00 0                                  [stack]
  • [第1列]显示内存区域的起始地址。每个区域代表进程的不同内存映射。
  • [第2列]内存映射区域的访问权限。这里的p代表的是(private)
  • [第5列]指实际在内存中占用的字节数。
  • [第6列]显示内存区域的映射信息,通常包括文件名或其他标识符。如果是匿名内存(未映射到文件),则会显示类似 [heap]、[stack]、[anon] 这样的标识。
启动参数&环境变量
VM Arguments:
java_command: Crash
java_class_path (initial): .
Launcher Type: SUN_STANDARDEnvironment Variables:
PATH=/root/seckill_server/java/jdk8/bin:/usr/local/nginx-1.17.2/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
SHELL=/bin/bash
信号处理
Signal Handlers:
SIGSEGV: [libjvm.so+0x922f80], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGBUS: [libjvm.so+0x922f80], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGFPE: [libjvm.so+0x922f80], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGPIPE: [libjvm.so+0x789a50], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGXFSZ: [libjvm.so+0x789a50], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGILL: [libjvm.so+0x922f80], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGUSR1: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none
SIGUSR2: [libjvm.so+0x789ac0], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO
SIGHUP: [libjvm.so+0x78a1c0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGINT: [libjvm.so+0x78a1c0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGTERM: [libjvm.so+0x78a1c0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
SIGQUIT: [libjvm.so+0x78a1c0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
系统信息
系统信息概要
---------------  S Y S T E M  ---------------OS:CentOS Linux release 7.5.1804 (Core) uname:Linux 3.10.0-1160.92.1.el7.x86_64 #1 SMP Tue Jun 20 11:48:01 UTC 2023 x86_64
libc:glibc 2.17 NPTL 2.17 
rlimit: STACK 8192k, CORE infinity, NPROC 63453, NOFILE 65535, AS infinity
load average:0.06 0.33 0.27
系统内存概括
/proc/meminfo:
MemTotal:       16264988 kB
MemFree:        10207936 kB
MemAvailable:   12058044 kB
Buffers:           85876 kB
Cached:          1974164 kB
SwapCached:            0 kB
Active:          4048200 kB
Inactive:        1576592 kB
Active(anon):    3565492 kB
Inactive(anon):     8700 kB
Active(file):     482708 kB
Inactive(file):  1567892 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                48 kB
Writeback:             0 kB
AnonPages:       3562968 kB
Mapped:           256152 kB
Shmem:              9444 kB
Slab:             156004 kB
SReclaimable:     106592 kB
SUnreclaim:        49412 kB
KernelStack:       17200 kB
PageTables:        26404 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8132492 kB
Committed_AS:   13224244 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       34460 kB
VmallocChunk:   34359698612 kB
Percpu:             2560 kB
HardwareCorrupted:     0 kB
AnonHugePages:   1660928 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       89600 kB
DirectMap2M:     4104192 kB
DirectMap1G:    14680064 kB

这些内容其实就是系统崩溃瞬时**cat /proc/meminfo的输出明细。/proc/meminfo是了解Linux系统内存使用状况的主要接口(需要注意的是在当前的MacOS开发环境并不适用),我们最常用的freevmstat**等命令就是通过它获取数据的 ,但一般来说在排查一些内存泄漏问题,利用meminfo的输出还是非常有帮助

CPU信息概括
CPU:total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 106 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms, rtm, 3dnowpref, lzcnt, ht, tsc, tscinvbit, bmi1, bmi2, adx/proc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 106
model name      : Intel(R) Xeon(R) Platinum 8378C CPU @ 2.80GHz
stepping        : 6
microcode       : 0x1
cpu MHz         : 2799.998
cache size      : 58368 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 arat avx512vbmi umip avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq md_clear spec_ctrl intel_stibp arch_capabilities
bogomips        : 5599.99
clflush size    : 64
cache_alignment : 64
address sizes   : 42 bits physical, 48 bits virtual
power management:
processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 106
model name      : Intel(R) Xeon(R) Platinum 8378C CPU @ 2.80GHz
stepping        : 6
microcode       : 0x1
cpu MHz         : 2799.998
cache size      : 58368 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 arat avx512vbmi umip avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq md_clear spec_ctrl intel_stibp arch_capabilities
bogomips        : 5599.99
clflush size    : 64
cache_alignment : 64
address sizes   : 42 bits physical, 48 bits virtual
power management:processor       : 2
......

这里其实就是命令**cat /proc/cpuinfo**的输出明细,给出了当前机器的CPU型号、CPU制造商、产品代号、主频、二级缓存、浮点运算单元等信息。

其它信息
Memory: 4k page, physical 16264988k(10207936k free), swap 0k(0k free)vm_info: Java HotSpot(TM) Server VM (25.401-b10) for linux-x86 JRE (1.8.0_401-b10), built on Dec 19 2023 12:38:34 by "java_re" with gcc 11.2.0time: Sat Aug 17 22:17:51 2024
timezone: CST
elapsed time: 0.043262 seconds (0d 0h 0m 0s)

日志的结尾给出了内存,虚拟机版本等内容,但大多和之前重合,这里有一个有用的信息是elapsed time,它反映了从应用启动到崩溃一共耗时多久(我的例子里直接启动就主动让虚拟机立刻崩溃了所以这里是0)。

解密JVM崩溃(Crash):如何通过日志分析揭开神秘面纱|得物技术

相关文章:

  • 北京网站建设多少钱?
  • 辽宁网页制作哪家好_网站建设
  • 高端品牌网站建设_汉中网站制作
  • qt-12工具盒(ToolBox)
  • 数学基础 -- 指数增长与指数衰变
  • 使用Go语言将PDF文件转换为Base64编码
  • Wireshark分析工具
  • 构建艺术:Ruby中RESTful API的精粹实践
  • 【IDEA】idea配置服务器没有tomcat
  • 【Django开发】前后端分离django美多商城项目第1篇:欢迎来到美多 项目主要页面介绍【附代码文档】
  • SpringBoot-01-全局异常处理器
  • Docker 部署 XXL-JOB
  • fastzdp_sqlmodel框架是如何实现更新和删除相关的功能封装的,20240817,Python的国产新ORM框架
  • 对外提供开放式数据查询使用什么数据存储?
  • 蚂蚁AL1 15.6T 创新科技的新典范
  • Python 算法交易实验81 QTV200日常推进-重新实验SMA/EMA/RSI
  • 记录|Label组件如何控制下边框为直线
  • 初识Linux系统,Ubuntu基础使用
  • 「前端」从UglifyJSPlugin强制开启css压缩探究webpack插件运行机制
  • 5、React组件事件详解
  • CentOS6 编译安装 redis-3.2.3
  • CentOS学习笔记 - 12. Nginx搭建Centos7.5远程repo
  • Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包
  • java 多线程基础, 我觉得还是有必要看看的
  • leetcode386. Lexicographical Numbers
  • Netty 框架总结「ChannelHandler 及 EventLoop」
  • Spark in action on Kubernetes - Playground搭建与架构浅析
  • SpringBoot 实战 (三) | 配置文件详解
  • UEditor初始化失败(实例已存在,但视图未渲染出来,单页化)
  • 彻底搞懂浏览器Event-loop
  • 初识MongoDB分片
  • 服务器从安装到部署全过程(二)
  • 基于游标的分页接口实现
  • 面试题:给你个id,去拿到name,多叉树遍历
  • 前端面试总结(at, md)
  • 学习笔记TF060:图像语音结合,看图说话
  • python最赚钱的4个方向,你最心动的是哪个?
  • RDS-Mysql 物理备份恢复到本地数据库上
  • Spring Batch JSON 支持
  • 浅谈sql中的in与not in,exists与not exists的区别
  • ​LeetCode解法汇总1410. HTML 实体解析器
  • ${factoryList }后面有空格不影响
  • (02)Cartographer源码无死角解析-(03) 新数据运行与地图保存、加载地图启动仅定位模式
  • (day 12)JavaScript学习笔记(数组3)
  • (day 2)JavaScript学习笔记(基础之变量、常量和注释)
  • (PADS学习)第二章:原理图绘制 第一部分
  • (二)pulsar安装在独立的docker中,python测试
  • (附源码)计算机毕业设计大学生兼职系统
  • (六)Flink 窗口计算
  • (三)uboot源码分析
  • (转)清华学霸演讲稿:永远不要说你已经尽力了
  • ***详解账号泄露:全球约1亿用户已泄露
  • .NET Core 实现 Redis 批量查询指定格式的Key
  • .NET Core工程编译事件$(TargetDir)变量为空引发的思考
  • .net 重复调用webservice_Java RMI 远程调用详解,优劣势说明
  • .Net的DataSet直接与SQL2005交互
  • /dev/sda2 is mounted; will not make a filesystem here!
  • /proc/interrupts 和 /proc/stat 查看中断的情况