皮皮网

【粒子系统源码】【wf改名网页源码】【富有金融app源码】jvm源码debug

时间:2024-12-24 21:52:55 来源:网店源码制作

1.Java问题解决录: 运行时抛出NoSuchMethodError / NoSuchFieldError异常
2.这究竟是为什么呢?都说JVM能实际使用的内存比-Xmx指定的少,头大
3.为什么JAVA要在CMD中运行
4.idea debug进入HashMap源码时传参不正确?
5.OpenJDK17-JVM 源码阅读 - ZGC - 并发标记 | 京东物流技术团队

jvm源码debug

Java问题解决录: 运行时抛出NoSuchMethodError / NoSuchFieldError异常

       现象描述

       在IDE中编译运行程序无异常,但在打包成可运行的jar包(如Spring Boot jar包)后,程序运行时会抛出NoSuchMethodError或NoSuchFieldError异常。

       问题定位步骤

       通过增加JVM参数如-verbose:class、-XX:+TraceClassLoading或-Xlog:class+load=debug来查看类的加载情况。使用Arthas工具的粒子系统源码jad命令可以查看已加载类的源码,从而查看类的加载路径、jar包版本号及使用的类加载器。

       问题分类

       问题可能源自三个主要方面:

       1. **重复类定义**:在同包中或不同jar包中定义了同名类,导致类加载器加载了错误的类。这类问题通常发生在第三方jar包与项目自身的jar包中。

       2. **依赖版本冲突**:maven的传递依赖特性可能导致多个版本的类被加载,最终生效的版本可能导致NoSuchMethodError或NoSuchFieldError异常。根据maven的广度优先遍历算法,高版本或低版本的类可能覆盖了其他版本的类。

       3. **反射机制错误**:使用反射时,如果类定义错误或传递参数错误,也可能导致运行时异常。目前尚无自动检测这类错误的wf改名网页源码工具。

       编译期发现方法

       对于使用maven的项目,可以配置额外的enforcer-rules(如Ban Duplicate Classes规则)来在编译期间强制发现重复类定义的问题。对于使用Android Studio(Gradle工具)的项目,这类编译错误提示较为常见。

       总结

       通过增加JVM参数、使用Arthas工具、分析maven依赖树和代码中的反射使用情况,可以有效地定位和解决NoSuchMethodError或NoSuchFieldError异常。确保类定义的唯一性、避免依赖版本冲突以及正确使用反射机制是预防此类异常的关键。

这究竟是为什么呢?都说JVM能实际使用的内存比-Xmx指定的少,头大

       这确实是个挺奇怪的问题,特别是当最常出现的几种解释理由都被排除后,看来JVM并没有耍一些明显的小花招:

       要弄清楚这个问题的第一步就是要明白这些工具的实现原理。通过标准APIs,我们可以用以下简单语句得到可使用的内存信息。

       而且确实,现有检测工具底层也是用这个语句来进行检测。要解决这个问题,首先我们需要一个可重复使用的富有金融app源码测试用例。因此,我写了下面这段代码:

       这段代码通过将new int[1__]置于一个循环中来不断分配内存给程序,然后监测JVM运行期的当前可用内存。当程序监测到可用内存大小发生变化时,通过打印出Runtime.getRuntime().maxMemory()返回值来得到当前可用内存尺寸,输出类似下面语句:

       实际情况也确实如预估的那样,尽管我已经给JVM预先指定分配了2G对内存,在不知道为什么在运行期有M内存不见了。你大可以把 Runtime.getRuntime().maxMemory()的返回值2,,K 除以来转换成MB,那样你将得到1,M,正好和M差M。

       在成功重现了这个问题之后,我尝试用使用不同的GC算法,果然检测结果也不尽相同。

       除了G1算法刚好完整使用了我预指定分配的2G之外,其余每种GC算法似乎都不同程度地丢失了一些内存。

       现在我们就该看看在JVM的源代码中有没有关于这个问题的解释了。我在CollectedHeap这个类的菜鸟极速app源码源代码中找到了如下的解释:

       我不得不说这个答案藏得有点深,但是只要你有足够的好奇心,还是不难发现的:有时候,有一块Survivor区是不被计算到可用内存中的。

       明白这一点之后问题就好解决了。打开并查看GC logging 信息之后我们发现,在Serial,Parallel以及CMS算法回收过程中丢失的那些内存,尺寸刚好等于JVM从2G堆内存中划分给Survivor区内存的尺寸。例如,在上面的ParallelGC算法运行时,GC logging信息如下:

       由上面的信息可以看出,Eden区被分配了,K,两个Survivor区都被分配到了,K,老年代(Old space)则被分配了1,,K。把Eden区、老年代以及一个Survivor区的尺寸求和,刚好等于2,,K,说明丢失的收钱返利源码那M(,K)确实就是剩下的那个Survivor区。

       总结而言,当JVM在运行时报告的可使用内存小于-Xmx指定的内存时,差值通常对应于一块Survivor区的大小。对于不同的GC算法,这个差值可能有所不同。

