共计 17408 个字符,预计需要花费 44 分钟才能阅读完成。
引言
本文介绍了 JDK 中罕用的并发库(JUC)的应用形式,并且自上而下地分析了其实现原理,从间接上级框架 AbstractQueuedSynchronizer,也就是大家常说的 AQS,再到其中应用的 CAS,Wait,Park,最初到操作系统层面的 Mutex,Condition,心愿通过这篇文章,大家可能对整个 Java 并发有一个清晰全面的意识,而且把这些内容串在一起你会发现他们实质上都是相通的。
JUC
在 java.util.concurrent
包(JUC)中,有各式各样的并发管制工具,这里咱们简略介绍一个罕用的工具及其应用形式。
Atomic 类
Atomic 类有很多种,它们都在 java.util.concurrent.atomic
包中。根本都是通过 CAS(CompareAndSwap)来实现的,而 CAS 的具体实现依赖于体系结构提供的指令。
这里咱们仅介绍几个例子,并不会介绍每一个 Atomic 类的应用。首先看一下AtomicInteger,通过它咱们能够无锁化的批改一个 int 类型的值,并且可能保障批改过程是原子的。
public static class LockTest {private AtomicInteger sum = new AtomicInteger(0);
public void increase() {sum.incrementAndGet();
}
}
比方统计一个网页的访问量时,就能够应用它,因为不会应用到锁,所以没有上下文切换的耗费,速度很快。
如果你不仅仅是批改一个根底类型的数据,例如一次要批改好几个根底数据类型得话,你能够把它们封装到一个对象中,而后应用 AtomicReference 来进行整个对象的更新操作。下例中,咱们就一次性更新了一个对象的所有属性。
public static class LockTest {private AtomicReference<LockTest> reference = new AtomicReference<>();
private int test1;
private int test2;
public void changeObject() {reference.getAndUpdate(new UnaryOperator<LockTest>() {@Override public LockTest apply(LockTest test) {LockTest newItem = new LockTest();
newItem.test1 = test.test1 + 1;
newItem.test2 = test.test2 - 1;
return newItem;
}
});
}
}
Aomic 类尽管很快,然而也有一个问题就是 ABA 问题,当一个 Atomic 的值从 A 批改为 B,再从新批改为 A 时,尽管值扭转了,然而在进行 CAS 时,会错认为该值没有发生变化,为了解决这类问题,你能够应用AtomicStampedReference。它通过一个版本号来控制数据的变动,如果遵循应用标准,即每次进行批改时都将版本号加一,那么就能够杜绝 ABA 问题。
public static class LockTest {private AtomicStampedReference<LockTest> reference = new AtomicStampedReference<>(null, 0);
private int test1;
public void changeObject() {LockTest newObject = new LockTest();
for (; ;) {int previousStamp = reference.getStamp();
LockTest previousObject = reference.getReference();
if (reference.compareAndSet(previousObject, newObject, previousStamp, previousStamp + 1)) {break;}
}
}
}
Semaphore
Semaphore(信号量)和 synchronized 相似,是控制线程是否进入某一同步代码区的一种伎俩,然而 synchronized 每次只有一个过程能够进入同步代码区,而 Semaphore 能够指定多个线程同时拜访某个资源。
public static class LockTest {public static void main(String[] args) {ExecutorService threadPool = Executors.newFixedThreadPool(300);
Semaphore semaphore = new Semaphore(5);
for (int i = 0; i < 100; i++) {
int finali = i;
threadPool.execute(() -> {
try {semaphore.acquire();
System.out.println("Index:" + finali);
Thread.sleep(2000);
semaphore.release();} catch (InterruptedException e) {e.printStackTrace();
}
});
}
threadPool.shutdown();}
}
上例中,咱们设定应用了 5 个许可证(同一时刻最多 5 个线程进入同步区),每次调用 acquire
都会耗费一个许可证,调用 release
时开释一个许可证,当许可证有余时调用 acquire
就会进入队列期待,值得一提的是 Semaphore 蕴含两种模式,偏心模式和非偏心模式,在偏心模式下,获取许可证是以 FIFO 的程序进行,而在非偏心模式,是不能保障程序的。
CountDownLatch
CountDownLatch 是一个同步工具类,它容许一个或多个线程始终期待,直到其余线程的操作执行完再执行。上面看一个例子:
public static class LockTest {public static void main(String[] args) throws InterruptedException {ExecutorService threadPool = Executors.newFixedThreadPool(1);
CountDownLatch countDownLatch = new CountDownLatch(5);
for (int i = 0; i < 5; i++) {
int finali = i;
threadPool.submit(() -> {
try {System.out.println("Index:" + finali);
Thread.sleep(2000);
countDownLatch.countDown();} catch (InterruptedException e) {e.printStackTrace();
}
});
}
countDownLatch.await();
System.out.println("Finish");
}
}
首先,咱们指定 CountDownLatch 期待 5 个线程实现工作,在每个线程执行完工作之后,都调用 countDown 函数,它会将 CountDownLatch 外部的计数器减 1,当计数器为 0 时,CountDownLatch::await 函数才会返回。我个别用它来实现 Future 接口。值得一提的是,CountDownLatch 是一次性的,计数器的值只能在构造方法中初始化一次,之后没有任何机制再次对其设置值,当 CountDownLatch 应用结束后,就不能再次被应用。
CyclicBarrier
CyclicBarrier 和 CountDownLatch 十分类似,它也能够实现线程间的计数期待,然而它的性能比 CountDownLatch 更加简单和弱小。它能够管制一组线程全副实现第一轮工作时,再同时开始让它们执行下一轮工作。
public static class LockTest {public static void main(String[] args) {ExecutorService threadPool = Executors.newFixedThreadPool(5);
CyclicBarrier cyclicBarrier = new CyclicBarrier(5, () -> System.out.println("barrierAction merge data"));
for (int i = 0; i < 5; i++) {
int finali = i;
threadPool.submit(() -> {
try {System.out.println("Task 1 Begin Index:" + finali);
Thread.sleep(ThreadLocalRandom.current().nextInt(2000));
System.out.println("Task 1 Finished Index:" + finali);
cyclicBarrier.await();
System.out.println("Task 2 Begin Index:" + finali);
Thread.sleep(ThreadLocalRandom.current().nextInt(2000));
} catch (InterruptedException | BrokenBarrierException e) {e.printStackTrace();
}
});
}
}
}
CyclicBarrier 很适宜进行数据分组解决的工作,而且下一轮工作依赖上一轮工作的后果,比方咱们将一个大工作拆分成很多小工作,当所有小工作实现时,咱们能够通过 barrierAction 合并上一轮工作的后果,而后再开始下一轮工作。
对于 CyclicBarrier 和 CountDownLatch 的区别:
CountDownLatch:A synchronized aid that allows one or more threads to wait until a set of operations being performed in other threads completes.(CountDownLatch: 一个或者多个线程,期待其余多个线程实现某件事情之后能力执行)
CyclicBarrier:A synchronized aid that allows aset of threads to all wait for each other to reach a common barrier point.(CyclicBarrier:多个线程互相期待,直到达到同一个同步点,再持续一起执行。)
ThreadLocal
通常状况下,咱们创立的变量是能够被任何一个线程拜访并批改的。然而 JDK 也为咱们提供了让某一变量独享与各个线程的计划,也就是 ThreadLocal。因为每个线程都有本人专属的变量,所以各个线程在操作 ThreadLocal 变量时不须要加锁。
public static class LockTest {public static void main(String[] args) {ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
new Thread(new Runnable() {@Override public void run() {
try {System.out.println("Thread 1 Current Value:" + threadLocal.get());
threadLocal.set(10);
Thread.sleep(500);
System.out.println("Thread 1 Current Value:" + threadLocal.get());
} catch (InterruptedException e) {e.printStackTrace();
}
}
}).start();
Thread.sleep(100);
new Thread(new Runnable() {@Override public void run() {
try {System.out.println("Thread 2 Current Value:" + threadLocal.get());
threadLocal.set(5);
Thread.sleep(1000);
System.out.println("Thread 2 Current Value:" + threadLocal.get());
} catch (InterruptedException e) {e.printStackTrace();
}
}
}).start();}
}
threadLocal 的初始值是 null,而后线程 1 先启动将值改为 10,100 ms 后线程 2 启动,会发现 threadLocal 的值依然为 null,而后将其改为 5,400ms 后线程 1 从睡眠中昏迷,发现 threadLocal 的值依然为 10,可见这两个线程所观测到的 threadLocal 值是各自独立的。
ThreadLocal 实现
这里咱们简略地介绍一下 ThreadLocal 的实现原理,在每个 Thread 对象中都保留了一个 ThreadLocal Map,其中 key 为 ThreadLocal 对象,Value 为 ThreadLocal 的值。这里 ThreadLocalMap 中的 Entry 应用了弱援用,是为了帮忙 GC。当一个 ThreadLocal 对象不再被援用时,就会被 GC,这时候 ThreadLocalMap 中就会呈现 key 为 null 的状况。然而因为 value 是强援用,所以如果 key 为 null 的数据不加治理的话,就会呈现内存透露问题。ThreadLocalMap 实现中曾经思考了这种状况,在调用 set()、get()、remove() 办法的时候,会清理掉 key 为 null 的记录。应用完 ThreadLocal 办法后最好手动调用 remove()办法,来帮忙 GC。
public class Thread implements Runnable {
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
}
static class ThreadLocalMap {
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object). Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table. Such entries are referred to
* as "stale entries" in the code that follows.
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {super(k);
value = v;
}
}
}
如果一个对象只具备弱援用,那么下次 GC 时该对象就会被清理。弱援用与软援用的区别在于:只含有软援用的对象只有在内存不足(行将产生 OOM)时才会革除,而只含有弱援用的对象下次 GC 时就会革除无论内存是否缓和。
当咱们想要获取 ThreadLocal 值的时候,会从以后 Thread 的 ThreadLocalMap 中查找,如果没有找到时,它会将初始值塞入该 Map 并返回。
/**
* Sets the current thread's copy of this thread-local variable
* to the specified value. Most subclasses will have no need to
* override this method, relying solely on the {@link #initialValue}
* method to set the values of thread-locals.
*
* @param value the value to be stored in the current thread's copy of
* this thread-local.
*/
public void set(T value) {Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
/**
* Set the value associated with key.
*
* @param key the thread local object
* @param value the value to be set
*/
private void set(ThreadLocal<?> key, Object value) {// We don't use a fast path as with get() because it is at
// least as common to use set() to create new entries as
// it is to replace existing ones, in which case, a fast
// path would fail more often than not.
Entry[] tab = table;
int len = tab.length;
// 计算 hash 值对应的槽位
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {ThreadLocal<?> k = e.get();
// 如果该槽位存储的 ThreadLocal 对象就是本人,就返回
if (k == key) {
e.value = value;
return;
}
// 如果遍历找到了一个空的槽位,就占用它
if (k == null) {replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
// 革除 key 为 null 的槽位,如果 size 过大就扩容,扩容阈值是哈希表长度的 2 / 3
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();}
ThreadLocalMap 外部应用一个数组来保留数据,相似 HashMap;每个 ThreadLocal 在初始化的时候会调配一个 threadLocalHashCode,而后和数组的长度进行取模来计算以后 ThreadLocal 变量所处的槽位。然而这样也会呈现 hash 抵触的状况,在 HashMap 中解决抵触是应用链表 + 红黑树的形式。而在 ThreadLocalMap 中,咱们能够看到它间接应用 nextIndex,进行遍历操作,期间如果找到了本人之前应用到的槽位,就间接返回,否则占用一个没有被应用的槽位。很显著当 ThreadLocal 很多时这样效率很低。获取 ThreadLocal 值的过程也相似,先通过 hash 找到槽位,如果该槽位保留的不是咱们要的 ThreadLocal 对象,则进行遍历查找。
private Entry getEntry(ThreadLocal<?> key) {int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
// 间接 hash 槽位找到了指标对象,间接返回
if (e != null && e.get() == key)
return e;
else
// 否则,遍历查找
return getEntryAfterMiss(key, i, e);
}
private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {Entry[] tab = table;
int len = tab.length;
while (e != null) {ThreadLocal<?> k = e.get();
if (k == key)
return e;
if (k == null)
// 这里如果发现了空的槽位,要进行从新 hash,来晋升效率
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}
private int expungeStaleEntry(int staleSlot) {Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// Rehash until we encounter null
Entry e;
int i;
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {ThreadLocal<?> k = e.get();
// 同样如果找到了 key 为 null 的槽位,就把他清空来帮忙 GC
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
// 如果一个节点通过 hash 计算的槽位,和理论保留的槽位不一样时,从计算所得的槽位登程,找到一个为 null 的槽位,并将该节点存进去
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {tab[i] = null;
// Unlike Knuth 6.4 Algorithm R, we must scan until
// null because multiple entries could have been stale.
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
fastThreadLocal
正是因为 JDK 提供的 ThreadLocal 存在性能问题,所以在 Netty 中,对 ThreadLocal 进行了改写,Netty 配套的提供了 FastThreadLocal
,FastThreadLocalThread
,FastThreadLocalRunnable
,其中 FastThreadLocalRunnable 比较简单,就是在原始 Runnable 接口之上的装璜者。达到了执行结束后主动革除 FastThreadLocal 的成果。
final class FastThreadLocalRunnable implements Runnable {
private final Runnable runnable;
private FastThreadLocalRunnable(Runnable runnable) {this.runnable = ObjectUtil.checkNotNull(runnable, "runnable");
}
@Override
public void run() {
try {runnable.run();
} finally {FastThreadLocal.removeAll();
}
}
static Runnable wrap(Runnable runnable) {return runnable instanceof FastThreadLocalRunnable ? runnable : new FastThreadLocalRunnable(runnable);
}
}
FastThreadLocal 必须配合 FastThreadLocalThread 一起应用,能力达到性能更优的成果,否则可能还不如间接应用 JDK 本身的 ThreadLocal。FastThreadLocal 为什么能比 JDK 的实现更快呢,起因就在于 FastThreadLocal 不是应用 hash 表来保留 ThreadLocal 的值,而是间接应用了数组。让咱们看看它的具体实现计划吧。FastThreadLocal 所有的数据都保留在了 InternalThreadLocalMap 中, 这里咱们先明确它是一个保留数据的容器就行,它是如何保留数据的咱们前面介绍。那么,InternalThreadLocalMap 这个容器存在哪了呢?是不是像 JDK 提供的 ThreadLocal 一样把容器(JDK 中用到的 Hash 表)存在了 Thread 对象中呢?没错,如果咱们应用的是 FastThreadLocalThread 的话,InternalThreadLocalMap 就是 FastThreadLocalThread 的一个成员变量。
public class FastThreadLocalThread extends Thread {
// This will be set to true if we have a chance to wrap the Runnable.
private final boolean cleanupFastThreadLocals;
// 保留了所有的 FastThreadLocal 值
private InternalThreadLocalMap threadLocalMap;
// ...
}
上面给大家展现的是 UnpaddedInternalThreadLocalMap 它是 InternalThreadLocalMap 的父类,大部分重要的数据都是保留在 UnpaddedInternalThreadLocalMap 中的。
class UnpaddedInternalThreadLocalMap {
// 当没有应用 FastThreadLocalThread 时,通过 JDK ThreadLocal 来保留
static final ThreadLocal<InternalThreadLocalMap> slowThreadLocalMap = new ThreadLocal<InternalThreadLocalMap>();
static final AtomicInteger nextIndex = new AtomicInteger();
/** Used by {@link FastThreadLocal} */
Object[] indexedVariables;
// ...
}
在 UnpaddedInternalThreadLocalMap 中,通过 JDK 提供的 ThreadLocal 来保留一个 InternalThreadLocalMap,以应答没有应用 FastThreadLocalThread 的状况。正因如此,当 FastThreadLocal 须要获取 InternalThreadLocalMap 对象时会依据以后运行的线程是不是 FastThreadLocalThread 来决定到底从哪里提取 InternalThreadLocalMap。
// InternalThreadLocalMap.java
public static InternalThreadLocalMap get() {Thread thread = Thread.currentThread();
if (thread instanceof FastThreadLocalThread) {
// 以后应用的是 FastThreadLocalThread
return fastGet((FastThreadLocalThread) thread);
} else {
// 以后应用的是 Thread
return slowGet();}
}
// 应用 FastThreadLocalThread 时,间接从成员变量获取
private static InternalThreadLocalMap fastGet(FastThreadLocalThread thread) {InternalThreadLocalMap threadLocalMap = thread.threadLocalMap();
if (threadLocalMap == null) {thread.setThreadLocalMap(threadLocalMap = new InternalThreadLocalMap());
}
return threadLocalMap;
}
// 应用 Thread 时,通过 InternalThreadLocalMap 外部的 ThreadLocal 获取
private static InternalThreadLocalMap slowGet() {
ThreadLocal<InternalThreadLocalMap> slowThreadLocalMap = UnpaddedInternalThreadLocalMap.slowThreadLocalMap;
InternalThreadLocalMap ret = slowThreadLocalMap.get();
if (ret == null) {ret = new InternalThreadLocalMap();
slowThreadLocalMap.set(ret);
}
return ret;
}
明确了 InternalThreadLocalMap 这个容器存在哪了之后,咱们再来看看这个容器外部是如何保留数据的。再回到 UnpaddedInternalThreadLocalMap 的代码中。咱们能够看到这里有一个 indexedVariables 数组,它就是保留所有数据的中央,然而如果咱们要应用数组就得有明确的数据下标对应关系。而那个 nextIndex 原子变量就是保护下标对应关系的要害。
class UnpaddedInternalThreadLocalMap {static final AtomicInteger nextIndex = new AtomicInteger();
/** Used by {@link FastThreadLocal} */
Object[] indexedVariables;
// ...
public static int nextVariableIndex() {int index = nextIndex.getAndIncrement();
if (index < 0) {nextIndex.decrementAndGet();
throw new IllegalStateException("too many thread-local indexed variables");
}
return index;
}
回到 FastThreadLocal 对象中,咱们能够看到这外面有一个动态属性 variablesToRemoveIndex,它的值通过 UnpaddedInternalThreadLocalMap 的动态字段 nextIndex 计算所得。因为 variablesToRemoveIndex 是一个动态属性,而且也是惟一一个动态调用 nextIndex 的中央,所以它的值恒为 0。而每个 FastThreadLocal 对象,都会在构造函数中申请一个新的 index 槽位。
public class FastThreadLocal<V> {private static final int variablesToRemoveIndex = InternalThreadLocalMap.nextVariableIndex();
private final int index;
public FastThreadLocal() {index = InternalThreadLocalMap.nextVariableIndex();
}
当咱们应用 FastThreadLocal 时,比方调用 set 函数,它会先获取 InternalThreadLocalMap 对象,而后依据以后 FastThreadLocal 调配的下标 index,间接设置数组 indexedVariables 中的值。
// FastThreadLocal.java
/**
* Set the value for the current thread.
*/
public final void set(V value) {if (value != InternalThreadLocalMap.UNSET) {
// 获取 Map
InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.get();
setKnownNotUnset(threadLocalMap, value);
} else {remove();
}
}
/**
* @return see {@link InternalThreadLocalMap#setIndexedVariable(int, Object)}.
*/
private void setKnownNotUnset(InternalThreadLocalMap threadLocalMap, V value) {if (threadLocalMap.setIndexedVariable(index, value)) {
// 如果设置胜利,则将该 FastThreadLocal 保存起来,不便后续清理
addToVariablesToRemove(threadLocalMap, this);
}
}
// InternalThreadLocalMap.java
/**
* @return {@code true} if and only if a new thread-local variable has been created
*/
public boolean setIndexedVariable(int index, Object value) {Object[] lookup = indexedVariables;
// 如果长度足够,间接通过 index 进行批改
if (index < lookup.length) {Object oldValue = lookup[index];
lookup[index] = value;
return oldValue == UNSET;
} else {
// 否则进行扩容,扩容后的大小是比 index 大的最小的 2 的幂
expandIndexedVariableTableAndSet(index, value);
return true;
}
}
设置胜利后,会将以后 FastThreadLocal 保留在一个汇合中,之后在进行清理工作时,可能疾速的进行革除。
// FastThreadLocal.java
@SuppressWarnings("unchecked")
private static void addToVariablesToRemove(InternalThreadLocalMap threadLocalMap, FastThreadLocal<?> variable) {Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);
Set<FastThreadLocal<?>> variablesToRemove;
// 保留 FastThreadLocal 对象的汇合存在数组的 index 0 地位,因为 variablesToRemoveIndex 恒等于 0
if (v == InternalThreadLocalMap.UNSET || v == null) {variablesToRemove = Collections.newSetFromMap(new IdentityHashMap<FastThreadLocal<?>, Boolean>());
threadLocalMap.setIndexedVariable(variablesToRemoveIndex, variablesToRemove);
} else {variablesToRemove = (Set<FastThreadLocal<?>>) v;
}
variablesToRemove.add(variable);
}
/**
* Removes all {@link FastThreadLocal} variables bound to the current thread. This operation is useful when you
* are in a container environment, and you don't want to leave the thread local variables in the threads you do not
* manage.
*/
public static void removeAll() {
// 在进行革除时,如果 InternalThreadLocalMap 为空,则阐明没有应用 FastThreadLocal
InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.getIfSet();
if (threadLocalMap == null) {return;}
try {Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);
// 如果 index0 不存在汇合,阐明没有应用 FastThreadLocal
if (v != null && v != InternalThreadLocalMap.UNSET) {@SuppressWarnings("unchecked")
Set<FastThreadLocal<?>> variablesToRemove = (Set<FastThreadLocal<?>>) v;
FastThreadLocal<?>[] variablesToRemoveArray =
variablesToRemove.toArray(new FastThreadLocal[0]);
// 挨个删除汇合中的所有 FastThreadLocal,其中会调用 FastThreadLocal 的 onRemoval 回调函数
for (FastThreadLocal<?> tlv: variablesToRemoveArray) {tlv.remove(threadLocalMap);
}
}
} finally {
// 将整个 InternalThreadLocalMap 删除
InternalThreadLocalMap.remove();}
}
/**
* Sets the value to uninitialized for the specified thread local map;
* a proceeding call to get() will trigger a call to initialValue().
* The specified thread local map must be for the current thread.
*/
@SuppressWarnings("unchecked")
public final void remove(InternalThreadLocalMap threadLocalMap) {if (threadLocalMap == null) {return;}
// 将对应槽位的值设为 null,并返回之前的值
Object v = threadLocalMap.removeIndexedVariable(index);
// 将该 FastThreadLocal 从待删除联合(index0 保留的汇合)中删除
removeFromVariablesToRemove(threadLocalMap, this);
// 如果之前的值不是空,就调用 onRemoval 回调函数
if (v != InternalThreadLocalMap.UNSET) {
try {onRemoval((V) v);
} catch (Exception e) {PlatformDependent.throwException(e);
}
}
}
至此,FastThreadLocal 的核心内容就介绍完了。这里我有一点费解,为什么 InternalThreadLocalMap 的下标分配器 nextIndex 要申明为动态变量,而不是成员变量呢,如果是成员变量的话,就不会有内存的节约了啊,可能当初这种计划效率会略微好一点吧。然而,当初这种实现很可能每个 InternalThreadLocalMap 中的数组中都会有一些空洞(如果以后线程没有应用所有的 FastThreadLocal)。
最初,还有一点要提一下,就是 InternalThreadLocalMap 为了进一步的提高效率在成员变量中增加了几个填充字段。这是为了避免伪共享。
// InternalThreadLocalMap.java
// Cache line padding (must be public)
// With CompressedOops enabled, an instance of this class should occupy at least 128 bytes.
public long rp1, rp2, rp3, rp4, rp5, rp6, rp7, rp8, rp9;
通常 CPU 的缓存行个别是 64 或 128 字节,为了避免 InternalThreadLocalMap 的不同实例被加载到同一个缓存行,咱们须要多余填充一些字段,使得每个实例的大小超出缓存行的大小。
下图是计算的根本构造。L1、L2、L3 别离示意一级缓存、二级缓存、三级缓存,越凑近 CPU 的缓存,速度越快,容量也越小。所以 L1 缓存很小但很快,并且紧靠着在应用它的 CPU 内核;L2 大一些,也慢一些,并且依然只能被一个独自的 CPU 核应用;L3 更大、更慢,并且被单个插槽上的所有 CPU 核共享;最初是主存,由全副插槽上的所有 CPU 核共享。
当 CPU 执行运算的时候,它先去 L1 查找所需的数据、再去 L2、而后是 L3,如果最初这些缓存中都没有,所需的数据就要去主内存拿。走得越远,运算消耗的工夫就越长。所以如果你在做一些很频繁的事,你要尽量确保数据在 L1 缓存中。另外,线程之间共享一份数据的时候,须要一个线程把数据写回主存,而另一个线程拜访主存中相应的数据。
Cache 是由很多个 cache line 组成的。每个 cache line 通常是 64 字节,对应了主内存中的一块儿地址。CPU 每次从主存中拉取数据时,会把相邻的数据也存入同一个 cache line。这就有可能有可能 Thread1 要应用 FastThreadLocal1 时一次性地将两个内存地址相邻的 FastThreadLocal 对象(FastThreadLocal1,FastThreadLocal2)放入本人的 cache line 中。这时候如果另一个线程 Thread2 只批改了 FastThreadLocal2,之后如果 Thread1 要应用 FastThreadLocal1 也须要从主存中从新拉取(因为 FastThreadLocal1 和 FastThreadLocal2 在同一个缓存行中,只有缓存行内的任意地位的数据被批改,那么其余线程就须要从主存中拉取最新的缓存行数据之后能力应用)。这种无奈充沛应用缓存行个性的景象,称为伪共享。