1.hotspot Դ?码分????
2.08.从源码揭秘偏向锁的升级
3.java是如何调用native方法？hotspot源码分析必会技能
4.不敢相信？System.currentTimeMillis()存在性能问题
5.字符串常量池，看这篇就够了（一）
hotspot Դ?码分????
我最近建立了一个在线自习室（App：番茄ToDO）用于相互监督学习，感兴趣的码分小伙伴可以加入。自习室加入码：D5A7A
Java并发包下的码分类大多基于AQS（AbstractQueuedSynchronizer）框架实现，而AQS线程安全的码分实现依赖于两个关键类：Unsafe和LockSupport。
其中，码分.net 简易网站源码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来解锁。
并且，java静态扫描源码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”，获得下载压缩包）
.从源码揭秘偏向锁的升级
深入探讨偏向锁的升级至轻量级锁的过程，主要涉及HotSpot虚拟机的源码分析。在学习synchronized机制时，将通过本篇文章解答关于synchronized功能的相关问题。首先，进行一些准备工作，了解在分析synchronized源码前的必要步骤。然后，通过示例代码的编译结果，揭示synchronized修饰代码块后生成的字节码指令，以及这些指令对应的操作。进一步地，使用jol工具跟踪对象状态，提供更直观的数据支持。
接下来，重点解析monitorenter指令的暴利产品竞价源码执行过程，包括其与templateTable_x和interp_masm_x方法之间的关联。通过分析注释中的参数设置，可以理解偏向锁升级为重量级锁的逻辑，以及epoch在偏向锁有效性判断中的作用。进一步，详细介绍对象头（markOop）的结构和其在偏向锁实现中的具体功能，包括epoch的含义及其在更新过程中的角色。
在理解了偏向锁的原理后，将分析其在不同条件下的执行流程，包括是否可偏向、是否重入偏向、是否依旧可偏向、epoch是否过期以及重新偏向等分支逻辑。接着，介绍偏向锁撤销和重偏向的过程，以及在获取偏向锁失败后的操作，即执行轻量级锁加锁的过程。最后，讨论偏向锁与轻量级锁的区别，总结它们的关键技术和性能特点，并简述偏向锁的争议与现状。
在偏向锁的实现中，关键点在于CAS操作的使用，以及在CAS竞争失败时导致的锁升级。偏向锁适用于单线程执行的场景，但在线程交替持有执行时，plc的底层源码撤销和重偏向逻辑的复杂性导致性能下降，因此引入轻量级锁以保证“轻微”竞争情况的安全性。尽管偏向锁在Java 中已被弃用，但在当前广泛应用的Java 8环境下，了解偏向锁的原理仍然具有重要意义。
总结而言，偏向锁与轻量级锁分别针对不同场景进行了优化，它们的核心逻辑基于CAS操作，但在处理线程竞争时的表现有所不同。通过深入学习这两种锁的升级过程，可以更好地理解synchronized机制在Java并发编程中的应用。
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方法。在尝试过程中可能会遇到各种问题，但通过一步步的调试和学习，我们可以逐步掌握这个过程。
不敢相信？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()。
值得注意的是，在不影响程序整体效率的情况下，无需进行这种优化，这仅针对极端情况而设。
字符串常量池，看这篇就够了（一）
研究事物，我们需要从两个角度出发：研究者角度与设计者角度。研究者角度，我们追求事物的本质与轨迹，深入理解设计者的意图。设计者角度，我们假想如何实现目标，分析各种选择的利弊，做出决策。今天，我们将从设计者的角度探讨字符串常量池在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中，字符串常量池的实现与性能优化是关键。了解这些原理，有助于在实际编程中做出更优决策。希望本文能够激发你对底层技术的兴趣，欢迎关注公众号道格子牙，与我一起探索更多底层知识。
