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

我承认，我自己也忍不住用过这项技术。它简直太方便了，可以省去一次不必要的类型转化。这就是：

除了lambda表达式，stream以及几个小的改进之外，Java 8还引入了一套全新的时间日期API，在本篇教程中我们将通过几个简单的任务示例来学习如何使用Java 8的这套API。Java对日期，日历及时间的处理一直以来都饱受诟病，尤其是它决定将java.util.Date定义为可修改的以及将SimpleDateFormat实现成非线程安全的。看来Java已经意识到需要为时间及日期功能提供更好的支持了，这对已经习惯使用Joda时间日期库的社区而言也是件好事。关于这个新的时间日期库的最大的优点就在于它定义清楚了时间日期相关的一些概念，比方说，瞬时时间（Instant）,持续时间（duration），日期（date）,时间（time），时区（time-zone）以及时间段（Period）。同时它也借鉴了Joda库的一些优点，比如将人和机器对时间日期的理解区分开的。Java 8仍然延用了ISO的日历体系，并且与它的前辈们不同，java.time包中的类是不可变且线程安全的。新的时间及日期API位于java.time包中，下面是里面的一些关键的类：

本文写作的灵感来自Pierre-Hugues Charbonneau的为什么加载不存在的类会影响系统性能一文。这让我想起了之前的一次调试经历，当时也遇到了类似的问题，只不过表现略有不同。

在Plumbr这和GC暂停检测打交道的这段日子里，我查阅了与这个主题相关的大量文章，书籍以及资料。在这当中，我经常会对新生代GC, 年老代GC以及Full GC的事件的使用（滥用）感到困惑。于是便有了这篇文章，希望能够清除一些困惑。

“HI,你能不能过来帮我看下这个奇怪的现象?”我之所以会写这篇文章是因为我在一个技术支持的案例中遇到了这么一个情况。这个问题是由于不同的JVM工具所检测出来的可用内存的大小不一致所产生的。

本文主要是想分析下为什么Plumbr代理在特定的场景下会对GC的暂停时间产生影响，以及影响究竟有多大。在排查这个故障的过程中，我们还发现，在GC暂停的时候，JVMTI（JVM Tool Interface）的打标记操作存在一些有趣的现象。

要设计出好的API绝非易事。真的是很不容易。如果你希望用户能给你的API点个赞的话，设计的时候需要考虑得非常周全。你必须得在以下几点中找到一个平衡点：

几个月前我们介绍了如何通过Plumbr来进行线程锁检测，随后便收到了很多类似的问题，“Hi，文章写得不错，现在我终于知道是什么引发的性能问题了，但是现在我该怎么做？”