JVM ’ 目录归档

我们的垃圾收集器

原文链接

(译者注:这篇博文发表在2008年,虽然年代有些久远,但是文中说到的垃圾收集器我们至今还在使用,作者也谈到了对于G1垃圾收集器的期望。)

最近我在白板上给客户化了一个图表,他们似乎对这个有点兴趣,所以我想我可以重画一遍来给你们消遣。

Collectors1

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 我们的垃圾收集器


一次应用OOM排查

前段时间系统经常出现OOM,每次出现之后系统会出现各种问题,临时解决方案只能是重启,然后等找到问题后再发布解决。

 

线上问题日志如下:

Exception in thread "msgWorkTP-811568603-1-thread-6" java.lang.OutOfMemoryError: Java heap space

Exception in thread "schedulerFactory_QuartzSchedulerThread" java.lang.OutOfMemoryError: Java heap space

Exception in thread "server-timer" java.lang.OutOfMemoryError: Java heap space

Exception in thread "Tracer-AsyncAppender-Thread-CommonAppender" java.lang.OutOfMemoryError: Java heap space

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 一次应用OOM排查


《 Java并发编程从入门到精通》 常见的内存溢出的三种情况

javaC
作者:张振华    购买链接:天猫商城  JD商城  当当书店

鸟欲高飞先振翅,人求上进先读书。本文是原书的第9章 线程的监控及其日常工作中如何分析里的9.3.3节常见的内存溢出的三种情况。
阅读全文


Java 9中将移除 Sun.misc.Unsafe

原文链接    译者:曲东方

灾难将至,Java 9中将移除 Sun.misc.Unsafe

Oracle 正在计划在Java 9中去掉 sun.misc.Unsafe API。 这绝对将是一场灾难,有可能会彻底破坏整个 java 生态圈。 几乎每个使用 java开发的工具、软件基础设施、高性能开发库都在底层使用了 sun.misc.Unsafe。 下面是上面链接中文档提到一个小列表:

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java 9中将移除 Sun.misc.Unsafe


深入浅出ClassLoader

Dedicate to Molly.

你真的了解ClassLoader吗?

这篇文章翻译自zeroturnaround.com的 Do You Really Get Classloaders? ,融入和补充了笔者的一些实践、经验和样例。本文的例子比原文更加具有实际意义,文字内容也更充沛一些,非常感谢作者 Jevgeni Kabanov 能够共享如此优秀的文档。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 深入浅出ClassLoader


通过JVM日志来进行安全点分析

原文链接 作者: Plumbr 译者:之诸暇

许多事件都可能会导致JVM暂停所有的应用线程。这类暂停又被称为”stop-the-world”(STW)暂停。触发STW暂停最常见的原因就是垃圾回收了(github中的一个例子),但不同的JIT活动(例子),偏向锁擦除(例子),特定的JVMTI操作,以及许多场景也可能会导致应用程序暂停。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 通过JVM日志来进行安全点分析


Java代码到字节码——第一部分

原文地址 作者:James Bloom 译者:张坤

理解在Java虚拟机中Java代码如何别被编译成字节码并执行是非常重要的,因为这可以帮助你理解你的程序在运行时发生了什么。这种理解不仅能确保你对语言特性有逻辑上的认识而且做具体的讨论时可以理解在语言特性上的妥协和副作用。 阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java代码到字节码——第一部分


为什么我的JVM能实际使用的内存比-Xmx指定的少?

原文链接

作者:Nikita Salnikov-Tarnovski   译者:Amanda    校对:

你好,你能过来看看帮我解决一个奇怪的问题么。”就是这个技术支持案例使我想起写下这篇帖子。眼前的这个问题就是关于不同工具对于可用内存大小检测的差异。

其实就是一个工程师在调查一个应用程序的过高的内存使用情况时发现,尽管该程序已经被指定分配2G堆内存,但是JVM检测工具似乎并不能确定进程实际能用多少内存。例如 jconsole显示可用堆内存为1,963M,然而 jvisualvm 却显示能用2,048M。所以到底哪个工具才是对的,为什么检测结果会出现差异呢?

这确实是个挺奇怪的问题,特别是当最常出现的几种解释理由都被排除后,看来JVM并没有耍一些明显的小花招:

  • -Xmx-Xms是相等的,因此检测结果并不会因为堆内存增加而在运行时有所变化。
  • 通过关闭自适应调整策略(-XX:-UseAdaptiveSizePolicy),JVM已经事先被禁止动态调整内存池的大小。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 为什么我的JVM能实际使用的内存比-Xmx指定的少?


并发环境下HashMap引起的full gc排查

作者:佐井    原文地址

