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 垃圾回收日志

JVM性能优化(三):垃圾收集

原文地址,译文地址,译者:Greenster

Java平台的垃圾收集机制显著提高了开发者的效率,但是一个实现糟糕的垃圾收集器可能过多地消耗应用程序的资源。在Java虚拟机性能优化系列的第三部分,Eva Andreasson向Java初学者介绍了Java平台的内存模型和垃圾收集机制。她解释了为什么碎片化(而不是垃圾收集)是Java应用程序性能的主要问题所在,以及为什么分代垃圾收集和压缩是目前处理Java应用程序碎片化的主要办法(但不是最有新意的)。

垃圾收集(GC)的目的是释放那些不再被任何活动对象引用的Java对象所占用的内存,它是Java虚拟机动态内存管理机制的核心部分。在一个典型的垃圾收集周期里,所有仍然被引用的对象(因此是可达的)都将被保留,而那些不再被引用的对象将被释放、其所占用的空间将被回收用来分配给新的对象。

为了理解垃圾收集机制和各种垃圾收集算法,首先需要知道关于Java平台内存模型的一些知识。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JVM性能优化(三):垃圾收集

JVM优化系列-第二部分-编译器

作者:Eva Andreasson    原文链接  译者:sooerr   校对:赵峰

JVM性能优化系列中,第二篇章里Java编译器是主要部分。Eva Andreasson介绍了不同类型的编译器,并且就客户端、服务器端、分层编译进行了性能对比。她也总结了JVM优化的一些概况,例如死代码的消除、代码内嵌和循环优化。

Java编译器是Java著名的跨平台特性的根源。软件开发者写出了一个理想的Java应用程序,在编写高效、平稳的代码的背后,正是编译器可以保证其运行在潜在的目标平台。不同种类的编译器可以满足多种应用程序的需要,产生出具体期望的性能测试结果。你对编译器了解的越多,例如工作原理和可用种类,那么你将更具备Java应用程序调优的能力。

JVM调优系列的第二篇文章展示并说明了各种虚拟机编译器的不同点。同时,我也会讨论使用Just-In-Time (JIT) 编译器可以实现的共同的优化点。(JVM总揽和介绍请看本系列第一部分”JVM性能调优PART1″)

阅读全文

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

JVM性能优化(一)JVM技术入门

作者 Eva Andreasson  译者:赵峰 校对:方腾飞  原文链接

Java应用程序是运行在JVM上的,但是你对JVM技术了解吗?这篇文章(这个系列的第一部分)讲述了经典Java虚拟机是怎么样工作的,例如:Java一次编写的利弊,跨平台引擎,垃圾回收基础知识,经典的GC算法和编译优化。之后的文章会讲JVM性能优化,包括最新的JVM设计——支持当今高并发Java应用的性能和扩展。

如果你是一个开发人员,你肯定遇到过这样的特殊感觉,你突然灵光一现,所有的思路连接起来了,你能以一个新的视角来回想起你以前的想法。我个人很喜欢学习新知识带来的这种感觉。我已经有过很多次这样的经历了,在我使用JVM技术工作时,特别是使用垃圾回收和JVM性能优化时。在这个新的Java世界中,我希望和你分享我的这些启发。希望你能像我写这篇文章一样兴奋的去了解JVM的性能。
阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JVM性能优化(一)JVM技术入门

ClassNotFoundException: 真的会使你的JVM慢下来吗?

本文翻译自javacodegeeks   作者Pierre Hugues Charbonneau   译者:TonySpark 校对:郑旭东
大多数Java开发者比较熟悉这个普通的 java.lang.ClassNotFoundException。这个问题的根源逐渐被开发人员所了解(在ClassPath中找不到相关类或者类库,类加载器委托问题等等),然而它对于整个JVM及性能的影响却鲜为人知。这个异常会应用程序的响应时间和可扩展性有很大的影响。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: ClassNotFoundException: 真的会使你的JVM慢下来吗?

Java字节码浅析(三)

英文原文链接译文链接,原文作者:James Bloom,译者:有孚

从Java7开始,switch语句增加了对String类型的支持。不过字节码中的switch指令还是只支持int类型,并没有增加对其它类型的支持。事实上switch语句对String的支持是分成两个步骤来完成的。首先,将每个case语句里的值的hashCode和操作数栈顶的值(译注:也就是switch里面的那个值,这个值会先压入栈顶)进行比较。这个可以通过lookupswitch或者是tableswitch指令来完成。结果会路由到某个分支上,然后调用String.equlals来判断是否确实匹配。最后根据equals返回的结果,再用一个tableswitch指令来路由到具体的case分支上去执行。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java字节码浅析(三)

JDK的sql设计不合理导致的驱动类初始化死锁问题

问题描述
当我们一个系统既需要mysql驱动,也需要oracle驱动的时候,在并发加载初始化这些驱动类的过程中产生死锁的可能性非常大,下面是一个模拟的例子,对于Thread2的实现其实是jdk里java.sql.DriverService的逻辑,也是我们第一次调用java.sql.DriverManager.registerDriver注册一个驱动实例要走的逻辑(jdk1.6下),不过这篇文章是使用我们生产环境的一个系统的线程dump和内存dump为基础进行分析展开的。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JDK的sql设计不合理导致的驱动类初始化死锁问题

return top