52.【面试宝典】面试宝典-JVM参数配置实战

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 【面试宝典】面试宝典-JVM参数配置实战

前文如下:

51.【面试宝典】面试宝典-JVM参数概述


1.jvm参数配置

1.1 查看测试环境

### jdk版本 openjdk11
java -version
openjdk version "11.0.12" 2021-07-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.12+7-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7-LTS, mixed mode, sharing)
###cpu 信息
#查看cpu信息,内容较多不展示
cat /proc/cpuinfo |grep name|cut -f2 -d: |uniq -c
cat /proc/cpuinfo
#查看物理cpu个数  --1个
cat /proc/cpuinfo |grep "physical id" |sort |uniq|wc -l
1
cat /proc/cpuinfo |grep "physical id" |sort |uniq
physical id : 0
cat /proc/cpuinfo |grep "physical id" |wc -l
8
cat /proc/cpuinfo |grep "physical id"
physical id : 0
physical id : 0
physical id : 0
physical id : 0
physical id : 0
physical id : 0
physical id : 0
physical id : 0
#查看每个物理cpu core核心数  --每个都是4个
 cat /proc/cpuinfo |grep "cpu cores" |uniq
cpu cores : 4
cat /proc/cpuinfo |grep "cpu cores" |wc -l
cpu cores : 4
cpu cores : 4
cpu cores : 4
cpu cores : 4
cpu cores : 4
cpu cores : 4
cpu cores : 4
cpu cores : 4
#查看逻辑cpu 个数
cat /proc/cpuinfo |grep "processor" |wc -l
8
## 1个物理cpu;4核;支持超线程; 8个逻辑cpu
## cpu总核数=物理cpu个数*每颗cpu核数;
## 逻辑cpu个数=物理cpu个数*每颗cpu核数*超线程数
###内存大小  14(预估16左右)
free -h
              total        used        free      shared  buff/cache   available
Mem:           14Gi       9.3Gi       4.9Gi       2.0Mi       730Mi       5.4Gi
Swap:            0B          0B          0B
### 操作系统信息  linux
uname -a
Linux 127.0.0.1 4.18.0-305.3.1.el8.x86_64 #1 SMP Tue Jun 1 16:14:33 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
cat /proc/version 
Linux version 4.18.0-305.3.1.el8.x86_64 (mockbuild@kbuilder.bsys.centos.org) 
(gcc version 8.4.1 20200928 (Red Hat 8.4.1-1) (GCC)) #1 SMP Tue Jun 1 16:14:33 UTC 2021
复制代码

1.2 查看启动参数

#设置启动参数
 ## 测试工程
 export PRO_NAME=test-project
 ## 工程目录
 export DEPLOY_PATH=/home/admin/java/test-project
 ## 启动参数
 export JAVA_OPTS="-server -Xms3072M -Xmx3072M  -XX:PretenureSizeThreshold=64m -XX:
 -OmitStackTraceInFastThrow -XX:+PrintCommandLineFlags -XX:MetaspaceSize=600m 
 -XX:MaxMetaspaceSize=600m -XX:+HeapDumpOnOutOfMemoryError 
 -XX:HeapDumpPath=/home/admin/java/test-project/logs/ 
 -Xlog:gc*,gc+ref=debug,gc+heap=debug,gc+age=trace:file=logs/gc.log:tags,uptime,time
 ,level:filecount=10,filesize=200m"
#设置启动脚本 
 exec nohup java -Dproject.home=$DEPLOY_PATH $JAVA_OPTS -jar $PRO_NAME >> /dev/null 2>&1 &
#查看启动进程
[admin@ 127.0.0.1]$ ps -ef|grep java
admin    1345636       1  2 Aug27 ?        
04:55:38 java -Dproject.home=/home/admin/java/test-project -server -Xms3072M -Xmx3072M -XX:PretenureSizeThreshold=64m -XX:-OmitStackTraceInFastThrow -XX:+PrintCommandLineFlags -XX:MetaspaceSize=600m 
-XX:MaxMetaspaceSize=600m -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/admin/java/test-project/logs/ 
-Xlog:gc*,gc+ref=debug,gc+heap=debug,gc+age=trace:file=logs/gc.log:tags,uptime,time,
level:filecount=10,filesize=200m 
-jar test-project.jar
[admin@ 127.0.0.1]$ jps
1345636 test-project.jar
2245365 Jps
复制代码

