jhsdb: A New Tool for JDK 9这篇文章中列出了jhsdb与jcmd的等价命令,如下图:
JHSDB是一款基于服务性代理(Serviceability Agent,SA)实现的进程外调试工具。
上篇文章介绍了JVM运行时数据区的一些概念,这篇文章将通过工具和字节码加深对常用的堆和虚拟机栈部分的理解。
导语:在2020年发布的 JDK15 中,腾讯成为国内厂商历史首位 Notable 贡献者,全球贡献第五。
看了网上很多帖子,都说一半,说的都是大家说过的,根本没有解决问题。说jdk8不行,换成jdk9或者jdk11,我都试了,还是不行,最后说是mac的问题。换成linux,崩溃!!!
导语:在2020年发布的 JDK15 中,腾讯成为国内厂商历史首位 Notable 贡献者,全球贡献第五。 时光飞逝,一转眼,2020年已经结束,自2019年11月KonaJDK开源,也已超过一年。在过去的这一年里,KonaJDK不断提升,锐意进取,为腾讯内部及外部云上客户提供了稳定的Java运行环境。关于KonaJDK服务腾讯及云业务,我们已经在《KonaJDK 赋能云上 Java 新生态》一文中做了表述。与此同时,2020年我们也积极参与了OpenJDK开源社区贡献。2021新年伊始,我们以腾讯云JD
大多数情况下,对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时,虚拟机将发起一次Minor GC
Java真的是长盛不衰,拥有顽强的生命力。其中,字节码机制功不可没。字节码,就像是 Linux 的 ELF。有了它,JVM直接摇身一变,变成了类似操作系统的东西。
堆中具有垃圾回收机制,但是垃圾回收的前提是堆中的对象不再被引用(实际上,回收引用的算法是根可达算法,后面会讲述,这里的表述是不准确的),因此如果我们有过多无法被回收的对象,就可能导致内存溢出。
oopsHierarchy: 描述了对象的表示层次,描述了klass的表示层次,并为OOPS指针oopDesc* 定义了别名
我们在日常开发中,其实很少去关注字节码层面的东西。但,作为我们的吃饭家伙,个人觉得还是很有必要了解的。
本篇讨论Java对象和类在HotSpot VM内部的具体实现,探索虚拟机在底层是如何对这些Java语言的概念建模的。
现代机器大部分是 64 位的,JVM 也从 9 开始仅提供 64 位的虚拟机。在 JVM 中,一个对象指针,对应进程存储这个对象的虚拟内存的起始位置,也是 64 位大小:
HSDB全称是HotSpotDebugger, HotSpot虚拟机的调试工具,在使用的时候,需要程序处在暂停的状态,可以直接使用Idea的debug工具. 使用HSDB可以看到堆栈里面相关的内容,
使用知行之桥EDI系统时,由于业务数据量的增多,难免会遇到一些系统异常情况,为了保证企业生产环境的稳定运行,EDI系统自带了错误邮件通知功能。此功能保证了在EDI系统自动处理数据的过程中可以将异常信息及时告知用户,使用户收到邮件及时处理,保证数据的正常传输。
(1)命令jps:全称 java process Status Tool, Java版的ps命令,查看java进程及其相关的信息的pid则可以用这个命令,和linux的ps类似
JVM 的全称是 「Java Virtual Machine」,也就是我们耳熟能详的 Java 虚拟机。
大家都知道,在存储用户输入的密码时候,会使用一些hash算法对密码进行加工,比如sha-1、bcrypt。这些信息同样不允许在日志输出里出现,必须做脱敏处理。但是对于一个拥有系统权限的攻击者来说,这些防护依然是不够的。攻击者可能会直接从内存中获取明文数据,尤其对于Java来说,由于提供了jmap一类非常方便的工具,可以把整个堆内存的数据dump下来。比如,“我的世界”一类使用Java开发的游戏,会比其他语言的游戏更加容易破解一些,所以我们在JVM中,如果把密码存储为char数组,安全性会稍微高一些。
提问 谈谈你对 Java 最直观的印象是什么?是它宣传的 “Write once, run anywhere"? 谈谈你对 Java 平台的理解? Java 是解释执行,这句话正确吗? 正文 谈谈你对 Java 平台的理解? 一看到这个问题时很懵,对 Java 平台的理解?这是啥问题,面这么广,该说些啥。 一瞬间闪过脑袋的,无外乎:面向对象的高级编程语言?跨平台?三大特性?然后就没了~ 然后看了本讲的内容,浏览了评论区各大神的回答,才发现,自己的基础确实很薄弱。这个问题并没有固定的答案,但关键在于考核你对
JVM是面试中必问的部分,本文通过思维导图以面向面试的角度整理JVM中不可不知的知识。
这还没过多久,我就遇到了几个大 Bug。前段时间我刚上线的面试刷题网站(mianshiya.com)的 Bug 就不说了,这网站基本已经变成大家的靶场了。
最近在调研 JDK 17,并且试着将之前的一个小项目升级了一下,在测试环境跑了一段时间。最终,决定了,新项目要采用 JDK 17 了。
作为法医,不怕高度腐烂的尸体,也不怕错综复杂的案情。最怕的,是没留下任何东西。空无一物,任何高超的技术,丰富的经验,都无从下手。
gc永远会是Java程序员需要考虑的不稳定因素之一。对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数。
监视虚拟机各种运行状态信息;显示进程中的 类加载、内存、垃圾收集、即时编译 等; 如果没有GUI图形化界面的服务器,可以通过该命令查看运行状况,命令格式:
如果您更喜欢Oracle JDK,可以下载适用于Ubuntu的二进制文件,然后安装它。可以在Oracle网站上找到JDK下载链接。
首先明确:只有Hotspot才有永久代。BEA JRockit、IBMJ9等来说,是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现细节,不受《Java虚拟机规范》管束,并不要求统一
比较先进的垃圾回收器都支持并发标记,即在标记过程中,用户线程仍然能工作。但这样带来一个新的问题,如果用户线程修改了对象引用,那么就存在漏标问题。例如:
abs(int) ceil(double) floor(double) round(float)
Java开发人员肯定都知道JDK的bin目录中有java.exe、javac.exe这两个命令行工具,但并非所有程序员都了解过JDK的bin目录下其他各种小工具的作用。随着JDK版本的更迭,这些小工具的数量和功能也在不知不觉地增加与增强。除了编译和运行Java程序外,打包、部署、签名、调试、监控、运维等各种场景都可能会用到它们。
本篇文章是《Java内存故障?只是因为你不够帅!》 这篇文章的续篇。上篇侧重于理论,本篇侧重于实践。对于内存问题排查来说,搞理论的痛苦,搞实践的也痛苦,没有一片清净之地。
前文我们没有提到,如何限制元空间的大小,其实就是限制 commit 的内存大小。元空间的限制不只是受限于我们的参数配置,并且前面我们提到了,元空间的内存回收也比较特殊,元空间的内存基本都是每个类加载器的 ClassLoaderData 申请并管理的,在类加载器被 GC 回收后,ClassLoaderData 管理的这些元空间也会被回收掉。所以,GC 是可能触发一部分元空间被回收了。所以元空间在设计的时候,还有一个动态限制 _capacity_until_GC,即触发 GC 的元空间占用大小。当要分配的空间导致元空间整体占用超过这个限制的时候,尝试触发 GC。这个动态限制也会在每次 GC 的时候动态扩大或者缩小。动态扩大以及缩小
上一周我有幸观看了高级架构师李国讲师的直播,内容是关于 Java 内存问题排查和解决。
有些面试题是开放性的,有些是知识性的,注意区别。面试并没有标准答案,尤其是开放性题目,你需要整理成白话文,来尽量的展示自己。
前面提到了虚拟内存需要映射物理内存才能使用,这个映射关系被保存在内存中的页表(Page Table)。现代 CPU 架构中一般有 TLB (Translation Lookaside Buffer,翻译后备缓冲,也称为页表寄存器缓冲)存在,在里面保存了经常使用的页表映射项。TLB 的大小有限,一般 TLB 如果只能容纳小于 100 个页表映射项。 我们能让程序的虚拟内存对应的页表映射项都处于 TLB 中,那么能大大提升程序性能,这就要尽量减少页表映射项的个数:页表项个数 = 程序所需内存大小 / 页大小。我们要么缩小程序所需内存,要么增大页大小。我们一般会考虑增加页大小,这就大页分配的由来,JVM 对于堆内存分配也支持大页分配,用于优化大堆内存的分配。那么 Linux 环境中有哪些大页分配的方式呢?
我们前面介绍了元空间的组成元素,但是没有将他们完整的串联起来,我们这里举一个简单的例子,将之前的所有元素串联起来。
JVM 在执行 Java 应用程序时,将加载的 Java 类的许多细节记录在内存中,这些信息称为类元数据(Class MetaData)。这些元数据对于 Java 的很多灵活的语言以及虚拟机特性都是很重要的,比如动态类加载、JIT 实时编译、反射以及动态代理等等。不同的 JVM 加载类保存的内存信息是不一样的,它们通常在更低的内存占用与更快的执行速度之间进行权衡(类似于空间还是时间的权衡)。对于 OpenJDK Hotspot 使用的则是相对丰富的元数据模型来获得尽可能快的性能(时间优先,不影响速度的情况下尽量优化空间占用)。相比于 C,C++,Go 这些离线编译为可执行二进制文件的程序相比,像 JVM 这样的托管运行时动态解释执行或者编译执行的,则需要保留更多关于正在执行的代码的运行时信息。原因如下:
不同的 GC 情况下,初始化以及扩展的流程可能在某些细节不太一样,但是,大体的思路都是:
不同的 GC 堆大小动态伸缩有很大很大的差异(比如 ParallelGC 涉及 UseAdaptiveSizePolicy 启用的动态堆大小策略以及相关的 UsePSAdaptiveSurvivorSizePolicy、UseAdaptiveGenerationSizePolicyAtMinorCollection 等等等等的参数参与决定计算最新堆大小的方式以及时机),在这个系列以后的章节我们详细分析每个 GC 的时候再详细分析这些不同 GC 的动态伸缩策略。我们这里仅涉及大多数 GC 通用的堆大小伸缩涉及的参数:MinHeapFreeRatio 与 MaxHeapFreeRatio:
我们过一下元空间内存分配流程,我们会忽略一些 GC 相关的还有并发安全的细节,否则涉及的概念太多,一下说不过来,这些细节,会在以后的系列中详细提到。
Linux 内存管理模型不是咱们这个系列的讨论重点,我们这里只会简单提一些对于咱们这个系列需要了解到的,如果读者想要深入理解,建议大家查看 bin 神(公众号:bin 的技术小屋)的系列文章:一步一图带你深入理解 Linux 虚拟内存管理
JVM 内存究竟包括哪些,可能网上众说纷纭。我们这里由官方提供的一个查看 JVM 内存占用的工具引入,即 Native Memory Tracking。不过要注意的一点是,这个只能监控 JVM 原生申请的内存大小,如果是通过 JDK 封装的系统 API 申请的内存,是统计不到的,例如 Java JDK 中的 DirectBuffer 以及 MappedByteBuffer 这两个(当然,对于这两个,我们后面也有其他的办法去看到当前使用的大小。当然xigao dog 啥都不会)。以及如果你自己封装 JNI 调用系统调用去申请内存,都是 Native Memory Tracking 无法涵盖的。这点要注意。
史上最全Java初中级面试题,发现网上很多Java初级面试题都没有答案,所以花了很长时间搜集整理出来了这套Java面试题大全,希望对大家有帮助哈~
从 Java 16 开始,引入了弹性元空间。老的元空间由于设计上分配粒度比较大,并且没有很好地释放空间的策略设计,所以占用可能比较大。Java 16 开始,JEP 387: Elastic Metaspace 引入了弹性元空间的设计,也是我们这里要讨论的设计。这个弹性元空间也引入了一个重要的参数 -XX:MetaspaceReclaimPolicy。
通过 jcmd <pid> VM.metaspace 命令可以查看对应 JVM 进程的元空间当前的详细使用情况,返回内容是:
因为我的是mac电脑,所以运行程序都是在mac上,有时一些工具在mac上不是很好用。如果有不好用的情况,可以参考文章:
Java 19 中 Loom 终于 Preview 了,虚拟线程(VirtualThread)是我期待已久的特性,但是这里我们说的线程内存,并不是这种 虚拟线程,还是老的线程。其实新的虚拟线程,在线程内存结构上并没有啥变化,只是存储位置的变化,实际的负载线程(CarrierThread)还是老的线程。
ThreadLocal:如何保证多个线程在并发环境下的安全性?典型应用就是数据库连接管理,以及独立会话管理
JVM:全称 Java Virtual Machine,一个虚拟计算机,Java 程序的运行环境(Java二进制字节码的运行环境)
领取专属 10元无门槛券
手把手带您无忧上云