Archive for the ‘ JVM ’ Category

Guava 源码分析之Cache的实现原理

前言

Google 出的 Guava 是 Java 核心增强的库,应用非常广泛。

我平时用的也挺频繁,这次就借助日常使用的 Cache 组件来看看 Google 大牛们是如何设计的。

缓存

本次主要讨论缓存。缓存在日常开发中举足轻重,如果你的应用对某类数据有着较高的读取频次,并且改动较小时那就非常适合利用缓存来提高性能。

缓存之所以可以提高性能是因为它的读取效率很高,就像是 CPU 的 L1、L2、L3 缓存一样,级别越高相应的读取速度也会越快。

但也不是什么好处都占,读取速度快了但是它的内存更小资源更宝贵,所以我们应当缓存真正需要的数据。其实也就是典型的空间换时间。下面谈谈 Java 中所用到的缓存。

Read more

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Guava 源码分析之Cache的实现原理

你应该知道的 volatile 关键字

前言

不管是在面试还是实际开发中 volatile 都是一个应该掌握的技能。

首先来看看为什么会出现这个关键字。

Read more

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 你应该知道的 volatile 关键字

深度解析Java线程池的异常处理机制

作者:aCoder2013 首发博客地址:https://github.com/aCoder2013/blog/issues/3

前言

今天小伙伴遇到个小问题,线程池提交的任务如果没有catch异常,那么会抛到哪里去,之前倒是没研究过,本着实事求是的原则,看了一下代码。

Read more

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 深度解析Java线程池的异常处理机制

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提供的Stream
  2. 另外Java 8还提供了Lamda(有效地表达和使用RP需要FP的语言构件和理念)。
  3. 有了前面的这些稳健但不失时机的准备,在Java 9中提供了面向RP的官方Flow API,实际上是直接把Reactive Streams的接口加在Java标准库中,即Reactive Streams规范转正了,Reactive StreamsRP的基础核心组件。Flow 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垃圾收集器介绍

return top