前言

原文地址:.NET8极致性能优化-线程

首先来看下，为什么性能会一直持续性优化。.NET8引入的SSE-XMM(16字节)Register和AVX-YMM(32字节)Register是关键，传统的Register一般指令集层次能移动的最多只有8位，就算是最新的x64系统。但是SSE和AVX改变了这种局面，它们能一次性移动64位系统的一倍乃至四倍，这就是优化的关键。

前面本公众号(jianghupt)多篇文章，展示了很多.NET8的性能优化，基本上都是核心级的CLR/JIT优化，包括了VM，Zeroing，CHRL，Exception，Non_GC，Branch，GC，Reflection，AOT，Enum，DateTime等等。但是漏掉了一个较为重要的东西：线程。本篇来看下.NET8里面的线程优化。

公众号:江湖评谈(jianghupt),扫一扫关注。

ThreadStatic

.NET在新的版本中，对线程，并发，并行，异步等方面做出了非常大的改进。比如ThreadPool完全重写，异步方法基础部分的完全重写，ConcurrentQueue队列的完全重写等等。.NET8在这些的基础上，进行了更为深思熟虑的和更为有影响力的改进。比如ThreadStatic。

.NET运行时里面运用本地数据和线程的关联，就是本地线程存储(TLS)。在托管代码上实现这一点，最常用的方法就是用[ThreadStatic]属性注解一个静态字段(当然这里还有个用途更高级的ThreadLocal),这样就会导致.NET运行时会把这个静态字段的存储复制到每个线程，而不是全局的进程上面。

例如以下ThreadStaitc属性注解的用法

private static int s_onePerProcess;
[ThreadStatic]private static int t_onePerThread;

在.NET8之前访问被TheadStatic标记的字段，需要一个JIT的非内联辅助方法CORINFO_HELP_GETSHARED_NONGCTHREADSTATIC_BASE_NOCTOR。它的原型实际上就是JIT_GetSharedNonGCThreadStaticBase。如下:​​​​​​​

#include HCIMPL2(void*, JIT_GetSharedNonGCThreadStaticBase, DomainLocalModule *pDomainLocalModule, DWORD dwClassDomainID){//为了便于观看，此处省略    return HCCALL1(JIT_GetNonGCThreadStaticBase_Helper, pMT);}HCIMPLEND

因为这个方法本身是有优化空间的，经过dotnet/runtime#82973 and dotnet/runtime#85619它的函数本体被内联到了调用者当中了。省略了函数调用以及跳转的成本。通过一个基准测试来看下这个效果。​​​​​​​

// dotnet run -c Release -f net7.0 --filter "*" --runtimes ne服务器托管网t7.0 net8.0//dotnetrun-cRelease-fnet7.0--filter"*"--runtimesnativeaot7.0nativeaot8.0using BenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;BenchmarkSwitcher.FromAssembly(typeof(Tests).Assembly).Run(args);[HideColumns("Error", "StdDev", "Median", "RatioSD")]public partial class Tests{    [ThreadStatic]    private static int t_value;
    [Benchmark]    pub服务器托管网lic int Increment() => ++t_value;}

测试结果如下，提升明显：

方法	运行时	平均值	比率
Increment	.NET 7.0	8.492 ns	1.00
Increment	.NET 8.0	1.453 ns	0.17

同样的通过

dotnet/runtime#84566 和 dotnet/runtime#87148为.NET AOT做的一个优化，提升同样明显。

方法	运行时	平均值	比率
Increment	NativeAOT 7.0	2.305 ns	1.00
Increment	NativeAOT 8.0	1.325 ns	0.57

ThreadPool

TheadPool优化在于线程池方面，之前老版本的.NET基本上都是通过封装Windows线程池，然后通过托管代码调用。但是在.NET6里面开始.NET运行时实现了自己的托管线程池，也就是说新版的.NET包含了两个线程池。分别为托管调用的windows线程池，以及托管代码自己实现的托管线程池。现在，在.NET8里面可以自由切换这两个线程池，你想使用哪个就用哪个，以提升程序的性能。

我们来看下，这个过程。首先新建一个.NET8.0控制台应用程序，代码如下​​​​​​​

static void Main(string[] args){    Task.Run(() => Console.WriteLine(Environment.StackTrace)).Wait();Console.ReadLine();}

并在 .csproj 中添加true。先运行下它，结果显示如下：​​​​​​​

at System.Environment.get_StackTrace()at ThreadPool_.Program.c.
b__0_0() in E:Visual Studio ProjectTest_ThreadPool_Program.cs:line 7at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)at System.Threading.ThreadPoolWorkQueue.Dispatch()at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()

PortableThreadPool这个就是.NET6以来新增的托管线程池操控的代码。我们下面再来看下Windows线程池方面，把上面代码进行AOT编译

dotnet publish -c Release -r win-x64

我们运行下路径binReleasenet8.0win-x64publish里的exe文件，可以看到如下：​​​​​​​

at System.Environment.get_StackTrace() + 0x21at ThreadPool_.Program.c.
b__0_0() + 0x9at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread, ExecutionContext, ContextCallback, Object) + 0x3dat System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task&, Thread) + 0xccat System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x289at System.Threading.WindowsThreadPool.DispatchCallback(IntPtr, IntPtr, IntPtr) + 0x45

很明显的看到这里是WindowsThreadPool(Windows线程池调用)，而上面的则是PortableThreadPool(.NET运行时自己实现的托管线程池)。这里有个疑问，为什么AOT可以看到Windows线程池，因为AOT是本地预编译机器码，它不包含托管代码，所以只能Windows自带线程池调用。但是如果是托管代码，不是AOT化，那么可以看到原汁原味的托管线程池调用。

通过issuse:dotnet/runtime#85373，Windows上运行的.NET8应用程序可以选择任何一个线程池。

可以在 .csproj 中的中，添加 ：

false

false表示不使用Windows线程池，True表示使用。其它的，也可以设置环境变量，来使用Windows线程池，设置0则不使用。

DOTNET_ThreadPool_UseWindowsThreadPool=1

目前来说，没有确切的证据证明哪个线程池好用，或者效率更高。但是开发者可以使用上面的选项来进行自己的选择，有一个测试就是在Windows线程池在比较大的机器上的IO扩展性不太好。如果你的应用程序已经大量的使用了Windows线程池，那么可以通过以上设置为另一个线程池操作也是可以的。此外，线程池经常被阻塞，Windows线程池对此有更多的处理，也能更有效的比托管线程处理的更好。如以下代码：​​​​​​​

// dotnet run -c Release -f net8.0
usingSystem.Diagnostics;varsw=Stopwatch.StartNew();var barrier = new Barrier(Environment.ProcessorCount * 2 + 1);for (int i = 0; i {    ThreadPool.QueueUserWorkItem(id =>    {        Console.WriteLine($"{sw.Elapsed}: {id}");        barrier.SignalAndWait();    }, i);}
barrier.SignalAndWait();Console.WriteLine($"Done:{sw.Elapsed}");

以上创建了很多工作项，所有的工作项都会被阻塞，直到所有工作项都被处理完毕。这里可以设置DOTNET_ThreadPool_UseWindowsThreadPool 为 1。看下对比的结果，显示Windows线程池处理的更好。

感兴趣的话，也可以来知识星球看看。

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: Guava Preconditions类的各种用法

公众号「架构成长指南」，专注于生产实践、云原生、分布式系统、大数据技术分享。 Guava Preconditions类 提供静态方法列表，用于检查是否使用有效参数值调用方法或构造函数。如果前提条件失败，则会抛出指定的异常。 前置依赖 引入 pom com.go…