Java避坑指南——高并发场景下的性能隐藏杀手“UUID”

本文预计阅读时间：10分钟

最近开发了一个新需求，要求对项目做压测，很奇怪，单机达到20万QPS之后就怎么也上不去了，增加线程之后，性能反而下降的厉害。经过一番分析，发现处理线程会block在UUID的一个地方，跟踪源码才发现了这个大坑。

先来介绍下它吧，UUID (Universally Unique Identifier) 大家都很熟悉，它是由一组32位数的16进制数字所构成，采用如下编码规则

1-8位采用系统时间，在系统时间上精确到毫秒级保证时间上的惟一性；9-16位采用底层的IP地址，在服务器集群中的惟一性；17-24位采用当前对象的HashCode值，在一个内部对象上的惟一性；25-32位采用调用方法的一个随机数，在一个对象内的毫秒级的惟一性。

通过以上4种策略能够保证在整个分布式系统中的惟一性。

使用非常简单，Java提供了简易的api。

    public String createUUID() {
        UUID uuid = UUID.randomUUID();
        return uuid.toString();
    }

但是，就是这短短的两句，成为了系统的性能瓶颈。

我们先来看下压测。。

机器配置

CPU: 16核 2.20GHz 
Memory: 16G 
JDK: 1.8 
VM:?CentOS?6 
GC: G1

测试代码

 while (true) {
     UUID.randomUUID();
 }

压测结果

很奇怪，常理来说，增大线程数都会带来性能的提升，但是在UUID这里行不通了。使用jstack发现，线程都block在了这里

test-thread    BLOCKED    blocked on java.security.SecureRandom@3b194842 owned by "test-thread" Id=358
at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
at java.util.UUID.randomUUID(UUID.java:145)
.....
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
at java.lang.Thread.run (Thread.java:745)

看到这里，基本已经知道问题了，UUID.randomUUID()是一个静态方法，内部使用一个静态成员变量SecureRandom，在SecureRandom内部有一个方法级别的锁,所以在锁竞争非常强烈的时候性能会下降的特别厉害。

public static UUID randomUUID() {
    SecureRandom ng = Holder.numberGenerator;

    byte[] randomBytes = new byte[16];
    ng.nextBytes(randomBytes);
    randomBytes[6]  &= 0x0f;  /* clear version        */
    randomBytes[6]  |= 0x40;  /* set to version 4     */
    randomBytes[8]  &= 0x3f;  /* clear variant        */
    randomBytes[8]  |= 0x80;  /* set to IETF variant  */
    return new UUID(randomBytes);
}

我们再看下SecureRandom的Java doc

 * Note: Depending on the implementation, the {@code generateSeed} and * {@code nextBytes} methods may block as entropy is being gathered, * for example, if they need to read from /dev/random on various Unix-like * operating systems.

意思是SecureRandom的generateSeed和nextBytes这两个方法可能会block，依赖随机数的产生，如果随机数不够了，它有可能就会堵塞在那边。比如随机数的产生是读取unix类系统的/dev/random文件。为什么是比如呢？事实上SecureRandom是使用SPI做扩展的。

public void nextBytes(byte[] bytes) {
   secureRandomSpi.engineNextBytes(bytes);
}

那么/dev/random又是什么呢？Unix-Like或者Linux系统有两个随机伪设备：/dev/random和/dev/urandom，他们提供永不为空的随机字节数据流。/dev/random和/dev/urandom是Linux系统中提供的随机伪设备，这两个设备的任务，是提供永不为空的随机字节数据流。

/dev/random的random pool依赖于系统中断，因此在系统的中断数不足时，/dev/random设备会一直封锁，尝试读取的进程就会进入等待状态，直到系统的中断数充分够用, /dev/random设备可以保证数据的随机性。

而/dev/urandom不依赖系统的中断，也就不会造成进程忙等待，但是数据的随机性比/dev/random低，在不是对随机性要求特别高的场景下，可以提供更高的性能

在java启动项中增加-Djava.security.egd=file:/dev/./urandom 配置项之后，再测试一下, 性能提升了1.5倍。

某团基础架构部搬砖工，专注于高并发、高可靠系统研发。本公号主要素材来自于个人日常工作、思考，偶尔也有前沿新闻、国外译文。关注我就对了= =

往期文章：

为什么面试必问线程状态？你的回答满分了吗

21个最常见Java并发编程面试题

线上服务宕机问题排查思路

吃瓜吃瓜！今年应届生有点牛