为什么JAVA要在CMD中运行

       cmd是windows上的命令行窗口,严格来说java不是在cmd中运行,而是在JVM(java Virtual Machine)中运行,windows电脑安装了JVM,配置好了系统变量,电脑就能顺利使用JVM来编译并运行java源代码,cmd命令行窗口只是java在JVM中运行的一个窗口而已,当然这个窗口也提供了相应的命令来控制编译或运行或debug一些java源代码。

       安装了IDE的话,就直接在IDE的控制台上运行了,省去了很多麻烦。java一般使用的IDE是eclipse。

idea debug进入HashMap源码时传参不正确?

       我测试了下面的代码:

       分别在这四个位置打了断点以监控程序的运行情况,debug后,进入第一次断点的位置为:

       与题主说的情况一致,而没有进入我的第一个断点进行输出,而后F9:

       发现还是在put文件,经多次F9之后,可以看出来,其实java的jvm在启动的时候,在底层也自行调用的put方法,将jvm所需要的一些动态库、jar包put到某个map之中,具体是哪个map看不出来。要等到jvm底层将所有东西准备好后,才进行main函数。

       jvm准备需要put多少次我就不数了,现在我先把put的断点取消,让程序debug到我的第一个断点处:

       这个时候将put方法打上断点,F9发现:

       奇怪的key值增加了,它将我的classes编译目录丢进去了,继续F9,和上一步差不多,再再次F9,终于来了:

       继续F9,终于到达了我的第二个断点:

       继续F9,这次没有put奇怪的东西了:

       继续:

       最后:

       然后程序退出:

       综上,jvm在启动的时候会在程序背后隐式地将一些配置啊什么的通过put方法放到某些地方,不用关心,你遇到的情况是正常的也是正确的

OpenJDK-JVM 源码阅读 - ZGC - 并发标记 | 京东物流技术团队

       ZGC简介:

       ZGC是Java垃圾回收器的前沿技术,支持低延迟、大容量堆、染色指针、读屏障等特性,自JDK起作为试验特性,JDK起支持Windows,JDK正式投入生产使用。在JDK中已实现分代收集,预计不久将发布,性能将更优秀。

       ZGC特征:

       1. 低延迟

       2. 大容量堆

       3. 染色指针

       4. 读屏障

       并发标记过程:

       ZGC并发标记主要分为三个阶段:初始标记、并发标记/重映射、重分配。本篇主要分析并发标记/重映射部分源代码。

       入口与并发标记:

       整个ZGC源码入口是ZDriver::gc函数,其中concurrent()是一个宏定义。并发标记函数是concurrent_mark。

       并发标记流程:

       从ZHeap::heap()进入mark函数,使用任务框架执行任务逻辑在ZMarkTask里,具体执行函数是work。工作逻辑循环从标记条带中取出数据,直到取完或时间到。此循环即为ZGC三色标记主循环。之后进入drain函数,从栈中取出指针进行标记,直到栈排空。标记过程包括从栈取数据,标记和递归标记。

       标记与迭代:

       标记过程涉及对象迭代遍历。标记流程中,ZGC通过map存储对象地址的finalizable和inc_live信息。map大小约为堆中对象对齐大小的二分之一。接着通过oop_iterate函数对对象中的指针进行迭代,使用ZMarkBarrierOopClosure作为读屏障,实现了指针自愈和防止漏标。

       读屏障细节:

       ZMarkBarrierOopClosure函数在标记非静态成员变量的指针时触发读屏障。慢路径处理和指针自愈是核心逻辑,慢路径标记指针,快速路径通过cas操作修复坏指针,并重新标记。

       重映射过程:

       读屏障触发标记后,对象被推入栈中,下次标记循环时取出。ZGC并发标记流程至此结束。

       问题回顾:

       本文解答了ZGC如何标记指针、三色标记过程、如何防止漏标、指针自愈和并发重映射过程的问题。

       扩展思考:

       ZGC在指针上标记,当回收某个region时,如何得知对象是否存活?答案需要结合标记阶段和重分配阶段的代码。

       结束语:

       本文深入分析了ZGC并发标记的源码细节,对您有启发或帮助的话,请多多点赞支持。作者:京东物流 刘家存,来源:京东云开发者社区 自猿其说 Tech。转载请注明来源。

推荐资讯
台中母帶2歲女兒從12樓頂樓墜落 原因待釐清

台中母帶2歲女兒從12樓頂樓墜落 原因待釐清

goturn源码

goturn源码

源码android

源码android

rp源码

rp源码

逆轉裁定收押理由曝光 鄭文燦出庭前將「答辯方向」LINE給秘書

逆轉裁定收押理由曝光 鄭文燦出庭前將「答辯方向」LINE給秘書

log 源码

log 源码

copyright © 2016 powered by 皮皮网   sitemap