1.JVM之创建对象源码分析
2.字符串常量池,码下看这篇就够了(一)
3.不敢相信?System.currentTimeMillis()存在性能问题
4.hotspotjvm的码下启动过程做了什么?
5.JVM详解之:HotSpot VM中的Intrinsic methods
6.从HotSpot源码,深度解读 park 和 unpark
JVM之创建对象源码分析
欢迎探索我的码下技术分享:《半栈工程师》 对于Java对象的创建,我过去只是码下停留在理论层面,但最近研究HotSpot虚拟机时,码下我深入剖析了JVM创建Java对象的码下maxcms源码底层机制。Java对象创建流程详解
首先,码下我们从一个简单的码下实例开始,看看如何通过代码创建一个Dog对象: 代码中new Dog()在编译成字节码后,码下会变成new #2,码下这里的码下new是实例化对象的关键字,#2则指向常量池中的码下Dog类索引。常量池是码下类编译后的存储区域,包含了各种符号引用和常量。码下new指令源码剖析
接下来,码下我们将深入new指令的源码。虽然涉及汇编代码,但无需立即深入,先了解一下《JVM之模板解释器》会有所帮助。新指令的运行过程如下:从指令中获取类在常量池的索引,存入rdx寄存器,并记录当前指令地址。
获取常量池地址和元素类型数组_tags,用于后续类型检查。
检查元素类型是否为JVM_CONSTANT_Class,如果不是,进入慢速分配。
获取并入栈类的运行时数据结构InstanceKlass,即类的内存地址。
判断类是否已解析,未解析则执行慢速分配,解析过的saas电商源码进入快速分配。
计算类实例大小并分配内存,首先尝试TLAB区,失败则在Eden区分配。
初始化对象实例数据和对象头。
如果类未解析,执行慢速分配过程。
总结
至此,我们了解了Java对象从创建到初始化的全过程。虽然使用了模板解释器,但理解字节码解释器中的相关方法也是个不错的选择。如果你对HotSpot源码感兴趣,欢迎加入讨论,我的****是wechat:wang_atbeijing。字符串常量池,看这篇就够了(一)
研究事物,我们需要从两个角度出发:研究者角度与设计者角度。研究者角度,我们追求事物的本质与轨迹,深入理解设计者的意图。设计者角度,我们假想如何实现目标,分析各种选择的利弊,做出决策。今天,我们将从设计者的角度探讨字符串常量池在Java世界中的作用。
字符串常量池的探究,核心问题在于:如果我们创建一个JVM,如何处理字符串?答案简洁明了,采用散列表,即hashtable结构。Java世界存在两种hashtable类型:Java的网站公告页源码HashTable与Hotspot的hashtable。Hotspot源码中的hashtable是C++实现的。
很多人对C++感到恐惧,但无需担忧,本文将提供清晰的动画,帮助你理解核心概念。阅读源码的小伙伴,可以期待下篇深度解析。
hashtable的基本实现有两种:数组+单链表与数组+红黑树。后者在大量数据时表现更佳。我们先从数组+单链表开始探讨。
当字符串"ziya"进入系统,它首先通过哈希算法确定在数组中的位置。假设哈希结果为2,这表示"ziya"将被存储在数组的第2个位置。然后,"ziya"被封装为链表节点,成为该位置的链表头。
数组长度通常设置为,这个数字可能有特殊意义,期待深入研究的读者留言分享。如果超过这个数量,哈希碰撞(相同字符串得到相同索引)将不可避免。
当碰撞发生,新字符串将作为链表节点,插入到已有节点之后。当链表深度过大,性能下降,我们引入数组+红黑树结构,以提升查找效率。当数据量小,如HashMap,网狐比赛源码链表结构可能更优。
字符串常量池主要涉及两个表:SymbolTable与StringTable。通常讨论的字符串常量池指的是StringTable,它与SymbolTable紧密相连,本文将深入探讨SymbolTable的底层原理。
SymbolTable基于散列表实现,使用数组+链表结构,遇到哈希碰撞严重时,通过改变哈希算法解决。默认算法为java_lang_String::hash_code,触发重哈希后使用AltHashing::murmur3_。
在JVM中,字符串常量池的实现与性能优化是关键。了解这些原理,有助于在实际编程中做出更优决策。希望本文能够激发你对底层技术的兴趣,欢迎关注公众号道格子牙,与我一起探索更多底层知识。
不敢相信?System.currentTimeMillis()存在性能问题
System.currentTimeMillis(),一个看似高效的基础Java API,实则在并发场景下暴露出性能问题。让我们深入了解其性能瓶颈所在。
在频繁或并发调用中,执行结果表明性能表现极不理想。例如,同时执行一百次System.currentTimeMillis()操作,耗时竟是单线程下一百次的倍!即使调用频次增加,问题依然存在,甚至可能超过创建简单对象实例所需的时间。
探究原因,嗨玩测试源码需深入到HotSpot源码的hotspot/src/os/linux/vm/os_linux.cpp文件中,找到javaTimeMillis()方法,这是System.currentTimeMillis()的native实现。然而,对于其性能表现的底层解释,已有国外专家深入到汇编级别进行分析,详情见《The Slow currentTimeMillis()》。简而言之,HPET计时器性能不佳在于对时间戳请求的串行处理,而TSC计时器则得益于专用寄存器,但其稳定性较低。
解决此问题的一种常见方法是采用单个调度线程按毫秒更新时间戳,创建全局缓存,以避免时钟资源争用,但牺牲了一定的精确度。实现步骤如下:使用CurrentTimeMillisClock.getInstance().now()。
值得注意的是,在不影响程序整体效率的情况下,无需进行这种优化,这仅针对极端情况而设。
hotspotjvm的启动过程做了什么?
HotSpot JVM启动过程涉及启动器和自身两大部分。
启动器主要负责加载Java类文件,将类文件转换为本地可执行代码,并初始化环境变量和设置。
HotSpot JVM的初始化过程则包括内存分配、类加载、方法区初始化、线程创建等步骤。
启动器通过执行Java解释器或Java虚拟机启动命令来启动HotSpot JVM,典型的启动器包括JRE/JDK自带的java[.exe]和javaw.exe。
Native应用程序也可自定义启动器实现Java启动。
《Java Performance》一书提供了高阶描述,适合深入理解HotSpot JVM启动机制。
《Java Performance》笔记第页可作为参考。
HotSpot JVM初始化大入口为Threads::create_vm函数,该函数接收JavaVMInitArgs参数,并进行VM初始化。
为了详细了解HotSpot JVM启动过程,建议阅读官方文档和相关书籍,同时也可参考JDK自带的Java launcher源代码。
JVM详解之:HotSpot VM中的Intrinsic methods
内置方法是编译器内置的方法实现,它们在给定编程语言中使用,由编译器专门处理。内置方法通常在程序请求优化时才启用,以提高效率。因为内置方法是在编译器内部实现的,所以不同的虚拟机,其内置方法是不一样的。内置方法可以在Java源代码级别看起来与非内置方法一样,但它们的区别在于JVM的实现。有些方法在普通Java代码中无法实现,如sun.misc.Unsafe.compareAndSwapInt(),只能通过JNI或内置方法来实现,实现对Java语义的扩展。在Hotspot VM中,内置方法通常在src/share/vm/classfile/vmSymbols.hpp类中。通过参数查看代码中调用的方法是否为内置方法,或者通过底层汇编语言查看。内置方法大部分都是内联方法,通过减少函数调用开销的技术实现。内置方法的实现由三种编译器完成:javac将Java源代码编译成为字节码,在这一层只有数学方法和bootstrapping的MethodHandle实现;JIT的Client Compiler (C1);JIT的Server Compiler (C2)。例如,java.lang.System.currentTimeMillis()方法在Interpreter级别没有intrinsified,因为它是一个native方法,通过JNI调用底层的C++实现。而在C1和C2级别使用intrinsified,直接调用os::javaTimeMillis(),减少JNI的使用,提升效率。内置方法的实现可以通过修改底层的JVM实现完成。Graal是一个用Java编写的JIT编译器,可以使用Java来实现Intrinsic方法,对于不熟悉C++的开发者来说非常友好。通过Graal,内置方法的实现变得简单且容易操作。内置方法是JVM中非常有用的特性,能够显著提高程序效率,是编程时值得考虑的技术之一。
从HotSpot源码,深度解读 park 和 unpark
我最近建立了一个在线自习室(App:番茄ToDO)用于相互监督学习,感兴趣的小伙伴可以加入。自习室加入码:D5A7A
Java并发包下的类大多基于AQS(AbstractQueuedSynchronizer)框架实现,而AQS线程安全的实现依赖于两个关键类:Unsafe和LockSupport。
其中,Unsafe主要提供CAS操作(关于CAS,在文章《读懂AtomicInteger源码(多线程专题)》中讲解过),LockSupport主要提供park/unpark操作。实际上,park/unpark操作的最终调用还是基于Unsafe类,因此Unsafe类才是核心。
Unsafe类的实现是由native关键字说明的,这意味着这个方法是原生函数,是用C/C++语言实现的,并被编译成了DLL,由Java去调用。
park函数的作用是将当前调用线程阻塞,而unpark函数则是唤醒指定线程。
park是等待一个许可,unpark是为某线程提供一个许可。如果线程A调用park,除非另一个线程调用unpark(A)给A一个许可,否则线程A将阻塞在park操作上。每次调用一次park,需要有一个unpark来解锁。
并且,unpark可以先于park调用,但不管unpark先调用多少次,都只提供一个许可,不可叠加。只需要一次park来消费掉unpark带来的许可,再次调用会阻塞。
在Linux系统下,park和unpark是通过Posix线程库pthread中的mutex(互斥量)和condition(条件变量)来实现的。
简单来说,mutex和condition保护了一个叫_counter的信号量。当park时,这个变量被设置为0,当unpark时,这个变量被设置为1。当_counter=0时线程阻塞,当_counter>0时直接设为0并返回。
每个Java线程都有一个Parker实例,Parker类的部分源码如下:
由源码可知,Parker类继承于PlatformParker,实际上是用Posix的mutex和condition来实现的。Parker类里的_counter字段,就是用来记录park和unpark是否需要阻塞的标识。
具体的执行逻辑已经用注释标记在代码中,简要来说,就是检查_counter是不是大于0,如果是,则把_counter设置为0,返回。如果等于零,继续执行,阻塞等待。
unpark直接设置_counter为1,再unlock mutex返回。如果_counter之前的值是0,则还要调用pthread_cond_signal唤醒在park中等待的线程。源码如下:
(如果不会下载JVM源码可以后台回复“jdk”,获得下载压缩包)
java是如何调用native方法?hotspot源码分析必会技能
在深入研究JDK源码,如并发包和Thread相关部分时,往往会遇到native修饰的方法,它们隐藏在层层方法的底层。native方法的存在并非偶然,它是解决Java语言与操作系统直接交互的关键。Java作为高层语言,需要JVM作为桥梁,将Java指令转换为可以直接操作系统的C或C++代码,这就是native方法的用武之地。
JDK、JRE和JVM的关系是这样的:JDK包含JRE,其中的JVM负责执行Java代码并进行操作系统间的转换。在OpenJDK源码中,特别是hotspot实现的JVM中,能找到native方法的具体实现。JNI(Java Native Interface)技术用于模拟Java调用C或C++编写的native方法,确保跨平台的兼容性。
让我们通过实践来理解这个过程。首先,创建一个简单的Java类,通过javac编译,生成JavaCallC.class文件。然后使用javah命令生成JavaCallC.h头文件,这是C语言调用Java的关键部分,需要与Java代码中的native方法签名匹配。接着,编写C代码(Cclass.c),编译成动态链接库libJavaCallC.so,并将库文件路径添加到LD_LIBRARY_PATH环境变量中。
最后,执行JavaCallC命令,如果一切顺利,会看到"Java_JavaCallC_cMethod call succ"的输出,表明Java成功调用了native方法。在尝试过程中可能会遇到各种问题,但通过一步步的调试和学习,我们可以逐步掌握这个过程。
2024-12-27 14:42
2024-12-27 14:20
2024-12-27 14:19
2024-12-27 13:51
2024-12-27 13:39
2024-12-27 13:02
2024-12-27 12:53
2024-12-27 12:46