登录/ 注册
 找回密码
 立即注册
关闭

CSDN热搜

程序园 精品问答 技术交流 资源下载
返回列表 发新帖
首页 › 业界区 › 业界 ›优化反射性能的总结（上）

优化反射性能的总结（上）

钤凑讪 2025-5-29 16:29:11
反射是一种很重要的技术，然而它与直接调用相比性能要慢很多，因此如何优化反射性能也就成为一个不得不面对的问题。目前最常见的优化反射性能的方法就是采用委托：用委托的方式调用需要反射调用的方法（或者属性、字段）。
那么如何得到委托呢？ 目前最常见也就是二种方法：Emit, ExpressionTree 。其中ExpressionTree可认为是Emit方法的简化版本，所以Emit是最根本的方法，它采用在运行时动态构造一段IL代码来包装需要反射调用的代码，这段动态生成的代码满足某个委托的签名，因此最后可以采用委托的方式代替反射调用。
用Emit方法优化反射

如果我们需要设计自己的数据访问层，那么就需要动态创建所有的数据实体对象，尤其是还要为每个数据实体对象的属性赋值，这里就要涉及用反射的方法对属性执行写操作，为了优化这种反射场景的性能，我们可以用下面的方法来实现：
  1. public delegate void SetValueDelegate(object target, object arg);
  3. public static class DynamicMethodFactory
  4. {
  5.     public static SetValueDelegate CreatePropertySetter(PropertyInfo property)
  6.     {
  7.         if( property == null )
  8.             throw new ArgumentNullException("property");
  10.         if( !property.CanWrite )
  11.             return null;
  13.         MethodInfo setMethod = property.GetSetMethod(true);
  15.         DynamicMethod dm = new DynamicMethod("PropertySetter", null,
  16.             new Type[] { typeof(object), typeof(object) },
  17.             property.DeclaringType, true);
  19.         ILGenerator il = dm.GetILGenerator();
  21.         if( !setMethod.IsStatic ) {
  22.             il.Emit(OpCodes.Ldarg_0);
  23.         }
  24.         il.Emit(OpCodes.Ldarg_1);
  26.         EmitCastToReference(il, property.PropertyType);
  27.         if( !setMethod.IsStatic && !property.DeclaringType.IsValueType ) {
  28.             il.EmitCall(OpCodes.Callvirt, setMethod, null);
  29.         }
  30.         else
  31.             il.EmitCall(OpCodes.Call, setMethod, null);
  33.         il.Emit(OpCodes.Ret);
  35.         return (SetValueDelegate)dm.CreateDelegate(typeof(SetValueDelegate));
  36.     }
  37.    
  38.     private static void EmitCastToReference(ILGenerator il, Type type)
  39.     {
  40.         if( type.IsValueType )
  41.             il.Emit(OpCodes.Unbox_Any, type);
  42.         else
  43.             il.Emit(OpCodes.Castclass, type);
  44.     }
  45. }
复制代码
现在可以用下面的测试代码检验委托调用带来的性能改进：
  1. Console.WriteLine(System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion());
  3. int count = 1000000;
  5. OrderInfo testObj = new OrderInfo();
  6. PropertyInfo propInfo = typeof(OrderInfo).GetProperty("OrderID");
  8. Console.Write("直接访问花费时间：       ");
  9. Stopwatch watch1 = Stopwatch.StartNew();
  11. for( int i = 0; i < count; i++ )
  12.     testObj.OrderID = 123;
  14. watch1.Stop();
  15. Console.WriteLine(watch1.Elapsed.ToString());
  18. SetValueDelegate setter2 = DynamicMethodFactory.CreatePropertySetter(propInfo);
  19. Console.Write("EmitSet花费时间：        ");
  20. Stopwatch watch2 = Stopwatch.StartNew();
  22. for( int i = 0; i < count; i++ )
  23.     setter2(testObj, 123);
  25. watch2.Stop();
  26. Console.WriteLine(watch2.Elapsed.ToString());
  29. Console.Write("纯反射花费时间：　       ");
  30. Stopwatch watch3 = Stopwatch.StartNew();
  32. for( int i = 0; i < count; i++ )
  33.     propInfo.SetValue(testObj, 123, null);
  35. watch3.Stop();
  36. Console.WriteLine(watch3.Elapsed.ToString());
  39. Console.WriteLine("-------------------");
  40. Console.WriteLine("{0} / {1} = {2}",
  41.     watch3.Elapsed.ToString(),
  42.     watch1.Elapsed.ToString(),
  43.     watch3.Elapsed.TotalMilliseconds / watch1.Elapsed.TotalMilliseconds);
  45. Console.WriteLine("{0} / {1} = {2}",
  46.     watch3.Elapsed.ToString(),
  47.     watch2.Elapsed.ToString(),
  48.     watch3.Elapsed.TotalMilliseconds / watch2.Elapsed.TotalMilliseconds);
  50. Console.WriteLine("{0} / {1} = {2}",
  51.     watch2.Elapsed.ToString(),
  52.     watch1.Elapsed.ToString(),
  53.     watch2.Elapsed.TotalMilliseconds / watch1.Elapsed.TotalMilliseconds);
