java - java.lang.Thread 中新增的附加字段，是什么意思？

Question

在 Java 8 中，java.lang.Thread 类获得了 3 个新字段:

/** The current seed for a ThreadLocalRandom */
@sun.misc.Contended("tlr")
long threadLocalRandomSeed;

/** Probe hash value; nonzero if threadLocalRandomSeed initialized */
@sun.misc.Contended("tlr")
int threadLocalRandomProbe;

/** Secondary seed isolated from public ThreadLocalRandom sequence */
@sun.misc.Contended("tlr")
int threadLocalRandomSecondarySeed;

正如它在 Javadoc 中所说的那样，由 java.util.concurrent.ThreadLocalRandom 类专门管理。

此外，在 ThreadLocalRandom 中，它们的使用方式非常怪异:

SEED = UNSAFE.objectFieldOffset
    (tk.getDeclaredField("threadLocalRandomSeed"));
PROBE = UNSAFE.objectFieldOffset
    (tk.getDeclaredField("threadLocalRandomProbe"));
SECONDARY = UNSAFE.objectFieldOffset
    (tk.getDeclaredField("threadLocalRandomSecondarySeed"));

(同样的代码片段也可以在 LockSupport 类中遇到)。

然后这个偏移量在多个 java.concurrent 地方内部使用。

这个想法是什么？为什么这些字段位于 java.lang.Thread 中？为什么不在 ThreadLocalRandom 中？

Answer 1

这些是内部字段。解释只能来自 JDK 开发人员自己。我找到了 post Doug Lea 于 2013 年 1 月发表的有关此内容的文章，解释了这些字段背后的基本原理以及它们为何位于 Thread 类中。

When we introduced ThreadLocalRandom, we conservatively implemented it to use an actual ThreadLocal. However, as it becomes more widely used, it is worth improving the implementation by housing ThreadLocalRandom state (and related bookkeeping) in class Thread itself. This would entail three fields (16 total bytes).

So I propose adding the following to class Thread:

// The following three initially uninitialized fields are exclusively
// managed by class java.util.concurrent.ThreadLocalRandom.
/** The current seed for a ThreadLocalRandom */
long threadLocalRandomSeed;
/** Probe hash value; nonzero if threadLocalRandomSeed initialized */
int threadLocalRandomProbe;
/** Secondary seed isolated from public ThreadLocalRandom sequence */
int threadLocalRandomSecondarySeed;

The reasons for doing it in this way are:

1. Uniformly faster access to ThreadLocalRandom state. While ThreadLocal access is normally pretty fast already, this is not only faster, it does not degrade in cases where user programs create large numbers of ThreadLocals, which may (probabilistically) cause any given access to become slower.

2. Smaller total footprint for any program using ThreadLocalRandom. Three fields require less space than boxing into a padded ThreadLocal object. As ThreadLocalRandom becomes widely used within JDK itself, this includes just about all programs.

3. Further time/space savings for java.util.concurrent ForkJoinPool, ConcurrentHashMap, LongAdder, ConcurrentSkipList, and other classes that could use this form of the unified ThreadLocalRandom bookkeeping rather than their own special-purpose ThreadLocals as they now do.