写点什么

【源码分析】【netty】FastThreadLocal 为什么快?

作者:如果晴天
  • 2023-05-18
    江苏
  • 本文字数:8423 字

    阅读完需:约 28 分钟

写在前面

接下来几篇文章,我们来聊一聊 netty 相关的。这里作者想先从 FastThreadLocal 开始说,而不是可能大家更熟悉的 reactor 啊,责任链设计啊,ByteBuf 啊,池化啊等等。不过虽然说 FastThreadLocal 熟知程度不如其他的,但是其实还是很有内容的。比如最核心的为啥快呢?它解决了 jdk 的 ThreadLocal 什么问题?


版本约定

				<dependency>            <groupId>io.netty</groupId>            <artifactId>netty-all</artifactId>            <version>4.1.92.Final</version>        </dependency>
复制代码

JDK:1.8.0_181


名词约定

ThreadLocal

直译就是本地线程,作者一般喜欢叫线程变量。从 1.2 开始便在 jdk 中了。


带着疑问

这个疑问应该显而易见拉,为什么快啊?这么嚣张在 jdk 的 ThreadLocal 前面加上 Fast!


源码分析

既然说是 FastThreadLocal,那我们肯定要先看一下 ThreadLocal 是大概怎么实现的

  • 先来看一下 javadoc。大意就是与一般我们使用的 get,set 的变量不同,本地线程的变量是单独初始化,并且共享的是副本。并且推荐本地线程的变量声明推荐私有静态,用于希望让变量声明周期与线程关联上

 * This class provides thread-local variables.  These variables differ from * their normal counterparts in that each thread that accesses one (via its * {@code get} or {@code set} method) has its own, independently initialized * copy of the variable.  {@code ThreadLocal} instances are typically private * static fields in classes that wish to associate state with a thread (e.g., * a user ID or Transaction ID).
复制代码
  • 我们从 get 方法切入去看一看原理

    public T get() {        Thread t = Thread.currentThread();      //可以看出存储结构类似一个map        ThreadLocalMap map = getMap(t);        if (map != null) {          //也是通过hash获取key,不过具体算法与HashMap有些差异,          //既然是hash,那么就要处理哈希冲突,HasjMap我们都知道是通过链式去处理的,          //而ThreadLocal是通过开放地址法的,因为作者Josh Bloch and Doug Lea认为线程变量中并不会存放太多entry          //所以使用开放地址法,一来设计更加简单,二来节约空间。不过开放地址也有自己的缺点比如删除之后需要移动entry            ThreadLocalMap.Entry e = map.getEntry(this);            if (e != null) {                @SuppressWarnings("unchecked")                T result = (T)e.value;                return result;            }        }        return setInitialValue();    }//map结构存储在Thread对象中,也就是为什么也叫做线程变量    ThreadLocalMap getMap(Thread t) {        return t.threadLocals;    }
复制代码
  • 再看看 map 具体的内部构造

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. */ //entry的对象,存储kv结构 static class Entry extends WeakReference<ThreadLocal<?>> { /** The value associated with this ThreadLocal. */ Object value;
Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } }
/** * The initial capacity -- MUST be a power of two. */ private static final int INITIAL_CAPACITY = 16;
/** * The table, resized as necessary. * table.length MUST always be a power of two. */ //使用数组存储entry private Entry[] table;
复制代码
  • 为了下文做铺垫,我们来看看 ThreadLocal 是怎么做资源回收的。

  • 首先 Entry 继承了 WeakReference

  • 其次 set 的时候也有清理的逻辑,来看一下 map 的 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; //计算index的哈希值 int i = key.threadLocalHashCode & (len-1);//遍历table,条件是Entry对象非空,也就是说,第一次插入的话,一定都是null for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) { ThreadLocal<?> k = e.get();//key相等则替换 if (k == key) { e.value = value; return; }//key是空,这里就是清理的逻辑,一般来说不会走到这里,因为Threadlocal在remove的时候,//不仅会设置entry的为空,也会设置table对应的元素为空,还会做entry的移动。//这里应该就是为了处理没有调用remove,但是ThreadLocal对象空了的异常情况,大部分情况是gc导致的,//因为entry的key是WeakReference if (k == null) { replaceStaleEntry(key, value, i); return; } }//没有找到替换值,或者key空的情况,正常插入 tab[i] = new Entry(key, value); int sz = ++size; //清理table,从i开始,长度就是table的大小,处理的就是entry非空,key(ThreadLocal)为空的情况,与 //replaceStaleEntry类似 if (!cleanSomeSlots(i, sz) && sz >= threshold) rehash(); }