复制代码
我用VS2008 (.net 3.5 , CLR 2.0) 测试可以得到以下结果：
1.png

从结果可以看出：
1. 反射调用所花时间是直接调用的2629倍，
2. 反射调用所花时间是Emit生成的Set委托代码的82倍，
3. 运行Emit生成的Set委托代码所花时间是直接调用的31倍。
虽然Emit比直接调用还有30倍的差距，但还是比反射调用快80倍左右。

有意思的是，同样的代码，如果用VS2012 ( .net 4.5 , CLR 4.0) 测试可以得到以下结果：
2.png

感谢zhangweiwen在博客中展示了CRL 4.0对反射的性能改进，在他的博客中还提供了一种采用表达式树的优化版本，以及包含一个泛型的强类型的版本。
Delegate.CreateDelegate也能创建委托

如果我们观察CreatePropertySetter的实现代码，发现这个方法的本质就是创建一个委托：
  1. public static SetValueDelegate CreatePropertySetter(PropertyInfo property)
  2. {
  3.     // ..... 省略前面已贴过的代码
  4.     return (SetValueDelegate)dm.CreateDelegate(typeof(SetValueDelegate));
  5. }
复制代码
看到这里，让我想起Delegate.CreateDelegate方法也能创建一个委托，例如：
  1. OrderInfo testObj = new OrderInfo();
  2. PropertyInfo propInfo = typeof(OrderInfo).GetProperty("OrderID");
  4. Action<OrderInfo, int> setter = (Action<OrderInfo, int>)Delegate.CreateDelegate(
  5.     typeof(Action<OrderInfo, int>), null, propInfo.GetSetMethod());
  7. setter(testObj, 123);
复制代码
显然，这是一种很直观的方法，可以得到一个强类型的委托。
然而，这种方法仅限有一种适用场景：明确知道要访问某个类型的某个属性或者方法，因为我们要提供类型参数。例如：我要写个关键字过滤的HttpMoudle，它需要修改HttpRequest.Form对象的IsReadOnly属性，由于IsReadOnly在NameObjectCollectionBase类型中已申明为protected访问级别，所以我只能反射操作它了，而且还需要很频繁的设置它。
在绝大部分反射场景中，例如数据访问层中从DataReader或者DataRow加载数据实体，我们不可能事先知道要加载哪些类型，更不可能知道要加载哪些数据成员，因此就不可能给泛型委托的类型参数赋值，这个方法看起来也就行不通了。

如果您不信的话，可以看下面修改后的代码：
  1. OrderInfo testObj = new OrderInfo();
  2. PropertyInfo propInfo = typeof(OrderInfo).GetProperty("OrderID");
  4. //Action<OrderInfo, int> setter = (Action<OrderInfo, int>)Delegate.CreateDelegate(
  5. //    typeof(Action<OrderInfo, int>), null, propInfo.GetSetMethod());
  7. Action<object, object> setter = (Action<object, object>)Delegate.CreateDelegate(
  8.     typeof(Action<object, object>), null, propInfo.GetSetMethod());
  10. setter(testObj, 123);
  12. Console.WriteLine(testObj.OrderID);
复制代码
虽然能通过编译，但会在运行时报错：
3.png

在很多时候，我们只能在运行时得到以Type对象表示的类型，接受object类型才是通用的解决方案。然而，前面的代码证明了我们不能简单将委托类型从Action修改为Action 。

真的没有办法了吗？
虽然Emit已是很成熟的优化方案，可我还是希望试试 Delegate.CreateDelegate ！
用Delegate.CreateDelegate优化反射