2 解析参数

JAVA_OPTS="
-server     #server模式
-Xms3072M   #初始堆大小
-Xmx3072M  #最大堆大小
-XX:PretenureSizeThreshold=64m  #对象超过多大是直接在老年代分配
-XX:-OmitStackTraceInFastThrow  #关闭 Fast Throw优化,注意是-号,不是+号
-XX:+PrintCommandLineFlags  ## PrintCommandLineFlags
-XX:MetaspaceSize=600m   ## 元空间大小 影响Full GC
-XX:MaxMetaspaceSize=600m  ## 最大元空间大小 影响Full GC
-XX:+HeapDumpOnOutOfMemoryError ##当JVM发生OOM时,自动生成DUMP文件
-XX:HeapDumpPath=/home/admin/java/test-project/logs/  ##dump日志地址
-Xlog:gc*,gc+ref=debug,gc+heap=debug,gc+age=trace:file=logs/gc.log:tags,uptime,time
 ,level:filecount=10,filesize=200m"  
 ## jvm1.9新特性 有点类似于将jvm不同事件不同日志级别想看的日志内容做了内容,日志级别和目录细分,可以通过相关参数去配置
复制代码

3.知识扩展:

  1. PretenureSizeThreshold\
    -XX:PretenureSizeThreshold的默认值和作用浅析
    讲到大对象主要指字符串和数组,虚拟机提供了一个-XX:PretenureSizeThreshold参数,大于这个值的参数直接在老年代分配。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存复制(新生代采用复制算法)。 说白了就是设置多大的大对象,直接进入老年代,避免年轻代过多的minor gc(来回复制)
    找到了一篇相关问题的文章《Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine》

第29条:Do objects ever get allocated directly into the old generation? In 1.4.1 there two situations where allocation may occur directly into the old generation. 有两种情况,对象会直接分配到老年代。 If an allocation fails in the young generation and the object is a large array that does not contain any references to objects, it can be allocated directly into the old generation. In some select instances, this strategy was intended to avoid a collection of the young generation by allocating from the old generation. 如果在新生代分配失败且对象是一个不含任何对象引用的大数组,可被直接分配到老年代。 通过在老年代的分配避免新生代的一次垃圾回收。 There is a flag (available in 1.4.2 and later) l-XX:PretenureSizeThreshold= that can be set to limit the size of allocations in the young generation. Any allocation larger than this will not be attempted in the young generation and so will be allocated out of the old generation. XX:PretenureSizeThreshold=<字节大小>可以设分配到新生代对象的大小限制。 任何比这个大的对象都不会尝试在新生代分配,将在老年代分配内存。 The threshold size for 1) is 64k words. The default size for PretenureSizeThreshold is 0 which says that any size can be allocated in the young generation. PretenureSizeThreshold 默认值是0,意味着任何对象都会现在新生代分配内存。

  1. OmitStackTraceInFastThrow异常栈信息不见了之JVM参数
    jdk 1.6开始,默认server模式下开启了这个参数,意为当jvm检测到程序在重复抛一个异常,在执行若干次后会将异常吞掉堆栈打印信息,即 Fast Throw

JVM只对几个特定类型异常开启了Fast Throw优化,这些异常包括:

  • NullPointerException
  • ArithmeticException
  • ArrayIndexOutOfBoundsException
  • ArrayStoreException
  • ClassCastException

相关解决问题:项目日志只打印 java.lang.NullPointerException信息,没有打印相关堆栈信息

