作者：Eva Andreasson 原文链接 译者：sooerr 校对：赵峰
JVM性能优化系列中，第二篇章里Java编译器是主要部分。Eva Andreasson介绍了不同类型的编译器，并且就客户端、服务器端、分层编译进行了性能对比。她也总结了JVM优化的一些概况，例如死代码的消除、代码内嵌和循环优化。
Java编译器是Java著名的跨平台特性的根源。软件开发者写出了一个理想的Java应用程序，在编写高效、平稳的代码的背后，正是编译器可以保证其运行在潜在的目标平台。不同种类的编译器可以满足多种应用程序的需要，产生出具体期望的性能测试结果。你对编译器了解的越多，例如工作原理和可用种类，那么你将更具备Java应用程序调优的能力。
JVM调优系列的第二篇文章展示并说明了各种虚拟机编译器的不同点。同时，我也会讨论使用Just-In-Time (JIT) 编译器可以实现的共同的优化点。（JVM总揽和介绍请看本系列第一部分”JVM性能调优PART1″）
作者 Eva Andreasson 译者：赵峰 校对：方腾飞 原文链接
Java应用程序是运行在JVM上的，但是你对JVM技术了解吗？这篇文章（这个系列的第一部分）讲述了经典Java虚拟机是怎么样工作的，例如：Java一次编写的利弊，跨平台引擎，垃圾回收基础知识，经典的GC算法和编译优化。之后的文章会讲JVM性能优化，包括最新的JVM设计——支持当今高并发Java应用的性能和扩展。
如果你是一个开发人员，你肯定遇到过这样的特殊感觉，你突然灵光一现，所有的思路连接起来了，你能以一个新的视角来回想起你以前的想法。我个人很喜欢学习新知识带来的这种感觉。我已经有过很多次这样的经历了，在我使用JVM技术工作时，特别是使用垃圾回收和JVM性能优化时。在这个新的Java世界中，我希望和你分享我的这些启发。希望你能像我写这篇文章一样兴奋的去了解JVM的性能。
阅读全文
本文翻译自javacodegeeks 作者：Pierre Hugues Charbonneau 译者：TonySpark 校对：郑旭东
大多数Java开发者比较熟悉这个普通的 java.lang.ClassNotFoundException。这个问题的根源逐渐被开发人员所了解（在ClassPath中找不到相关类或者类库，类加载器委托问题等等），然而它对于整个JVM及性能的影响却鲜为人知。这个异常会应用程序的响应时间和可扩展性有很大的影响。
英文原文链接，译文链接，原文作者：James Bloom，译者：有孚
从Java7开始，switch语句增加了对String类型的支持。不过字节码中的switch指令还是只支持int类型，并没有增加对其它类型的支持。事实上switch语句对String的支持是分成两个步骤来完成的。首先，将每个case语句里的值的hashCode和操作数栈顶的值（译注：也就是switch里面的那个值，这个值会先压入栈顶）进行比较。这个可以通过lookupswitch或者是tableswitch指令来完成。结果会路由到某个分支上，然后调用String.equlals来判断是否确实匹配。最后根据equals返回的结果，再用一个tableswitch指令来路由到具体的case分支上去执行。
问题描述
当我们一个系统既需要mysql驱动，也需要oracle驱动的时候，在并发加载初始化这些驱动类的过程中产生死锁的可能性非常大，下面是一个模拟的例子，对于Thread2的实现其实是jdk里java.sql.DriverService的逻辑，也是我们第一次调用java.sql.DriverManager.registerDriver注册一个驱动实例要走的逻辑(jdk1.6下)，不过这篇文章是使用我们生产环境的一个系统的线程dump和内存dump为基础进行分析展开的。
原文发表于CodeCentric博客，经原作者Sven Ruppert授权由并发编程网翻译并分享。
JVM是Java Virtual Machine（Java虚拟机）的缩写，Java通过使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java具备了一次编写，多处运行的特性。JVM一直是Java学习中的重点，也是难点。并发编程网组织翻译了JVM实用参数系列文章，旨在帮助大家了解JVM的结构以及相关参数。JVM实用参数系列一共包括八篇文章，由浅入深，从编译器、垃圾回收、内存调优等方面介绍JVM。
特别感谢CodeCentric AG授权我们翻译此部分文章；同时感谢译者赵峰、郑旭东、Greenster、iDestiny、张军、李洪柱以及参与校对的主编们。由于翻译时间仓促，内容难免有疏漏之处，敬请批评指正。另外我们接下来会翻译一些关于垃圾回收算法和垃圾回收器的优质文章，敬请期待。
阅读全文
作者： PATRICK PESCHLOW 原文地址 译者：赵峰 校对：许巧辉
在这个系列的第二部分，我来介绍一下HotSpot JVM提供的不同类别的参数。我同样会讨论一些关于JIT编译器诊断的有趣参数。
JVM 参数分类
HotSpot JVM 提供了三类参数。第一类包括了标准参数。顾名思义，标准参数中包括功能和输出的参数都是很稳定的，很可能在将来的JVM版本中不会改变。你可以用java命令（或者是用 java -help）检索出所有标准参数。我们在第一部分中已经见到过一些标准参数，例如：-server。
阅读全文
HotSpot JVM的并发标记清理收集器(CMS收集器)的主要目标就是：低应用停顿时间。该目标对于大多数交互式应用很重要，比如web应用。在我们看一下有关JVM的参数之前,让我们简要回顾CMS收集器的操作和使用它时可能出现的主要挑战。
就像吞吐量收集器(参见本系列的第6部分),CMS收集器处理老年代的对象,然而其操作要复杂得多。吞吐量收集器总是暂停应用程序线程，并且可能是相当长的一段时间，然而这能够使该算法安全地忽略应用程序。相比之下，CMS收集器被设计成在大多数时间能与应用程序线程并行执行，仅仅会有一点(短暂的)停顿时间。GC与应用程序并行的缺点就是，可能会出现各种同步和数据不一致的问题。为了实现安全且正确的并发执行，CMS收集器的GC周期被分为了好几个连续的阶段。
阅读全文
原文链接 本文连接 译者：张军 校对：梁海舰
在实践中我们发现对于大多数的应用领域，评估一个垃圾收集(GC)算法如何根据如下两个标准：
首先让我们来明确垃圾收集(GC)中的两个术语:吞吐量(throughput)和暂停时间(pause times)。 JVM在专门的线程(GC threads)中执行GC。 只要GC线程是活动的，它们将与应用程序线程(application threads)争用当前可用CPU的时钟周期。 简单点来说，吞吐量是指应用程序线程用时占程序总用时的比例。 例如，吞吐量99/100意味着100秒的程序执行时间应用程序线程运行了99秒， 而在这一时间段内GC线程只运行了1秒。
阅读全文
译者：李洪柱 校对：方腾飞
本篇文章基于Java 6（update 21oder 21之后）版本， HotSpot JVM 提供给了两个新的参数，在JVM启动后，在命令行中可以输出所有XX参数和值。
-XX:+PrintFlagsFinal and -XX:+PrintFlagsInitial
让我们现在就了解一下新参数的输出。以 -client 作为参数的 -XX:+PrintFlagsFinal 的结果是一个按字母排序的590个参数表格（注意，每个release版本参数的数量会不一样）
原文链接 作者： PATRICK PESCHLOW ；译者：严亮
本部分，我们将关注堆(heap) 中一个主要区域，新生代(young generation)。首先我们会讨论为什么调整新生代的参数会对应用的性能如此重要，接着我们将学习新生代相关的JVM参数。
单纯从JVM的功能考虑，并不需要新生代，完全可以针对整个堆进行操作。新生代存在的唯一理由是优化垃圾回收(GC)的性能。更具体说，把堆划分为新生代和老年代有2个好处：简化了新对象的分配(只在新生代分配内存),可以更有效的清除不再需要的对象(即死对象)(新生代和老年代使用不同的GC算法)
通过广泛研究面向对象实现的应用，发现一个共同特点：很多对象的生存时间都很短。同时研究发现，新生对象很少引用生存时间长的对象。结合这2个特点，很明显 GC 会频繁访问新生对象，例如在堆中一个单独的区域，称之为新生代。在新生代中，GC可以快速标记回收”死对象”，而不需要扫描整个Heap中的存活一段时间的”老对象”。
英文原文链接，译文链接，原文作者：James Bloom，译者：有孚
明白Java代码是如何编译成字节码并在JVM上运行的非常重要，这有助于理解程序运行的时候究竟发生了些什么。理解这点不仅能搞清语言特性是如何实现的，并且在做方案讨论的时候能清楚相应的副作用及权衡利弊。
本文介绍了Java代码是如何编译成字节码并在JVM上执行的。想了解JVM的内部结构以及字节码运行时用到的各个内存区域，可以看下我前面的一篇关于JVM内部细节的文章。
感谢同事【沐剑】的投稿
重排序通常是编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。重排序分为两类：编译期重排序和运行期重排序，分别对应编译时和运行时环境。
在并发程序中，程序员会特别关注不同进程或线程之间的数据同步，特别是多个线程同时修改同一变量时，必须采取可靠的同步或其它措施保障数据被正确地修改，这里的一条重要原则是：不要假设指令执行的顺序，你无法预知不同线程之间的指令会以何种顺序执行。
但是在单线程程序中，通常我们容易假设指令是顺序执行的，否则可以想象程序会发生什么可怕的变化。理想的模型是：各种指令执行的顺序是唯一且有序的，这个顺序就是它们被编写在代码中的顺序，与处理器或其它因素无关，这种模型被称作顺序一致性模型，也是基于冯·诺依曼体系的模型。当然，这种假设本身是合理的，在实践中也鲜有异常发生，但事实上，没有哪个现代多处理器架构会采用这种模型，因为它是在是太低效了。而在编译优化和CPU流水线中，几乎都涉及到指令重排序。 阅读全文
Loading...