当我们用Delegate.CreateDelegate从一个MethodInfo对象创建委托时，委托的签名必须和MethodInfo表示的方法签名相匹配（有可能不一致），所以这种方法得到的委托注定是一种强类型的委托。现在的问题是：我们在运行时构造与指定MethodInfo匹配的委托，如何将Type对象转换成泛型委托的类型参数？
为了解决这个问题，我采用了泛型类来解决泛型委托的类型参数问题：
  1. public class SetterWrapper<TTarget, TValue>
  2. {
  3.     private Action<TTarget, TValue> _setter;
  5.     public SetterWrapper(PropertyInfo propertyInfo)
  6.     {
  7.         if( propertyInfo == null )
  8.             throw new ArgumentNullException("propertyInfo");
  10.         if( propertyInfo.CanWrite == false )
  11.             throw new NotSupportedException("属性不支持写操作。");
  13.         MethodInfo m = propertyInfo.GetSetMethod(true);
  14.         _setter = (Action<TTarget, TValue>)Delegate.CreateDelegate(typeof(Action<TTarget, TValue>), null, m);
  15.     }
  16.    
  17.     public void SetValue(TTarget target, TValue val)
  18.     {
  19.         _setter(target, val);
  20.     }
复制代码
我用泛型类把Delegate.CreateDelegate的问题解决了，但是如何创建这个类型的实例呢？
可以用Type.MakeGenericType()方法来解决：
  1. public static object CreatePropertySetterWrapper(PropertyInfo propertyInfo)
  2. {
  3.     if( propertyInfo == null )
  4.         throw new ArgumentNullException("propertyInfo");
  5.     if( propertyInfo.CanWrite == false )
  6.         throw new NotSupportedException("属性不支持写操作。");
  8.     MethodInfo mi = propertyInfo.GetSetMethod(true);
  10.     if( mi.GetParameters().Length > 1 )
  11.         throw new NotSupportedException("不支持构造索引器属性的委托。");
  13.     Type instanceType = typeof(SetterWrapper<,>).MakeGenericType(propertyInfo.DeclaringType, propertyInfo.PropertyType);
  14.     return Activator.CreateInstance(instanceType, propertyInfo);
  15. }
复制代码
现在问题并没有结束，我又如何调用那些泛型类型实例的委托呢？
这里还有另一个问题要解决：调用方法需要支持object类型（满足通用性）。
我想到了定义一个接口来解决：
  1. public interface ISetValue
  2. {
  3.     void Set(object target, object val);
  4. }
复制代码
然后让SetterWrapper实现ISetValue接口：
  1. public class SetterWrapper<TTarget, TValue> : ISetValue
  2. {
  3.     // ..... 省略前面已贴过的代码
  5.     void ISetValue.Set(object target, object val)
  6.     {
  7.         _setter((TTarget)target, (TValue)val);
  8.     }
  9. }
复制代码
还有前面的CreatePropertySetterWrapper方法也需要再次调整返回值类型：
  1. public static ISetValue CreatePropertySetterWrapper(PropertyInfo propertyInfo)
  2. {
  3.     // ..... 省略前面已贴过的代码
  4.     return (ISetValue)Activator.CreateInstance(instanceType, propertyInfo);
  5. }
复制代码
考虑到有些特定场景下需要用反射的方式重复操作某一个属性，使用强类型的方法可以避免拆箱装箱，
所以我保留了前面的SetValue方法，让它提供更好的性能，满足一些特定场景的需要。
因此，现在的SetterWrapper类型有二种使用方法，可以提供二种性能不同的实现方法。
现在可以增加二段测试代码来测试它的性能了：
  1. Console.Write("泛型委托花费时间：       ");
  2. SetterWrapper<OrderInfo, int> setter3 = new SetterWrapper<OrderInfo, int>(propInfo);
  3. Stopwatch watch4 = Stopwatch.StartNew();
  5. for( int i = 0; i < count; i++ )
  6.     setter3.SetValue(testObj, 123);
  8. watch4.Stop();
  9. Console.WriteLine(watch4.Elapsed.ToString());
  12. Console.Write("通用接口花费时间：       ");
  13. ISetValue setter4 = GetterSetterFactory.CreatePropertySetterWrapper(propInfo);
  14. Stopwatch watch5 = Stopwatch.StartNew();
  16. for( int i = 0; i < count; i++ )
  17.     setter4.Set(testObj, 123);
  19. watch5.Stop();
  20. Console.WriteLine(watch5.Elapsed.ToString());
复制代码
测试结果如下：
4.png

测试结果表明：强类型的泛型委托的速度比Emit生成的Set委托要快，但是基于通用接口的方法调用由于多了一层包装就比Emit方案要略慢一点。
完整的属性优化方案

前面介绍了为属性赋值这类反射案例的优化方案，那么怎么优化读取属性的反射操作呢？
其实思路差不多：
1. 在泛型类中调用Delegate.CreateDelegate，得到一个Func,
2. 定义一个IGetValue接口，提供一个方法： object Get(object target);
3. 让泛型类实现IGetValue接口
4. 提供一个工厂方法实例化泛型类的实例。
相关代码如下：
  1. public interface IGetValue
  2. {
  3.     object Get(object target);
  4. }
  6. public static class GetterSetterFactory
  7. {
  8.     public static IGetValue CreatePropertyGetterWrapper(PropertyInfo propertyInfo)
  9.     {
  10.         if( propertyInfo == null )
  11.             throw new ArgumentNullException("propertyInfo");
  12.         if( propertyInfo.CanRead == false )
  13.             throw new InvalidOperationException("属性不支持读操作。");
  15.         MethodInfo mi = propertyInfo.GetGetMethod(true);
  17.         if( mi.GetParameters().Length > 0 )
  18.             throw new NotSupportedException("不支持构造索引器属性的委托。");
  19.         
  20.         Type instanceType = typeof(GetterWrapper<,>).MakeGenericType(propertyInfo.DeclaringType, propertyInfo.PropertyType);
  21.         return (IGetValue)Activator.CreateInstance(instanceType, propertyInfo);
  22.     }
  23. }
  25. public class GetterWrapper<TTarget, TValue> : IGetValue
  26. {
  27.     private Func<TTarget, TValue> _getter;
  29.     public GetterWrapper(PropertyInfo propertyInfo)
  30.     {
  31.         if( propertyInfo == null )
  32.             throw new ArgumentNullException("propertyInfo");
  34.         if( propertyInfo.CanRead == false )
  35.             throw new InvalidOperationException("属性不支持读操作。");
  37.         MethodInfo m = propertyInfo.GetGetMethod(true);
  38.         _getter = (Func<TTarget, TValue>)Delegate.CreateDelegate(typeof(Func<TTarget, TValue>), null, m);
  39.     }
  40.    
  41.     public TValue GetValue(TTarget target)
  42.     {
  43.         return _getter(target);
  44.     }
  45.     object IGetValue.Get(object target)
  46.     {
  47.         return _getter((TTarget)target);
  48.     }
  49. }
复制代码
前面的代码优化了实例属性的反射读写性能问题，但是还有极少数时候我们还需要处理静态属性，那么我们还需要再定义二个泛型类来解决：
  1. public class StaticGetterWrapper<TValue> : IGetValue
  2. {
  3.     private Func<TValue> _getter;
  5.     // ............
  6. }
  8. public class StaticSetterWrapper<TValue> : ISetValue
  9. {
  10.     private Action<TValue> _setter;
  12.     // ............
  13. }
复制代码
前面看到的工厂方法也要调整，完整代码如下：
  1. public static ISetValue CreatePropertySetterWrapper(PropertyInfo propertyInfo)
  2. {
  3.     if( propertyInfo == null )
  4.         throw new ArgumentNullException("propertyInfo");
  5.     if( propertyInfo.CanWrite == false )
  6.         throw new NotSupportedException("属性不支持写操作。");
  8.     MethodInfo mi = propertyInfo.GetSetMethod(true);
  10.     if( mi.GetParameters().Length > 1 )
  11.         throw new NotSupportedException("不支持构造索引器属性的委托。");
  13.     if( mi.IsStatic ) {
  14.         Type instanceType = typeof(StaticSetterWrapper<>).MakeGenericType(propertyInfo.PropertyType);
  15.         return (ISetValue)Activator.CreateInstance(instanceType, propertyInfo);
  16.     }
  17.     else {
  18.         Type instanceType = typeof(SetterWrapper<,>).MakeGenericType(propertyInfo.DeclaringType, propertyInfo.PropertyType);
  19.         return (ISetValue)Activator.CreateInstance(instanceType, propertyInfo);
  20.     }
  21. }
复制代码
委托方案的后续问题

前面的代码解决了属性的读写问题，然而使用它们还很不方便：每次都要创建一个ISetValue接口的实例，再调用它的方法。其实这也是委托方案共有的问题：我们需要为每个属性的读写操作分别创建不同的委托，而且委托太零散了。
如何将属性与创建好的委托关联起来呢？（创建委托也是需要时间的）
我想所有人都会想到用字典来保存。
是的，好像也只有这一种方法了。
为了提高性能，我改进了工厂类，缓存了包含委托的实例，
为了方便使用前面的方法，我提供了一些扩展方法：
  1. public static class GetterSetterFactory
  2. {
  3.     private static readonly Hashtable s_getterDict = Hashtable.Synchronized(new Hashtable(10240));
  4.     private static readonly Hashtable s_setterDict = Hashtable.Synchronized(new Hashtable(10240));
  6.     internal static IGetValue GetPropertyGetterWrapper(PropertyInfo propertyInfo)
  7.     {
  8.         IGetValue property = (IGetValue)s_getterDict[propertyInfo];
  9.         if( property == null ) {
  10.             property = CreatePropertyGetterWrapper(propertyInfo);
  11.             s_getterDict[propertyInfo] = property;
  12.         }
  13.         return property;
  14.     }
  16.     internal static ISetValue GetPropertySetterWrapper(PropertyInfo propertyInfo)
  17.     {
  18.         ISetValue property = (ISetValue)s_setterDict[propertyInfo];
  19.         if( property == null ) {
  20.             property = CreatePropertySetterWrapper(propertyInfo);
  21.             s_setterDict[propertyInfo] = property;
  22.         }
  23.         return property;
  24.     }
  25. }
  27. public static class PropertyExtensions
  28. {
  29.     public static object FastGetValue(this PropertyInfo propertyInfo, object obj)
  30.     {
  31.         if( propertyInfo == null )
  32.             throw new ArgumentNullException("propertyInfo");
  34.         return GetterSetterFactory.GetPropertyGetterWrapper(propertyInfo).Get(obj);
  35.     }
  37.     public static void FastSetValue(this PropertyInfo propertyInfo, object obj, object value)
  38.     {
  39.         if( propertyInfo == null )
  40.             throw new ArgumentNullException("propertyInfo");
  42.         GetterSetterFactory.GetPropertySetterWrapper(propertyInfo).Set(obj, value);
  43.     }
  44. }
复制代码
说明：我在缓存的设计上并没有使用泛型Dictionary，而是使用了Hashtable。
我承认在简单的单线程测试中，Dictionary要略快于Hashtable 。
再来测试一下FastSetValue的性能吧，毕竟大多数时候我会使用这个扩展方法。
我又在测试代码中增加了一段：
  1. propInfo.FastSetValue(testObj, 123);
  2. Console.Write("FastSet花费时间：　      ");
  3. Stopwatch watch6 = Stopwatch.StartNew();
  5. for( int i = 0; i < count; i++ )
  6.     propInfo.FastSetValue(testObj, 123);
  8. watch6.Stop();
  9. Console.WriteLine(watch6.Elapsed.ToString());
复制代码
测试结果如下：
5.png

测试结果表明：虽然通用接口ISetValue将反射性能优化了37倍，但是最终的FastSetValue将这个数字减少到还不到7倍（在CLR4中还不到5倍）。
看到这个结果您是否也比较郁闷：优化了几十倍的结果，最后却丢了大头，只得到一个零头！
中间那30倍的时间是哪里消耗了？
1. Hashtable的查找时间。
2. 代码的执行路径变长了。
代码的执行路径变长了，我想所有人应该都能接受：为了简化调用并配合缓存一起工作，代码的执行路径确实变长了。
Hashtable的查找时间应该很快吧？ 您是不是也这样想呢？
为了看看Hashtable的查找时间，我又加了一点测试代码：
  1. Hashtable table = new Hashtable();
  2. table[propInfo] = new object();
  3. Console.Write("Hashtable花费时间：      ");
  4. Stopwatch watch7 = Stopwatch.StartNew();
  6. for( int i = 0; i < count; i++ ) {
  7.     object val = table[propInfo];
  8. }
  9. watch7.Stop();
  10. Console.WriteLine(watch7.Elapsed.ToString());
复制代码
现在运行测试代码的结果如下：
6.png

确实，大部分时间消耗在Hashtable的查找上！
缓存的线程并发问题

集合不仅仅只有查找开销，在多线程环境中，我们还要考虑并发性。
看到许多人做性能测试时，总是喜欢写个控制台程序，然后再来个for循环，执行多少万次！
我认为 这样的结果只能反映代码在单线程环境下的性能，在多线程下，结果可能会有较大的差别，当然了，多线程测试的确很复杂，也很难得到准确的数字。但是我们的设计不能不考虑多线程下的并发问题。
虽然我也在单线程环境下测试过Dictionary的性能，的确要比Hashtable略好点。
但是MSDN上对Dictionary的线程安全的描述是这样的：
此类型的公共静态（在 Visual Basic 中为 Shared）成员是线程安全的。但不能保证任何实例成员是线程安全的。

只要不修改该集合，Dictionary) 就可以同时支持多个阅读器。即便如此，从头到尾对一个集合进行枚举本质上并不是一个线程安全的过程。当出现枚举与写访问互相争用这种极少发生的情况时，必须在整个枚举过程中锁定集合。若要允许多个线程访问集合以进行读写操作，则必须实现自己的同步。
而MSDN对Hashtable的线程安全的描述却是：
Hashtable 是线程安全的，可由多个读取器线程和一个写入线程使用。多线程使用时，如果只有一个线程执行写入（更新）操作，则它是线程安全的，从而允许进行无锁定的读取（若编写器序列化为 Hashtable）。若要支持多个编写器，如果没有任何线程在读取 Hashtable 对象，则对 Hashtable 的所有操作都必须通过 Synchronized 方法返回的包装完成。

