Archive for the ‘ JVM ’ Category

Java Fork/Join框架

原文链接:A Java Fork/Join Framework(PDF) – Doug Lea

译序

Doug Lea 大神关于Java 7引入的他写的Fork/Join框架的论文。

响应式编程Reactive Programming / RP)作为一种范式在整个业界正在逐步受到认可和落地,是对过往系统的业务需求理解梳理之后对系统技术设计/架构模式的提升总结。Java作为一个成熟平台,对于趋势一向有些稳健的接纳和跟进能力,有着令人惊叹的生命活力:

  1. Java 7提供了ForkJoinPool,支持了Java 8提供的StreamReactive StreamRP的一个核心组件)。
  2. 另外Java 8还提供了Lamda(有效地表达和使用RP需要FP的语言构件和理念)。
  3. 有了前面的这些稳健但不失时机的准备,在Java 9中提供了面向RPFlow API,为Java圈子提供了官方的RP API,标志着RP由集市式的自由探索阶段 向 教堂式的统一使用的转变。

通过上面这些说明,可以看到ForkJoinPool的基础重要性。

对了,另外提一下Java 9Flow API@author也是 Doug Lee 哦~

PS:基于Alex/萧欢 翻译、方腾飞 校对的译文稿:Java Fork Join 框架,补译『结论』之后3节,调整了格式和一些用词,整理成完整的译文。译文源码在GitHub的这个仓库中,可以提交Issue/Fork后提交代码来建议/指正。

0. 摘要

这篇论文描述了Fork/Join框架的设计、实现以及性能,这个框架通过(递归的)把问题划分为子任务,然后并行的执行这些子任务,等所有的子任务都结束的时候,再合并最终结果的这种方式来支持并行计算编程。总体的设计参考了为Cilk设计的work-stealing框架。就设计层面来说主要是围绕如何高效的去构建和管理任务队列以及工作线程来展开的。性能测试的数据显示良好的并行计算程序将会提升大部分应用,同时也暗示了一些潜在的可以提升的空间。

Read more

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java Fork/Join框架



JAVA互斥锁(synchronized&Lock):行为分析及源码

JVM中有这样一段注释:

// The base-class, PlatformEvent, is platform-specific while the ParkEvent is
// platform-independent.  PlatformEvent provides park(), unpark(), etc., and
// is abstract -- that is, a PlatformEvent should never be instantiated except
// as part of a ParkEvent.
// Equivalently we could have defined a platform-independent base-class that
// exported Allocate(), Release(), etc.  The platform-specific class would extend
// that base-class, adding park(), unpark(), etc.
//
// A word of caution: The JVM uses 2 very similar constructs:
// 1. ParkEvent are used for Java-level "monitor" synchronization.
// 2. Parkers are used by JSR166-JUC park-unpark.
//
// We'll want to eventually merge these redundant facilities and use ParkEvent.

Read more

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JAVA互斥锁(synchronized&Lock):行为分析及源码



我们的垃圾收集器

原文链接

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

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

Collectors1

Read more

原创文章,转载请注明: 转载自并发编程网 – 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

Read more

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



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

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

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



Java 9中将移除 Sun.misc.Unsafe

原文链接    译者:曲东方

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

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

Read more

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



深入浅出ClassLoader

Dedicate to Molly.

你真的了解ClassLoader吗?

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

Read more

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



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

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

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

Read more

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



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

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

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

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



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

原文链接

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

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

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

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

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

Read more

原创文章,转载请注明: 转载自并发编程网 – 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%。

Read more

G1垃圾收集器介绍

原文链接,译者:Greenster

简介

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

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



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

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

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

基础知识

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

Read more

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



GC对吞吐量的影响

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

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

Read more

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



JVM性能优化系列

Read more

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



return top