ThreadLocalRandom的特性

Random 的性能问题
使用 Random 类时，为了避免重复创建的开销，我们一般将实例化好的 Random 对象设置为我们所使用服务对象的属性或静态属性，这在线程竞争不激烈的情况下没有问题，但在一个高并发的 web 服务内，使用同一个 Random 对象可能会导致线程阻塞。Random 的随机原理是对一个”随机种子”进行固定的算术和位运算，得到随机结果，再使用这个结果作为下一次随机的种子。在解决线程安全问题时，Random 使用 CAS 更新下一次随机的种子，可以想到，如果多个线程同时使用这个对象，就肯定会有一些线程执行 CAS 连续失败，进而导致线程阻塞。ThreadLocalRandomjdk 的开发者自然考虑到了这个问题，在 concurrent 包内添加了 ThreadLocalRandom 类，第一次看到这个类名，我以为它是通过 ThreadLocal 实现的，进而想到恐怖的内存泄漏问题，但点进源码却没有 ThreadLocal 的影子，而是存在着大量 Unsafe 相关的代码。我们来看一下它的核心代码：UNSAFE.putLong(t = Thread.currentThread(), SEED, r = UNSAFE.getLong(t, SEED) + GAMMA);翻译成更直观的 Java 代码就像：Thread t = Thread.currentThread();long r = UNSAFE.getLong(t, SEED) + GAMMA;UNSAFE.putLong(t, SEED, r);看上去非常眼熟，像我们平常往 Map 里 get/set 一样，以 Thread.currentThread() 获取到的当前对象里 key，以 SEED 随机种子作为 value。但是以对象作为 key 是可能会造成内存泄漏的啊，由于 Thread 对象可能会大量创建，在回收时不 remove Map 里的 value 时会导致 Map 越来越大，最后内存溢出。Unsafe功能不过再仔细看 ThreadLocalRandom 类的核心代码，发现并不是简单的 Map 操作，它的 getLong() 方法需要传入两个参数，而 putLong() 方法需要三个参数，查看源码发现它们都是 native 方法，我们看不到具体的实现。两个方法签名分别是：public native long getLong(Object var1, long var2);public native void putLong(Object var1, long var2, long var4);虽然看不到具体实现，但我们可以查得到它们的功能，下面是两个方法的功能介绍：putLong(object, offset, value) 可以将 object 对象内存地址偏移 offset 后的位置后四个字节设置为 value。getLong(object, offset) 会从 object 对象内存地址偏移 offset 后的位置读取四个字节作为 long 型返回。不安全性作为 Unsafe 类内的方法，它也透露着一股 “Unsafe” 的气息，具体表现就是可以直接操作内存，而不做任何安全校验，如果有问题，则会在运行时抛出 Fatal Error，导致整个虚拟机的退出。在我们的常识里，get 方法是最容易抛异常的地方，比如空指针、类型转换等，但 Unsafe.getLong() 方法是个非常安全的方法，它从某个内存位置开始读取四个字节，而不管这四个字节是什么内容，总能成功转成 long 型，至于这个 long 型结果是不是跟业务匹配就是另一回事了。而 set 方法也是比较安全的，它把某个内存位置之后的四个字节覆盖成一个 long 型的值，也几乎不会出错。那么这两个方法”不安全”在哪呢？它们的不安全并不是在这两个方法执行期间报错，而是未经保护地改变内存，会引起别的方法在使用这一段内存时报错。public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { // Unsafe 设置了构造方法私有，getUnsafe 获取实例方法包私有，在包外只能通过反射获取 Field field = Unsafe.class.getDeclaredField(“theUnsafe”); field.setAccessible(true); Unsafe unsafe = (Unsafe) field.get(null); // Test 类是一个随手写的测试类，只有一个 String 类型的测试类 Test test = new Test(); test.ttt = “12345”; unsafe.putLong(test, 12L, 2333L); System.out.println(test.value); }运行上面的代码会得到一个 fatal error，报错信息为 “A fatal error has been detected by the Java Runtime Environment: … Process finished with exit code 134 (interrupted by signal 6: SIGABRT)”。可以从报错信息中看到虚拟机因为这个 fatal error abort 退出了，原因也很简单，我使用 unsafe 将 Test 类 value 属性的位置设置成了 long 型值 2333，而当我使用 value 属性时，虚拟机会将这一块内存解析为 String 对象，原 String 对象对象头的结构被打乱了，解析对象失败抛出了错误，更严重的问题是报错信息中没有类名行号等信息，在复杂项目中排查这种问题真如同大海捞针。不过 Unsafe 的其他方法可不一定像这一对方法一样，使用他们时可能需要注意另外的安全问题，之后有遇到再说。