从头到尾对一个集合进行枚举本质上并不是一个线程安全的过程。即使一个集合已进行同步，其他线程仍可以修改该集合，这将导致枚举数引发异常。若要在枚举过程中保证线程安全，可以在整个枚举过程中锁定集合，或者捕捉由于其他线程进行的更改而引发的异常。
显然，二个集合都不能完全支持多线程的并发读写。
虽然Hashtable提供同步包装的线程安全版本，但是内部还是在使用锁来保证同步的！
没办法，在多线程环境中，任何复杂数据结构都有线程安全问题。
如何保证集合在并发操作中数据的同步呢？
是lock还是ReaderWriterLock？
显然前者的实现较为简单，所以它成了绝大多数人的首选。
在.net4中，ConcurrentDictionary是另一个新的首选方法。
由于Dictionary只支持并发的读操作，所以只要涉及到写操作，它就不安全了，
因此最安全地做法也只好在 读和写 操作上都加lock，否则就不安全了。
而Hashtable则不同，它的内部数据结构支持一个线程写入的同时允许多个线程并发读取，所以只要在写操作上加lock就可以实现线程同步，Hashtable的线程安全版本也就是这样实现的。这也是我选择Hashtable的原因。
小结

在这篇博客中，我演示了二种不同的反射优化方法：
1. 基于Emit的动态生成符合委托签名的IL代码。
2. 使用Delegate.CreateDelegate直接创建委托。
这是二种截然不同的思路：
1. Emit方法，需要先定义一个委托签名，然后生成符合委托签名的IL代码。
2. CreateDelegate可以直接生成委托，但需要借用泛型类解决委托的类型参数问题，最后为了能通用，需要以接口方式调用强类型委托。
虽然我们可以使用任何一种方法得到委托，但是我们需要操作多少属性呢？显然这是一个无解的问题，我们只能为每个属性创建不同的委托。所以新的问题也随之产生：我们如何保存那些委托？如何让它们与属性关联起来？Dictionary或者Hashtable或许是较好的选择(.net 3.5)，然而，这些对象内部的数据结构在查找时，并不是零成本，它们会消耗优化的大部分成果。另外，在实现缓存委托的问题上，并发问题也是值得我们考虑的，不高效的并发设计还会让优化的成果继续丢失！
所以，我认为优化反射是个复杂问题，至少有3个环节是需要考虑的：
1. 如何得到委托？
2. 如何缓存委托？
3. 如何支持并发？
得到委托是容易的，但它只是一个开始！

博客中所有代码将在后续博客中给出。
如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】按钮。
如果，您希望更容易地发现我的新博客，不妨点击一下右下角的【关注 Fish Li】。
因为，我的写作热情也离不开您的肯定支持。
感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

使用道具 举报
相关推荐
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册
发帖
钤凑讪
2025-5-29 16:29:11

0

粉丝关注

10

主题发布

板块介绍填写区域，请于后台编辑
微信扫一扫