【.NET8】访问私有成员新姿势UnsafeAccessor（下）

前言

书接上回，我们讨论了在.NET8中新增的UnsafeAccessor，并且通过UnsafeAccessor访问了私有成员，这极大的方便了我们代码的编写，当然也聊到了它当前存在的一些局限性，那么它的性能到底如何？我们今天就来实际测试一下。

测试代码

话不多说，直接上代码，本次测试代码如下：

using System.Linq.Expressions; using System.Reflection; using System.Reflection.Emit; using System.Runtime.CompilerServices; using BenchmarkDotNet.Attributes; using BenchmarkDotNet.Columns; using BenchmarkDotNet.Configs; using BenchmarkDotNet.Order; using BenchmarkDotNet.Reports; using BenchmarkDotNet.Running; using Perfolizer.Horology;  [MemoryDiagnoser] [Orderer(SummaryOrderPolicy.FastestToSlowest)] public class AccessBenchmarks {     public static readonly A TestInstance = new();     public static readonly Action<A, int> SetDelegate;     public static readonly Func<A, int> GetDelegate;     public static readonly PropertyInfo ValueProperty;     public static readonly MethodInfo SetValueMethod;     public static readonly MethodInfo GetValueMethod;      public static readonly Func<A, int> GetValueExpressionFunc;     public static readonly Action<A, int> SetValueExpressionAction;      static AccessBenchmarks()     {         TestInstance = new();         ValueProperty = typeof(A).GetProperty("Value");         SetValueMethod = ValueProperty.GetSetMethod();         GetValueMethod = ValueProperty.GetGetMethod();          SetDelegate = CreateSetDelegate();         GetDelegate = CreateGetDelegate();          GetValueExpressionFunc = CreateGetValueExpressionFunc();         SetValueExpressionAction = CreateSetValueExpressionAction();     }      [UnsafeAccessor(UnsafeAccessorKind.Method, Name = "get_Value")]     static extern int GetValueUnsafe(A a);      [UnsafeAccessor(UnsafeAccessorKind.Method, Name = "set_Value")]     static extern void SetValueUnsafe(A a, int value);      [Benchmark]     public void UnsafeAccessor()     {         SetValueUnsafe(TestInstance, 10);         var value = GetValueUnsafe(TestInstance);     }      [Benchmark]     public void Reflection()     {         SetValueMethod.Invoke(TestInstance, new object[] { 10 });         var value = GetValueMethod.Invoke(TestInstance, new object[] { });     }      [Benchmark]     public void Emit()     {         SetDelegate(TestInstance, 10);         var value = GetDelegate(TestInstance);     }      [Benchmark]     public void ExpressionTrees()     {         SetValueExpressionAction(TestInstance, 10);         var value = GetValueExpressionFunc(TestInstance);     }      [Benchmark]     public void Direct()     {         TestInstance.Value = 10;         var value = TestInstance.Value;     }      private static Action<A, int> CreateSetDelegate()     {         var dynamicMethod = new DynamicMethod("SetValue", null, new[] { typeof(A), typeof(int) }, typeof(A));         var ilGenerator = dynamicMethod.GetILGenerator();         ilGenerator.Emit(OpCodes.Ldarg_0);         ilGenerator.Emit(OpCodes.Ldarg_1);         ilGenerator.EmitCall(OpCodes.Call, SetValueMethod, null);         ilGenerator.Emit(OpCodes.Ret);         return (Action<A, int>)dynamicMethod.CreateDelegate(typeof(Action<A, int>));     }      private static Func<A, int> CreateGetDelegate()     {         var dynamicMethod = new DynamicMethod("GetValue", typeof(int), new[] { typeof(A) }, typeof(A));         var ilGenerator = dynamicMethod.GetILGenerator();         ilGenerator.Emit(OpCodes.Ldarg_0);         ilGenerator.EmitCall(OpCodes.Call, GetValueMethod, null);         ilGenerator.Emit(OpCodes.Ret);         return (Func<A, int>)dynamicMethod.CreateDelegate(typeof(Func<A, int>));     }      private static Func<A, int> CreateGetValueExpressionFunc()     {         var instance = Expression.Parameter(typeof(A), "instance");         var getValueExpression = Expression.Lambda<Func<A, int>>(             Expression.Property(instance, ValueProperty),             instance);          return getValueExpression.Compile();     }      private static Action<A, int> CreateSetValueExpressionAction()     {         var instance = Expression.Parameter(typeof(A), "instance");         var value = Expression.Parameter(typeof(int), "value");         var setValueExpression = Expression.Lambda<Action<A, int>>(             Expression.Call(instance, ValueProperty.GetSetMethod(true), value),             instance, value);          return setValueExpression.Compile();     } }  public class A {     public int Value { get; set; } }  public class Program {     public static void Main()     {         Console.WriteLine(AccessBenchmarks.TestInstance);         var summary = BenchmarkRunner.Run<AccessBenchmarks>(DefaultConfig.Instance.WithSummaryStyle(new SummaryStyle(             cultureInfo: null, // use default             printUnitsInHeader: true,             printUnitsInContent: true,             sizeUnit: SizeUnit.B,             timeUnit: TimeUnit.Nanosecond,             printZeroValuesInContent: true,             ratioStyle: RatioStyle.Trend // this will print the ratio column         )));     } } 

在测试代码中，我们使用了BenchmarkDotNet来进行测试，测试的内容包括：

• UnsafeAccessor：使用UnsafeAccessor特性来访问私有成员
• Reflection：使用反射访问私有成员
• Emit：使用Emit+动态方法访问私有成员
• ExpressionTrees：使用表达式树+委托来访问私有成员
• Direct：直接访问私有成员

测试结果如下图所示，可以看到使用UnsafeAccessor的性能是最好的，其次是直接访问私有成员，最差的是反射。这其实是出乎我的意料的，因为我认为它最多和直接访问私有成员的性能差不多，但是实际上它的性能比直接访问私有成员还要好，当然也有可能是统计的误差，0.0000ns这个尺度已经非常小了。

深入探究

看到这里我想大家都有很多疑问，实际上作者本人看到这里也是有很多的疑问，主要是这两个：

• 是什么原因让.NET社区想加入这个API？
• 它是如何做到访问私有成员的？
• 为什么性能会这么好？

新增功能的原因

如果要了解这个功能背后的东西，那么我们首先就要找到对应这个API的Issues，按照.NET社区的规范，所有的API都需要提交Issues，然后经过API Review，多轮讨论设计以后，才会开始开发。

首先我们定位到Issue是这一个，在Issue中我们可以了解到这个API主要是为了给System.Text.Json或EF Core这种需要访问私有成员的框架使用，因为目前它们都是基于Emit动态代码生成实现的，但是Emit不能在AOT中使用，现阶段只能使用慢速的反射API，所以迫切引入了一种零开销的私有成员访问机制。

https://github.com/dotnet/runtime/issues/86161

如何做到访问私有成员？

翻阅一下整个API提案Issue的讨论，我们可以找到具体实现的Issue，所以我们要了解它背后的原理的话，就需要跳转到对应的Issue。

在这里可以看到目前还没有做泛型的实现，非泛型的已经在下面链接中实现了，一个是为CoreCLR做的实现，另外一个是为Mono做的实现。

我们目前只关注CoreCLR，点开这个Issue。

https://github.com/dotnet/runtime/issues/86161

可以看到将这个任务拆成了几个部分，他们都在在一个PR中完成的，其中包括定义了UnsafeAccessor特性，在JIT中的实现，以及NativeAOT中进行了支持，另外编写了单元测试加入了有效的诊断方案。

那么来看看这个PR里面做了什么吧。

https://github.com/dotnet/runtime/pull/86932

由于PR非常的长，大家有兴趣可以点进去看看，低于8GB内存的小伙伴就要小心了。简单的来说这次修改主要就是两块地方，一块是JIT相关的修改，JIT这里主要是支持UnsafeAccessor和static extern int声明函数的用法，需要支持方法的IL Body为空，然后在JIT时根据特性为它插入代码。

首先我们来看JIT的处理，这块代码主要就是修改了jitinterface.cpp，可以看到它调用了TryGenerateUnsafeAccessor方法：

这个TryGenerateUnsafeAccessor方法实现在prestub.cpp中，这个prestub.cpp实现了一些预插桩的操作，TryGenerateUnsafeAccessor方法实现如下所示：

它针对UnsafeAccessorKind的不同枚举做了校验，防止出现运行时崩溃的情况：

然后调用了GenerateAccessor方法来生成IL：

在GenerateAccessor里面就是使用Emit进行代码生成：

所以从JIT的实现来看，它其实核心原理就是Emit代码生成，并没有太多特殊的东西。

另外是关于NativeAOT的实现，首先修改了NativeAotILProvider.cs这个类，这个类的主要作用就是在进行NativeAot的时候提供IL给JIT预先编译使用：

关键也是在GenerateAccessor方法里面，在这里生成了对应的IL代码：

总结一下，UnsafeAccessor实现原理还是使用的IL动态生成技术，只不过它是在JIT内部实现的。

为什么性能这么好？

那么它为什么性能要比我们在C#代码中自己写Emit要更好呢？其实原因也是显而易见的，我们自己编写的Emit代码中间有一层DynamicMethod的委托调用，增加了开销，而UnsafeAccessor它直接就是一个static extern int GetValueUnsafe(A a);方法，没有中间开销，而且它IL Body很小，可以被内联。

总结

通过对.NET8中新增的UnsafeAccessor特性的深入探究，我们得到了一些启示和理解。首先，UnsafeAccessor的引入并非无中生有，而是应运而生，它是为了满足System.Text.Json或EF Core这类框架在访问私有成员时的需求，因为它们目前大多基于Emit动态代码生成实现，但在AOT环境中无法使用Emit，只能依赖于效率较低的反射API。因此，UnsafeAccessor的引入，为我们提供了一种零开销的私有成员访问机制。

总的来说，UnsafeAccessor的引入无疑为.NET的发展增添了一抹亮色，它不仅提升了代码的执行效率，也为我们的编程方式提供了新的可能。我们期待在未来的.NET版本中，看到更多这样的创新和突破。