复制代码
  • 上面说到的资源回收,细心的读者会发现,当我们没有手动调用 remove,也没有调用 set 的话,那么就不会触发清理的操作,如果有大量这种情况,那么 table 中就会有大量 entry 的可以是空(gc 了),value 还没有被清理的情况。

FastThreadLocal 来啦

  • 跟 ThreadLocal 一样,我们先来看看 javadoc。首先是说提供了更高的查询性能(一波自吹),然后就是关键拉,用了一个常量 index 取代了原来的哈希值去检索变量。为了最大化的发挥 ThreadLocal 的优势,建议线程使用 FastThreadLocalThread,因为可以避免走回 ThreadLocal 的逻辑。

 * A special variant of {@link ThreadLocal} that yields higher access performance when accessed from a * {@link FastThreadLocalThread}. * <p> * Internally, a {@link FastThreadLocal} uses a constant index in an array, instead of using hash code and hash table, * to look for a variable.  Although seemingly very subtle, it yields slight performance advantage over using a hash * table, and it is useful when accessed frequently. * </p><p> * To take advantage of this thread-local variable, your thread must be a {@link FastThreadLocalThread} or its subtype. * By default, all threads created by {@link DefaultThreadFactory} are {@link FastThreadLocalThread} due to this reason. * </p><p> * Note that the fast path is only possible on threads that extend {@link FastThreadLocalThread}, because it requires * a special field to store the necessary state.  An access by any other kind of thread falls back to a regular * {@link ThreadLocal}. * </p>
复制代码
  • 先看看这个常量 index。构造中就初始化了。底层通过 io.netty.util.internal.UnpaddedInternalThreadLocalMap#nextIndex,一个 AtomicInteger 去分配。通过 get,set 都是使用这个 index 去操作 io.netty.util.internal.UnpaddedInternalThreadLocalMap#indexedVariables。是一个 Object[]的结构,使用数组检索元素,效率确实高

    public FastThreadLocal() {        index = InternalThreadLocalMap.nextVariableIndex();    }
复制代码
  • 那么再来看看为啥说要配合使用 FastThreadLocalThread,才能快起来?set 方法为例

    /**     * Set the value for the current thread.     */    public final void set(V value) {        if (value != InternalThreadLocalMap.UNSET) {            InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.get();            setKnownNotUnset(threadLocalMap, value);        } else {            remove();        }    }//io.netty.util.internal.InternalThreadLocalMap的方法    public static InternalThreadLocalMap get() {        Thread thread = Thread.currentThread();        if (thread instanceof FastThreadLocalThread) {          //快速获取,因为FastThreadLocalThread内部就有InternalThreadLocalMap的成员变量            return fastGet((FastThreadLocalThread) thread);        } else {          //走回ThreadLocal,通过io.netty.util.internal.UnpaddedInternalThreadLocalMap#slowThreadLocalMap去获取          //这个变量就是一个ThreadLocal,也就是说netty兼容非FastThreadLocalThread的处理方式就是          //把自己fast模式下需要使用的InternalThreadLocalMap变量,使用ThreadLocal作为存储媒介,相当于做了一下中转          //其实总结一下就是如果不使用FastThreadLocalThread,那么完全多此一举            return slowGet();        }    }    /**     * @return see {@link InternalThreadLocalMap#setIndexedVariable(int, Object)}.     */    private void setKnownNotUnset(InternalThreadLocalMap threadLocalMap, V value) {      //直接数组赋值        if (threadLocalMap.setIndexedVariable(index, value)) {            addToVariablesToRemove(threadLocalMap, this);        }    }//这里就是netty的清理逻辑拉,variablesToRemoveIndex这个index跟之前说的常量index类似,他是在实例初始化的时候初始化的//对象是一个Set<FastThreadLocal<?>>。用来存放需要被清理的FastThreadLocal的对象,每次set都会加入这个set//用set方便去重,因为一个FastThreadLocal多次set就会加入多次    private static void addToVariablesToRemove(InternalThreadLocalMap threadLocalMap, FastThreadLocal<?> variable) {        Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);        Set<FastThreadLocal<?>> variablesToRemove;        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); }
