人机工程学 （垃圾回收自学习优化策略）

人机工程学是Java虚拟机和垃圾收集探索式（例如基于行为的探索式算法）提高应用程序性能的过程。
Java虚拟机为垃圾收集器，堆大小和运行时编译器配置提供基于平台的默认选择。这些选择满足不同类型应用程序的需求，并且需要较少的命令行调优。此外，基于行为调优动态优化堆的大小，以满足应用程序特定的性能要求。
本节将介绍这些默认的选择和基于行为的调优。在使用后续章节中更加详细的控制配置前，请使用这些默认配置。

翻译原文

垃圾回收调优简介

从小的桌面应用到大型服务器上的web应用，各种各样的应用程序都使用标准版Java平台（Java SE）。为了支持这一系列不同的部署，Java HotSpot VM提供了多个垃圾收集器，每个垃圾收集器都是为满足不同的需求而设计的。Java SE基于应用程序在计算机上运行的类选择最合适的垃圾收集器。然而，对于每个应用程序，此选择可能不是最优的。具备严格的性能目标或者其他需求的用户，开发人员和管理员可能需要显式地选择垃圾收集器并优化某些参数已达到渴望的性能级别。本文档提供了帮助显式完成优化任务的信息。
首先，垃圾收集器的一般特性和基础的调优选项将被描述通过串行垃圾收集器，然后介绍其他垃圾收集器的具体特性以及选择垃圾收集器时要考虑的因素。

在Java Magazine的前几期文章中，我们介绍了just-in- time (JIT) 编译技术的一些理论基础，以及如何使用Java Microbenching Harness（JMH）和开源工具JITWatch来进行可视化分析，以便搞清楚HotSpot VM的内部机制。在这期文章中，我们将要深入介绍一下逃逸分析（escape analysis）技术，这是JVM最有意思的优化手段之一。逃逸分析是JVM的一项自动分析变量作用域的技术，它可以用来实现某些特殊的优化，后续我们也会分析下这些优化。在开始之前，你只需要掌握一些HotSpot JVM的基本工作原理就可以了。

引子

带着问题去学习一个东西，才会有目标感，我先把一直以来自己对CMS的一些疑惑罗列了下，希望这篇学习笔记能解决掉这些疑惑，希望也能对你有所帮助。

1. CMS出现的初衷、背景和目的？
2. CMS的适用场景？
3. CMS的trade-off是什么?优势、劣势和代价
4. CMS会回收哪个区域的对象？
5. CMS的GC Roots包括那些对象？
6. CMS的过程？
7. CMS和Full gc是不是一回事？
8. CMS何时触发？
9. CMS的日志如何分析？
10. CMS的调优如何做？
11. CMS扫描那些对象？
12. CMS和CMS collector的区别？
13. CMS的推荐参数设置？
14. 为什么ParNew可以和CMS配合使用，而Parallel Scanvenge不可以？

阅读全文

前言

已经记不清有多少读者问过：

博主，你是怎么学习的？像我这样的情况有啥好的建议嘛？

也不知道啥时候我居然成人生导师了。当然我不排斥这些问题，和大家交流都是学习的过程。

因此也许诺会准备一篇关于学习方面的文章；所以本文其实准备了很久，篇幅较长，大家耐心看完希望能有收获。

以下内容仅代表我从业以来所积累的相关经验，我会从硬技能、软实力这些方面尽量阐述我所认为的 “不那么差的程序员” 应当做到哪些技能。

阅读全文

简介

• container： 资源隔离、平台无关， 限制cpu、mem等资源
• Java： 平台无关、Write once, run anywhere、WORA

    java不知道自己运行在container里，以为它看到的资源都能用。结果：java工作在资源充足的
  

阅读全文

前言

Map 这样的 Key Value 在软件开发中是非常经典的结构，常用于在内存中存放数据。

本篇主要想讨论 ConcurrentHashMap 这样一个并发容器，在正式开始之前我觉得有必要谈谈 HashMap，没有它就不会有后面的 ConcurrentHashMap。

阅读全文

前言

在上文「Guava 源码分析（Cache 原理）」中分析了 Guava Cache 的相关原理。

文末提到了回收机制、移除时间通知等内容，许多朋友也挺感兴趣，这次就这两个内容再来分析分析。

在开始之前先补习下 Java 自带的两个特性，Guava 中都有具体的应用。

阅读全文

前言

之前或多或少分享过一些内存模型、对象创建之类的内容，其实大部分人看完都是懵懵懂懂，也不知道这些的实际意义。

直到有一天你会碰到线上奇奇怪怪的问题，如：

• 线程执行一个任务迟迟没有返回，应用假死。
• 接口响应缓慢，甚至请求超时。
• CPU 高负载运行。

这类问题并不像一个空指针、数组越界这样明显好查，这时就需要刚才提到的内存模型、对象创建、线程等相关知识结合在一起来排查问题了。

正好这次借助之前的一次生产问题来聊聊如何排查和解决问题。

阅读全文

前言

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

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

缓存

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

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

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

阅读全文

前言

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

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

阅读全文

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

前言

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

阅读全文

原文链接：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 Streams是RP的基础核心组件。Flow API标志着RP由集市式的自由探索阶段 向 教堂式的统一使用的转变。

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

对了，另外提一下Java 9的Flow API的@author也是 Doug Lee 哦～

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

0. 摘要

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

阅读全文

JVM中有这样一段注释：

[code lang=”java”]
// 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.
[/code]

阅读全文

原文链接

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

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

阅读全文