jvm
文章平均质量分 93
AI乔治
十年码农,站在巨人的肩膀上敲代码!
展开
-
这也许是写的最全最透彻最深入的JVM解析了
Java运行时数据区: Java虚拟机在执行Java程序的过程中会将其管理的内存划分为若干个不同的数据区域,这些区域有各自的用途、创建和销毁的时间,有些区域随虚拟机进程的启动而存在,有些区域则是依赖用户线程的启动和结束来建立和销毁。Java虚拟机所管理的内存包括以下几个运行时数据区域,如图: 1、程序计数器:指向当前线程正在执行的字节码指令。线程私有的。 2、虚拟机栈:虚拟机栈是Java执行方法的内存模型。每个方法被执行的时候,都会创建一个栈帧,把栈帧压人栈,当方法正常返回或者抛出未捕获的异.原创 2021-01-27 02:09:40 · 171 阅读 · 0 评论 -
JVM性能调优实战:让你的IntelliJ Idea纵享丝滑
前言 在前面整理了一篇关于JVM故障诊断和处理工具,考虑到大部分的Java程序员都使用的是IntelliJ Idea,本篇就使用工具来实战演练对IntelliJ Idea运行速度调优 调优前的运行状态 原始配置内容 要查询idea原始配置文件的路径可以在VisualVM中的概述中查看 原始配置内容: -XX:ReservedCodeCacheSize=240m -XX:+UseCompressedOops -Dfile.encoding=UTF-8 -XX:SoftRefLRUPolicy原创 2021-01-18 23:26:20 · 624 阅读 · 0 评论 -
32个问题,学习Java虚拟机的运行时数据区
学习JVM虚拟机是一个比较枯燥无味的过程,刚开始基本是看不懂学不懂,然后就是似懂非懂,最后觉得好像懂了一些,到后来又觉得还是没懂,反正就是懵懵懂懂,过目就忘,一问就卡住,说也说不清,其实说的就是我自己。 我觉得在学习了相关理论知识之后,除了进行实操之外,通过提问和回答的方式,也能更好的理解所学知识,并检验自己是否真的理解了。 今天我们要学习的是Java虚拟机的运行时数据区,包括程序计数器(Program Counter Register)、Java虚拟机栈(Java Virtual Machine ..原创 2020-10-27 21:34:12 · 194 阅读 · 0 评论 -
一次 Java 进程 OOM 的排查分析(glibc 篇)
遇到了一个 glibc 导致的内存回收问题,查找原因和实验的的过程是比较有意思的,主要会涉及到下面这些: Linux 中典型的大量 64M 内存区域问题 glibc 的内存分配器 ptmalloc2 的底层原理 如何写一个自定义的 malloc hook 动态链接库 so glibc 的内存分配原理(Arena、Chunk 结构、bins 等) malloc_trim 对内存真正回收的影响 gdb 的 heap 调试工具使用 jemalloc 库的介绍与应用 背景 前段时间有同学反馈一个 j原创 2020-09-23 13:30:41 · 1294 阅读 · 3 评论 -
YGC问题排查,又让我涨姿势了!
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务超时,引发性能问题。 我们团队负责的广告系统承接了比较大的C端流量,平峰期间的请求量基本达到了上千QPS,过去也遇到了很多次GC相关的线上问题。 这篇文章,我再分享一个更棘手的Young GC耗时过长的线上案例,同时会整理下YGC相关的知识点,希望让你有所收获。内容分成以下2个部分: 从一次YGC耗时..原创 2020-09-20 14:45:37 · 1036 阅读 · 0 评论 -
高吞吐、低延迟 Java 应用的 GC 优化实践
本篇原文作者是 LinkedIn 的 Swapnil Ghike,这篇文章讲述了 LinkedIn 的 Feed 产品的 GC 优化过程,虽然文章写作于 April 8, 2014,但其中的很多内容和知识点非常有学习和参考意义。 背景 高性能应用构成了现代网络的支柱。LinkedIn 内部有许多高吞吐量服务来满足每秒成千上万的用户请求。为了获得最佳的用户体验,以低延迟响应这些请求是非常重要的。 例如,我们的用户经常使用的产品是 Feed —— 它是一个不断更新的专业活动和内容的列表。Feed 在 .原创 2020-09-18 14:33:41 · 608 阅读 · 0 评论 -
一次“内存泄露”引发的血案
对性能不佳的Ark Server进行了改造和重写。重编发布一段时间后,结果发现新发布的Svr的机器内存一直在上涨。如下图示: 观察后,第一反应是完了,一定存在内存泄露。花了3、4天时间,使用各种办法进行定位,一无所获。 后来无意中在SPP日志中发现了端倪,日志中一直打印tcp socket[%d] user check pkg not ok, but no more memory,看代码逻辑,是收包缓冲区太小,导致调用方不断使用new操作来扩充缓冲区,我仔细检查了下调用方的代码逻辑...原创 2020-09-17 22:44:08 · 363 阅读 · 0 评论