复制代码

上面已经说到了清理部分的逻辑,提到了待清理的 FastThreadLocal 集合,那么这个集合什么时候被清理的呢?

  • 来看可以看 usage

  • removeAll。先看看 javadoc,清理当前线程变量中的所有 FastThreadLocal。再来看看源码。

    /**     * 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 threadLocalMap = InternalThreadLocalMap.getIfSet();        if (threadLocalMap == null) {            return;        }
try { //获取待清理的FastThreadLocal set Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex); if (v != null && v != InternalThreadLocalMap.UNSET) { @SuppressWarnings("unchecked") Set<FastThreadLocal<?>> variablesToRemove = (Set<FastThreadLocal<?>>) v; FastThreadLocal<?>[] variablesToRemoveArray = variablesToRemove.toArray(new FastThreadLocal[0]); //遍历remove for (FastThreadLocal<?> tlv: variablesToRemoveArray) { tlv.remove(threadLocalMap); } } } finally { 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; }//删除线程变量 Object v = threadLocalMap.removeIndexedVariable(index); //把自己从待清理的FastThreadLocal set中移除 removeFromVariablesToRemove(threadLocalMap, this);
if (v != InternalThreadLocalMap.UNSET) { try { //子类实现 onRemoval((V) v); } catch (Exception e) { PlatformDependent.throwException(e); } } }
复制代码
  • 之前提过的添加到 set 的逻辑

  • io.netty.util.concurrent.FastThreadLocal#remove(io.netty.util.internal.InternalThreadLocalMap)中使用,用于把自己从待清理的 FastThreadLocal set 中移除,因为已经清理过了

  • 关于清理,这里我们对比一下跟 jdk 原生的区别,很明显,netty 提供了 removeAll 去处理线程绑定的所有线程变量。背后的语义,就是 netty 关注线程对象销毁之后,绑定的线程变量有没有被即使清理,而不会去造成内存溢出。但是这里也可也可以看出,netty 的方式也需要手动维护,那为什么不使用自动化的方式呢?

  • netty 在 4.1.27.Final 之前的版本使用了一个 ObjectCleaner 的对象。这个对象依旧被保留了,但是原先使用 ObjectCleaner 去清理线程变量的逻辑被注释了,并最终在 netty-4.1.35.Final 中被删除。简单提一下之前的思路,在 set 方法中会注册一个 Cleaner 线程。原理就是利用 AutomaticCleanerReference 的父类构造 java.lang.ref.WeakReference#WeakReference(T, java.lang.ref.ReferenceQueue<? super T>)提供的语义,在 T 对象被销毁之后,会加入 ReferenceQueue。Cleaner 在第一次注册清理线程之后,会启动一个后台线程 CLEANER_TASK 去自旋从这个 ReferenceQueue 中获取对象,如果获取到了就会调用对象对应的清理线程(AutomaticCleanerReference 构造中传入)去执行清理逻辑

  • 那么为什么 netty 现在不用这个逻辑了呢?官网 issue 的大意就是 cleaner 线程无法被停止和控制,所以可能导致线程引用的变量泄漏

private void registerCleaner(final InternalThreadLocalMap threadLocalMap) {    Thread current = Thread.currentThread();    if (FastThreadLocalThread.willCleanupFastThreadLocals(current) ||	//线程是FastThreadLocalThread类型并且构造这个线程时传入了runnable        threadLocalMap.indexedVariable(cleanerFlagIndex) != InternalThreadLocalMap.UNSET) {	//已经注册过了        return;    }    // removeIndexedVariable(cleanerFlagIndex) isn't necessary because the finally cleanup is tied to the lifetime    // of the thread, and this Object will be discarded if the associated thread is GCed.    threadLocalMap.setIndexedVariable(cleanerFlagIndex, Boolean.TRUE);	//设置value,避免重复注册
// We will need to ensure we will trigger remove(InternalThreadLocalMap) so everything will be released // and FastThreadLocal.onRemoval(...) will be called.//即为 每个FastThreadLocal注册对象清理器,即线程销毁的时候,把线程的变量map清理掉 ObjectCleaner.register(current, new Runnable() { @Override public void run() { remove(threadLocalMap);
// It's fine to not call InternalThreadLocalMap.remove() here as this will only be triggered once // the Thread is collected by GC. In this case the ThreadLocal will be gone away already. } });}//后台线程private static final Runnable CLEANER_TASK = new Runnable() { @Override public void run() { boolean interrupted = false; for (;;) { //自旋条件,就是注册的AutomaticCleanerReference集合非空, //为什么官网说不可停止,就是因为这个set不对外暴露可以清理的方法,同时集合元素AutomaticCleanerReference也不对外暴露 // Keep on processing as long as the LIVE_SET is not empty and once it becomes empty // See if we can let this thread complete. while (!LIVE_SET.isEmpty()) { final AutomaticCleanerReference reference; try { //销毁队列中获取已经被销毁的对象 reference = (AutomaticCleanerReference) REFERENCE_QUEUE.remove(REFERENCE_QUEUE_POLL_TIMEOUT_MS); } catch (InterruptedException ex) { // Just consume and move on interrupted = true; continue; } if (reference != null) { try { //启动对象的清理线程 reference.cleanup(); } catch (Throwable ignored) { // ignore exceptions, and don't log in case the logger throws an exception, blocks, or has // other unexpected side effects. } LIVE_SET.remove(reference); } } CLEANER_RUNNING.set(false);
// Its important to first access the LIVE_SET and then CLEANER_RUNNING to ensure correct // behavior in multi-threaded environments. if (LIVE_SET.isEmpty() || !CLEANER_RUNNING.compareAndSet(false, true)) { // There was nothing added after we set STARTED to false or some other cleanup Thread // was started already so its safe to let this Thread complete now. break; } } if (interrupted) { // As we caught the InterruptedException above we should mark the Thread as interrupted. Thread.currentThread().interrupt(); } } };
复制代码



总结

本文从 jdk 原生 ThreadLocal 切入,介绍了为什么 FastThreadLocal 更快,FastThreadLocal 的清理逻辑做了什么优化,去避免线程变量的内存溢出。下一篇我们继续聊聊 netty 拉,再会!想念家宝~


参考资料

https://github.com/netty/netty/issues/8017

https://github.com/netty/netty/commit/9b1a59df383559bc568b891d73c7cb040019aca6#diff-e0eb4e9a6ea15564e4ddd076c55978de


用户头像

如果晴天

关注

非淡泊无以明志,非宁静无以致远 2021-04-24 加入

朴实无华的开发者,热爱思考,喜欢探究原理,学以致用,追求极致。

评论

发布
暂无评论
【源码分析】【netty】FastThreadLocal为什么快?_源码分析_如果晴天_InfoQ写作社区