JVM - 一个案例反推不同JDK版本的intern机制以及intern C++源码解析

简介: JVM - 一个案例反推不同JDK版本的intern机制以及intern C++源码解析
+关注继续查看

20200712003202517.png

Pre

JVM - 深入剖析字符串常量池


案例

      String str2 = new StringBuilder("计算机").append("技术").toString();
      System.out.println(str2 == str2.intern()); 

      String s2 = new StringBuilder("计算机技术").toString();
      System.out.println(s2 == s2.intern());  



读者可以先自行推演一下答案 ,是不是所有的JDK版本都是一样的? 还是说不同的JDK版本的答案不尽相同 ?


答案

        String str2 = new StringBuilder("计算机").append("技术").toString();
        System.out.println(str2 == str2.intern());  //1.8 true  1.6 false

        String s2 = new StringBuilder("计算机技术").toString();
        System.out.println(s2 == s2.intern());  //1.8 false    1.6 false 


【1.6 】

20200712170632176.png

【1.7 】


20200712170808392.png

【1.8】



20200712171037547.png


字符串常量池在不同JDK版本的位置变化


Jdk1.6及之前: JVM存在永久代, 运行时常量池在永久代,运行时常量池包含字符串常量池

Jdk1.7:有永久代,但已经逐步“去永久代”,字符串常量池从永久代里的运行时常量池分离到堆里

Jdk1.8及之后: 无永久代,变成了元空间,运行时常量池在元空间,字符串常量池里依然在堆里


String中的intern方法是一个 native 的方法


JDK1.7(含) + ,当调用 intern方法时,如果池已经包含一个等于此String对象的字符串(用equals(oject)方法确定),则返回池中的字符串, 否则,将intern返回的引用指向当前字符串 。


jdk1.6版本需要将 s1 复制到字符串常量池里


JDK1.7(含)+

20200712224255430.png

JDK1.6


20200712224244643.png

明白了哈


intern源码

intern 在JDK里是native ,所以只能找C++的代码了。

JDK8对应的哈


20200712235002244.png

20200712235124647.png


看看basic_add 返回的啥


20200712235213494.png


oop : ordinary object pointer 指针

2020071223530337.png


20200712235343990.png


加入到常量池,这个常量池StringTable , 也是个hash结构 ,最后返回string(), 这其实是个指针引用。

so ~ , 这样就好理解intern机制了吧 。

相关文章
|
6天前
|
监控 Oracle 数据可视化
深度解析JVM性能监控工具:推荐与详细用法
深度解析JVM性能监控工具:推荐与详细用法
48 0
|
6天前
|
缓存 Java 大数据
深入解析JVM调优:解决OutOfMemoryError、内存泄露、线程死锁、锁争用和高CPU消耗问题
深入解析JVM调优:解决OutOfMemoryError、内存泄露、线程死锁、锁争用和高CPU消耗问题
50 0
|
1月前
|
存储 缓存 安全
万字完整深入解析JVM面试必备,原来这就是和年薪百万的差距
工作之余,想总结一下JVM相关知识。话不多说直接进入主题
|
2月前
|
存储 算法 Java
JAVA虚拟机(JVM)-- 万字解析
JAVA虚拟机(JVM)-- 万字解析
108 1
|
3月前
|
存储 监控 Java
Java虚拟机之 XX:+UseGCLogFileRotation 解析
通常,在生产环境中,我们需要借助 GC Log 来实时检测我们的微服务基于 Java 虚拟机层面活动状态,涉及年轻代、年老代以及全局的垃圾回收 ,只有基于上述方案,我们才能够快速的定位、分析微服务在某一时刻、时间段所呈现的活动轨迹及事件,以便高效解决业务问题。此篇文章来自笔者早期博客,依据实际的项目场景进行总结整理的。因技术群里有朋友在问此方面领域的问题,故再次将其呈现出来。
46 0
|
3月前
|
前端开发 Java
Java虚拟机 CMS GC 调优解析
随着 JDK 版本的不断升级,其 GC 策略也随之不停革新,从早期的 1.4 到如今的 11(本文仅讨论在线上环境落地规模较大的版本),其对应的 GC 策略也随之由 Serial、Parallel、CMS 演进至当前的 G1 甚至即将落地的 ZGC 。每一次的调整无不是基于环境的适配性以及业务场景特性,无论如何,只要能够基于特定的操作系统内核、物理内存、JDK版本以及业务特性,达到收益最大化,采用何种实现策略都不为过。当然,还是建议大家以官方的推荐为准,基于自己的业务场景进行不断优化调整,这样才能保证万无一失,使得我们的业务能够健康发展。
47 0
|
3月前
|
存储 监控 算法
Java虚拟机 G1 GC 调优解析
在上篇文章中,我们解析了 Java 虚拟机体系生态中基于 CMS GC 策略的调优场景及基本案例,具体链接为:Java虚拟机 CMS GC 调优解析。本文则重点介绍另一款当前比较流行的 GC 策略 - G1。
88 0
|
3月前
|
算法 Java API
Java虚拟机System.gc()解析
对于Java语言来说是不用刻意手动去释放内存,同时,也尽可能不需要手动去干预Java虚拟机的GC行为。在本篇文章中,我们试图从多个方面去解析有关System.gc()API调用的最常见问题。希望对需要了解这块技术的朋友有所帮助。
52 0
|
3月前
|
监控 算法 Oracle
Java虚拟机三件套解析
Java虚拟机(JVM)生成3个关键工件,这些工件对于优化性能和解决生产问题很有用。这些工件是: 垃圾收集(GC)日志 线程转储(ThreadDump) 堆转储(HeapDump 在本文中,我将尝试简要解析下这3个关键工件,描述下在什么场景中使用它们,它们的外观如何,如何捕获它们,如何分析它们及其之间的差异。
65 0
|
3月前
|
Arthas Dubbo Oracle
Java虚拟机OOM解析
针对以Java主导的企业级应用开发,Java虚拟机是整个项目架构的灵魂所在。只有弄清楚其内存分配及垃圾回收机制才能够在项目建设活动过程中游刃而余,无论是基于当前流行的微服务体系(以Spring家族的 Spring Cloud或以Ali家族的Dubbo)or 即将(已经)流行的服务网格体系。
48 1
相关产品
云迁移中心
推荐文章
更多