一、前言

最近一直忙着参与公司的新项目开发，由于临期上线，正在对系统进行性能压测，在这个过程中，发现一些代码有性能优化的空间。因此决定写一篇文章，把本次以及今后，遇到的性能优化的 case 都记录下来，希望对大家们的编码水平能够有所帮助。

一、前言

距离上篇文章更新已经一月有余，之所以一直没更新一是工作最近比较忙，二是感觉产出不了什么对自己和他人有价值的文章。因此这段时间，主要的空闲时间在学习技术和写 GitHub，博客这边就暂时落下了。

本篇文章的落成更像是一篇笔记，而不是博客。因为在一年的工作后，首次碰上了 OOM 问题，虽然导致的原因比较简单，但也算是值得纪念的，哈哈。

一、CPU Cache

存储设备往往是速度越快价格越昂贵，速度越快价格越低廉。在计算机中，CPU 的速度远高于主存的速度，而主存的速度又远高于磁盘的速度。为了解决不同存储部件的速度不对等问题，让高速设备充分发挥性能，引入了多级缓存机制。

为了解决内存和 CPU 的速度不匹配问题，相继引入了 L1 Cache、L2 Cache、L3 Cache，数字越小，容量越小，速度越快，位置越接近 CPU。

一、前言

Java 提供了种类丰富的锁，每种锁因其特性的不同，在适当的场景下能够展现出非常高的效率。本文旨在对锁相关源码（本文中的源码来自 JDK 8和 Netty 3.10.6）和使用场景进行举例，为读者介绍主流锁的知识点，以及不同的锁的适用场景。

Java 中往往是按照是否含有某一特性来定义锁，我们通过特性将锁进行分组归类，再使用对比的方式进行介绍，帮助大家更快捷的理解相关知识。下面给出本文内容的总体分类目录：

一、前言

1.1 文章起因

这篇文章的起因来源于一个 BUG，这个 BUG 和上篇文章《Java SynchronizedSet 线程不安全之坑》 有点关系。简单来说，就是在线程池中执行任务，任务本身未做异常处理，导致出现异常后任务停止。

出错的原因来自对 Collections.synchronizedSet(new HashSet<>()) 的线程不安全访问，抛出了 ConcurrentModificationException。

问题的关键是在事后查询线上日志时并没有发现相关异常记录，导致问题的排查变得困难。所幸最后找到了问题，同时也发现了默认情况下线程中的异常是不会被记录到日志中的，也算是踩了个坑吧，这就是这篇文章的由来。

一、前言

一般而言，想要构造出线程安全的 Set，我们会使用 Collections.synchronizedSet 方法，如下所示。

Set<User> set = Collections.synchronizedSet(new HashSet<>());

但这并不意味着，你可以安全的使用该集合的任何方法，如果没有仔细的了解过其实现的话，一不小心就会踩进坑中。最近我在使用该集合的 stream 方法时发现了线程不安全问题，都是血的教训啊，下面写个Case 来复现下吧。