作者：手机用户2502875747 | 来源：互联网 | 2024-11-12 08:20
本文总结了一些开发中常见的问题及其解决方案，包括特性过滤器的使用、NuGet程序集版本冲突、线程存储、溢出检查、ThreadPool的最大线程数设置、Redis使用中的问题以及Task.Result和Task.GetAwaiter().GetResult()的区别。
1）关于特性过滤器
特性过滤器在开发中非常常用，主要用于异常捕获和权限控制等场景。虽然使用起来很方便，但其中隐藏了一个潜在的问题：特性过滤器在首次访问时会被创建一次，并且仅创建一次，之后会被ASP.NET缓存。因此，如果在特性类中包含状态可变的局部变量，可能会引发线程安全问题。
2）关于NuGet程序集版本
在项目中使用NuGet包时，不同程序集可能引用不同版本的NuGet包。编译完成后，Web目录下只会保留一个版本的DLL文件。如果这些包是强命名的，可能会导致版本冲突异常。建议尽量保持所有程序集的版本一致。当然，也可以通过在web.config文件中配置bindingRedirect节点来解决版本冲突问题。
6）关于线程存储
在Web开发中，有时需要在一个请求生命周期内从前到后传递某些对象。可以使用CallContext.SetData方法将数据存储在线程中，但在异步操作中，这可能导致数据丢失。此时，可以使用CallContext.LogicalSetData方法，该方法会将数据复制到新的线程中，确保数据在异步操作中也能正确传递。
7）关于溢出检查
C#中有一个关键字checked，用于对代码执行进行溢出检查。例如：
int b = int.MaxValue;
b++;//这里不会抛出异常，b变为-2147483648
unchecked
{
int a = int.MaxValue;
a++;//这里也不会抛出异常，a变成-2147483648
}
checked
{
int a = int.MaxValue;
a++;//这里抛出异常，超出最大值
}
默认情况下是unchecked，因此在某些情况下，int值达到最大值后继续增加会导致错误结果。这是需要注意的一个坑。
8）关于ThreadPool设置最大线程数
不建议手动设置ThreadPool的最大线程数。曾经遇到过一个问题，设置最大线程数为10，用于处理API请求任务。当10个任务都排入线程池队列并走到HTTP请求步骤时，由于HttpClient的请求方法是异步的，需要启动一个Task来发送HTTP请求，而Task也使用线程池，但此时线程池中的线程已用完，无法再分配线程，导致循环等待。可以通过使用信号量来控制线程数，每开启一个任务，信号量加1，任务完成时减1，当信号量达到10时停止执行，等待有空闲任务时再执行。
9）关于使用Redis之后出现的问题
1、CPU和内存消耗增加：从Redis获取数据并序列化为对象集合时，序列化过程会消耗大量资源。在高并发情况下，内存拷贝增多，导致内存消耗激增和频繁的垃圾回收。解决方案：
1、设置二级缓存，先内存后Redis，减少序列化次数。
2、细化缓存，将集合按一定维度分散存储，减少每次获取的数据量，降低序列化时间和CPU峰值。
2、关于序列化：使用Redis缓存时，对象需要序列化为二进制存储。实体类需加上[Serializable]标签，但这可能导致WebApi无法接收前端MVC发来的数据（反序列化失败）。原因是加上标签后，对象反序列化为JSON时按私有变量进行，而非属性。解决方案是在反序列化时判断是否存在"k__BackingField"参数，如果存在则使用微软的序列化方式，否则使用Newtonsoft的序列化方式。
10）关于Task.Result和Task.GetAwaiter().GetResult()的区别
Task.Result和Task.GetAwaiter().GetResult()的主要区别在于异常处理方式。如果任务执行过程中发生异常，Task.Result会将异常包装成一个AggregateException返回，而Task.GetAwaiter().GetResult()则直接返回原始异常信息。
京公网安备 11010802041100号