经过一番代码调试,确定并非程序代码问题。没有线索之后,从Google找到了答案:是因为在server模式下运行的时候,有一个默认选项是-XX:+OmitStackTraceInFastThrow,这个玩意的意思就是当大量抛出同样的异常的后,后面的异常输出将不打印堆栈,打印堆栈的时候底层会调用到Throwable.getOurStackTrace()方法,而这个方法是synchronized的,对性能有比较明显对影响。所以这个参数是合理的。正常情况下,如果打印了几万条异常堆栈是很容易发现问题的。但是我们的系统正好赶上访问量高峰,一不留神就错过打印详细堆栈的阶段了。 说明:JVM默认开启了Fast Throw优化。如果想关闭这个优化,很简单,配置-XX:-OmitStackTraceInFastThrow, 恢复开启Fast Throw设置 -XX:+OmitStackTraceInFastThrow`即可。

  1. PrintCommandLineFlags  :JVM调优:-XX:+PrintCommandLineFlags 查看程序使用的默认JVM参数.
  2. MetaspaceSize和MaxMetaspaceSize :元空间大小,基于本地内存大小,jdk1.8引入. MetaspaceSize容量触发FGC的阈值。比如-XX:MetaspaceSize=256m,当MetaspaceSize容量超过256M时触发FGC,超过设定阈值后MetaspaceSize每扩容一次触发一次FGC。需要和永久代区分.
    建议
    MetaspaceSizeMaxMetaspaceSize设置一样大; 具体设置多大,建议稳定运行一段时间后通过jstat -gc pid确认且这个值大一些,对于大部分项目256m即可.
    JDK7的PermSize(永久代)
    JDK8+移除了Perm,引入了Metapsace,它们两者的区别是什么呢?Metaspace上面已经总结了,无论-XX:MetaspaceSize-XX:MaxMetaspaceSize两个参数如何设置,随着类加载越来越多不断扩容调整,直到MetaspaceSize(如果没有配置就是默认20.8m)触发FGC,上限是-XX:MaxMetaspaceSize默认是几乎无穷大(基于本地内存大小)。而Perm的话,我们通过配置-XX:PermSize以及-XX:MaxPermSize来控制这块内存的大小,jvm在启动的时候会根据-XX:PermSize初始化分配一块连续的内存块,这样的话,如果-XX:PermSize设置过大,就是一种浪费。很明显,Metapspace比Perm可控;后续可以细讲 ,待定.....
  3. HeapDumpOnOutOfMemoryError和HeapDumpPath :-XX:+HeapDumpOnOutOfMemoryError参数表示当JVM发生OOM时,自动生成DUMP文件,后续可以细讲如何查看dump日志 ,待定.....
    JVM参数-XX:+HeapDumpOnOutOfMemoryError使用方法
    -XX:HeapDumpPath=${目录}参数表示生成DUMP文件的路径,也可以指定文件名称,例如:-XX:HeapDumpPath=${目录}/java_heapdump.hprof。如果不指定文件名,默认为:java_<pid>_<date>_<time>_heapDump.hprof。
  4. xlog :    
    JDK9的新特性:JVM的xlog
    JDK9的新特性:JVM的xlog-阿里云开发者社区 (aliyun.com)
    在java程序中,我们通过日志来定位和发现项目中可能出现的问题。在现代java项目中,我们使用log4j或者slf4j,Logback等日志记录框架来处理日志问题。JVM是java程序运行的基础,JVM中各种事件比如:GC,class loading,JPMS,heap,thread等等其实都可以有日志来记录。通过这些日志,我们可以监控JVM中的事件,并可以依次来对java应用程序进行调优。 在JDK9中引入的Xlog日志服务就是为这个目的而创建的。通过xlog,JDK将JVM中的各种事件统一起来,以统一的形式对外输出。通过tag参数来区分子系统,通过log level来区分事件的紧急性,通过logging output来配置输出的地址。使用java -Xlog:help命令我们看一下xlog的基本格式:
-Xlog Usage: -Xlog[:[selections][:[output][:[decorators][:output-options]]]]
     where 'selections' are combinations of tags and levels of the form tag1[+tag2...][*][=level][,...]
     NOTE: Unless wildcard (*) is specified, only log messages tagged with exactly the tags specified will be matched.
# 1.selections
## selections表示的是到底需要输出哪些信息。是以tag=level来表示的。
## 1.1 tag表示的是JVM中的事件或者子系统 
> 相关参数 Available log tags:
>  add, age, alloc, annotation, aot, arguments, attach, barrier, biasedlocking, blocks, bot, breakpoint, bytecode, cds, census, class, classhisto, cleanup, codecache, compaction, compilation, constantpool, constraints, container, coops, cpu, cset, data, datacreation, dcmd, decoder, defaultmethods, director, dump, dynamic, ergo, event, exceptions, exit, fingerprint, free, freelist, gc, handshake, hashtables, heap, humongous, ihop, iklass, init, inlining, install, interpreter, itables, jfr, jit, jni, jvmti, liveness, load, loader, logging, malloc, mark, marking, membername, memops, metadata, metaspace, methodcomparator, mirror, mmu, module, monitorinflation, monitormismatch, nestmates, nmethod, normalize, numa, objecttagging, obsolete, oldobject, oom, oopmap, oops, oopstorage, os, pagesize, parser, patch, path, perf, periodic, phases, plab, preorder, preview, promotion, protectiondomain, ptrqueue, purge, record, redefine, ref, refine, region, reloc, remset, resolve, safepoint, sampling, scavenge, setting, smr, stackmap, stacktrace, stackwalk, start, startuptime, state, stats, streaming, stringdedup, stringtable, subclass, survivor, sweep, symboltable, system, table, task, thread, time, timer, tlab, tracking, unload, unshareable, update, verification, verify, vmmutex, vmoperation, vmthread, vtables, vtablestubs, workgang
>  Specifying 'all' instead of a tag combination matches all tag combinations
## 1.2 levels表示的是日志的级别  
> 相关参数 Available log levels:
> off, trace, debug, info, warning, error
## 1.3 例如
java -Xlog:os,class=info -version   
[admin@127.0.0.1]$ java -Xlog:os,class=info -version   
[0.001s][info][os] Use of CLOCK_MONOTONIC is supported
[0.001s][info][os] Use of pthread_condattr_setclock is supported
[0.001s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
[0.001s][info][os] HotSpot is running with glibc 2.28, NPTL 2.28
[0.001s][info][os] SafePoint Polling address, bad (protected) page:0x00007f0a8558e000, good (unprotected) page:0x00007f0a8558f000
[0.001s][info][os] attempting shared library load of /usr/lib/jvm/java-11-openjdk-11.0.12.0.7-0.el8_4.x86_64/lib/libzip.so
[0.002s][info][os] shared library load of /usr/lib/jvm/java-11-openjdk-11.0.12.0.7-0.el8_4.x86_64/lib/libzip.so was successful
openjdk version "11.0.12" 2021-07-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.12+7-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7-LTS, mixed mode, sharing)
# 2. output    
## 2.1 output表示将日志输出到什么地方。    
## 2.2 output的可选项:
  stdout/stderr
  file=<filename>
## stdout表示标准输出,stderr表示标准错误。file表示输出到文件里面。
## 2.3 例如
java -Xlog:all=debug:file=test-protect-ttt.log -version    
[admin@127.0.0.1]$ java -Xlog:all=debug:file=test-protect-ttt.log -version
openjdk version "11.0.12" 2021-07-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.12+7-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7-LTS, mixed mode, sharing) 
[admin@127.0.0.1]$ ll -h test-protect-ttt.log 
-rw-rw-r-- 1 admin admin 602K Aug 27 22:44 test-protect-ttt.log
[admin@127.0.0.1]$ more test-protect-ttt.log     
more test-protect-ttt.log 
[0.001s][debug][os] Initial active processor count set to 8
[0.001s][debug][os,container] container memory limit unlimited: -1, using host value
[0.001s][debug][os,container] container memory limit unlimited: -1, using host value
[0.001s][debug][ergo        ] ThreadLocalHandshakes enabled.
[0.001s][info ][os          ] Use of CLOCK_MONOTONIC is supported
[0.001s][info ][os          ] Use of pthread_condattr_setclock is supported
[0.001s][info ][os          ] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
[0.001s][info ][os          ] HotSpot is running with glibc 2.28, NPTL 2.28
[0.001s][info ][os          ] SafePoint Polling address, bad (protected) page:0x00007fbd7c527000, good (unprotected) page:0x00007fbd7c528000
[0.001s][debug][perf,memops ] PerfDataMemorySize = 32768, os::vm_allocation_granularity = 4096, adjusted size = 32768
[0.001s][debug][perf,memops ] PerfMemory created: address = 0x00007fbd7c418000, size = 32768
[0.001s][info ][biasedlocking] Aligned thread 0x00007fbd740186a0 to 0x00007fbd74018800
[0.001s][info ][os,thread    ] Thread attached (tid: 2284746, pthread id: 140451811297024).  ### 内容较多忽略.....................
# 3. decorators   
## 3.1 decorators表示输出哪些内容到日志中。    
> 相关参数:time (t), utctime (utc), uptime (u), timemillis (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), pid (p), tid (ti), level (l), tags (tg)
>  Decorators can also be specified as 'none' for no decoration
## 3.2 例如
java -Xlog:gc*=debug:stdout:time,uptimemillis,tid -version
[admin@127.0.0.1]$ java -Xlog:gc*=debug:stdout:time,uptimemillis,tid -version
[2022-08-27T22:47:37.731+0800][2ms][2285793] Heap region size: 1M
[2022-08-27T22:47:37.731+0800][2ms][2285793] Minimum heap 8388608  Initial heap 251658240  Maximum heap 4013948928
[2022-08-27T22:47:37.732+0800][3ms][2285793] ConcGCThreads: 2 offset 16
[2022-08-27T22:47:37.732+0800][3ms][2285793] ParallelGCThreads: 8
[2022-08-27T22:47:37.732+0800][3ms][2285793] Initialize mark stack with 4096 chunks, maximum 16384
[2022-08-27T22:47:37.732+0800][3ms][2285793] Expand the heap. requested expansion amount: 251658240B expansion amount: 251658240B
[2022-08-27T22:47:37.735+0800][6ms][2285793] Target occupancy update: old: 0B, new: 251658240B
[2022-08-27T22:47:37.735+0800][6ms][2285793] Initial Refinement Zones: green: 8, yellow: 24, red: 40, min yellow size: 16
[2022-08-27T22:47:37.735+0800][6ms][2285793] Using G1
[2022-08-27T22:47:37.735+0800][6ms][2285793] Heap address: 0x0000000710c00000, size: 3828 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
[2022-08-27T22:47:37.735+0800][6ms][2285793] Attempt heap expansion (allocate archive regions). Total size: 1048576B
[2022-08-27T22:47:37.735+0800][6ms][2285793] Mark closed archive regions in map: [0x00000007bff00000, 0x00000007bff6aff8]
[2022-08-27T22:47:37.735+0800][6ms][2285793] Attempt heap expansion (allocate archive regions). Total size: 1048576B
[2022-08-27T22:47:37.735+0800][6ms][2285793] Mark open archive regions in map: [0x00000007bfe00000, 0x00000007bfe47ff8]
openjdk version "11.0.12" 2021-07-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.12+7-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7-LTS, mixed mode, sharing)
[2022-08-27T22:47:37.758+0800][29ms][2285797] Stopping 0
[2022-08-27T22:47:37.758+0800][29ms][2285793] Heap
[2022-08-27T22:47:37.758+0800][29ms][2285793]  garbage-first heap   total 247808K, used 1740K [0x0000000710c00000, 0x0000000800000000)
[2022-08-27T22:47:37.758+0800][29ms][2285793]   region size 1024K, 2 young (2048K), 0 survivors (0K)
[2022-08-27T22:47:37.758+0800][29ms][2285793]  Metaspace       used 120K, capacity 4480K, committed 4480K, reserved 1056768K
[2022-08-27T22:47:37.759+0800][30ms][2285793]   class space    used 2K, capacity 384K, committed 384K, reserved 1048576K
复制代码

今天先实战配置一下jvm参数,明天看看具体日志输出怎么解析(后续还有待定的两个任务:一个是分析一下永久代和元空间,还有一个是如何查看dump日志)


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
10天前
|
SQL 缓存 监控
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
本文详细解析了数据库、缓存、异步处理和Web性能优化四大策略,系统性能优化必知必备,大厂面试高频。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
|
10天前
|
Arthas 监控 Java
JVM进阶调优系列(9)大厂面试官:内存溢出几种?能否现场演示一下?| 面试就那点事
本文介绍了JVM内存溢出(OOM)的四种类型:堆内存、栈内存、元数据区和直接内存溢出。每种类型通过示例代码演示了如何触发OOM,并分析了其原因。文章还提供了如何使用JVM命令工具(如jmap、jhat、GCeasy、Arthas等)分析和定位内存溢出问题的方法。最后,强调了合理设置JVM参数和及时回收内存的重要性。
|
1月前
|
存储 监控 算法
美团面试:说说 G1垃圾回收 底层原理?说说你 JVM 调优的过程 ?
尼恩提示: G1垃圾回收 原理非常重要, 是面试的重点, 大家一定要好好掌握
美团面试:说说 G1垃圾回收 底层原理?说说你 JVM 调优的过程  ?
|
1月前
|
监控 架构师 Java
JVM进阶调优系列(6)一文详解JVM参数与大厂实战调优模板推荐
本文详述了JVM参数的分类及使用方法,包括标准参数、非标准参数和不稳定参数的定义及其应用场景。特别介绍了JVM调优中的关键参数,如堆内存、垃圾回收器和GC日志等配置,并提供了大厂生产环境中常用的调优模板,帮助开发者优化Java应用程序的性能。
|
1月前
|
Java 应用服务中间件 程序员
JVM知识体系学习八:OOM的案例(承接上篇博文,可以作为面试中的案例)
这篇文章通过多个案例深入探讨了Java虚拟机(JVM)中的内存溢出问题,涵盖了堆内存、方法区、直接内存和栈内存溢出的原因、诊断方法和解决方案,并讨论了不同JDK版本垃圾回收器的变化。
30 4
|
1月前
|
存储 监控 算法
JVM调优深度剖析:内存模型、垃圾收集、工具与实战
【10月更文挑战第9天】在Java开发领域,Java虚拟机(JVM)的性能调优是构建高性能、高并发系统不可或缺的一部分。作为一名资深架构师,深入理解JVM的内存模型、垃圾收集机制、调优工具及其实现原理,对于提升系统的整体性能和稳定性至关重要。本文将深入探讨这些内容,并提供针对单机几十万并发系统的JVM调优策略和Java代码示例。
51 2
|
1月前
|
Arthas 监控 Java
JVM知识体系学习七:了解JVM常用命令行参数、GC日志详解、调优三大方面(JVM规划和预调优、优化JVM环境、JVM运行出现的各种问题)、Arthas
这篇文章全面介绍了JVM的命令行参数、GC日志分析以及性能调优的各个方面,包括监控工具使用和实际案例分析。
45 3
|
1月前
|
Java Android开发 开发者
【编程进阶知识】精细调控:掌握Eclipse JVM参数配置的艺术
本文详细介绍了如何在Eclipse中配置JVM参数,包括内存的初始和最大值设置。通过具体步骤和截图演示,帮助开发者掌握JVM参数的精细调控,以适应不同的开发和测试需求。
43 1
|
1月前
|
存储 缓存 JavaScript
JVM面试真题总结(一)
JVM面试真题总结(一)
|
1月前
|
存储 Kubernetes 架构师
阿里面试:JVM 锁内存 是怎么变化的? JVM 锁的膨胀过程 ?
尼恩,一位经验丰富的40岁老架构师,通过其读者交流群分享了一系列关于JVM锁的深度解析,包括偏向锁、轻量级锁、自旋锁和重量级锁的概念、内存结构变化及锁膨胀流程。这些内容不仅帮助群内的小伙伴们顺利通过了多家一线互联网企业的面试,还整理成了《尼恩Java面试宝典》等技术资料,助力更多开发者提升技术水平,实现职业逆袭。尼恩强调,掌握这些核心知识点不仅能提高面试成功率,还能在实际工作中更好地应对高并发场景下的性能优化问题。

相关实验场景

更多
下一篇
无影云桌面