现象

最近上线一个需求,完成需求的过程对代码进行了一次重构。应用发布后半个小时左右,发现一个机器报警,load过高。登陆机器看CPU使用情况,发现load已经正常,看下CPU使用情况,发现有一个核跑满,其他CPU使用率很低。大概一个小时后,其他机器陆续报警,发现同样的问题,紧急回滚应用。

应用运行在16G内存的虚机上,整个JVM11G内存,其中新生代3G,CMS gc,JDK7。

第一反应是JVM可能在进行full gc,因为只有一个线程跑满,其他线程被JVM暂停了。先去应用日志看下应用运行情况,果然日志已经没有任何输出。jstat -gcutil查看JVM内存使用情况,发现Old区使用已经100%。

阅读全文

G1垃圾收集器介绍

原文链接,译者:Greenster

简介

Oracle在JDK7 update 4之后开始完全支持G1垃圾收集器,G1是一个针对多处理器大容量内存的服务器端的垃圾收集器,其目标是在实现高吞吐量的同时,尽可能的满足垃圾收集暂停时间的要求。G1在执行一些Java堆空间中的全区域操作(如:全局标记)时是和应用程序线程并发进行的,因此减少了Java堆空间的中断比例。(译者注:可简单理解为减少了Stop-the-World的时间比例) 阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: G1垃圾收集器介绍


JVM的持久代——何去何从?

英文原文链接译文链接,原文作者:Abhishek Gupta ,译者:有孚

本文会介绍一些JVM内存结构的基本概念,然后很快会讲到持久代,来看下Java SE 8发布后它究竟到哪去了。

基础知识

JVM只不过是运行在你系统上的另一个进程而已,这一切的魔法始于一个java命令。正如任何一个操作系统进程那样,JVM也需要内存来完成它的运行时操作。记住——JVM本身是硬件的一层软件抽象,在这之上才能够运行Java程序,也才有了我们所吹嘘的平台独立性以及WORA(一次编写,处处运行)。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JVM的持久代——何去何从?


GC对吞吐量的影响

英文原文链接译文链接,原文作者:Nikita Salnikov-Tarnovski,译者:有孚

在看内存管理术语表的时候偶然发现了”Pig in the Python(注:有点像中文里的贪心不足蛇吞象)”的定义,于是便有了这篇文章。表面上看,这个术语说的是GC不停地将大对象从一个分代提升到另一个分代的情景。这么做就好比巨蟒整个吞食掉它的猎物,以至于它在消化的时候都没办法移动了。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: GC对吞吐量的影响


JVM性能优化系列

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JVM性能优化系列


JVM 性能优化,第二部分:编译器

JVM 性能优化,第二部分:编译器

—为你的应用程序选择正确的Java编译器

 原文连接 译者:Vitas

本文将是JVM 性能优化系列的第二篇文章,Java 编译器将是本文讨论的核心内容。

本文中,作者(Eva Andreasson)首先介绍了不同种类的编译器,并对客户端编译,服务器端编译器和多层编译的运行性能进行了对比。然后,在文章的最后介绍了几种常见的JVM优化方法,如死代码消除,代码嵌入以及循环体优化。

Java最引以为豪的特性“平台独立性”正是源于Java编译器。软件开发人员尽其所能写出最好的java应用程序,紧接着后台运行的编译器产生高效的基于目标平台的可执行代码。不同的编译器适用于不同的应用需求,因而也就产生不同的优化结果。因此,如果你能更好的理解编译器的工作原理、了解更多种类的编译器,那么你就能更好的优化你的Java程序。

本篇文章突出强调和解释了各种Java虚拟机编译器之间的不同。同时,我也会探讨一些及时编译器(JIT)常用的优化方案。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JVM 性能优化,第二部分:编译器


了解 CMS 垃圾回收日志

原文地址   作者: poonam 译者:严亮 校对:梁海舰

在CMS GC 时,使用参数-XX:+PrintGCDetails-XX:+PrintGCTimeStamps 会输出很多日志信息,了解这些信息可以帮我们更好的调整参数,以获得更高的性能。

我们来看下在JDK1.4.2_10 中CMS GC日志示例:

39.910: [GC 39.910: [ParNew: 261760K->0K(261952K), 0.2314667 secs] 262017K->26386K(1048384K), 0.2318679 secs]
新生代使用 (ParNew 并行)回收器。新生代容量为261952K,GC回收后占用从261760K降到0,耗时0.2314667秒。(译注:262017K->26386K(1048384K), 0.2318679 secs 表示整个堆占用从262017K 降至26386K,费时0.2318679)

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 了解 CMS 垃圾回收日志


return top