几种设计良好结构以提高.NET应用性能的方法
写在前面
设计良好的系统，除了架构层面的优良设计外，剩下的大部分就在于如何设计良好的代码，.net提供了很多的类型，这些类型非常灵活，也非常好用，比如list，dictionary、hashset、stringbuilder、string等等。在大多数情况下，大家都是看着业务需要直接去用，似乎并没有什么问题。从我的实际经验来看，出现问题的情况确实是少之又少。之前有朋友问我，我有没有遇到过内存泄漏的情况，我说我写的系统没有，但是同事写的我遇到过几次。
为了记录曾经发生的问题，也为了以后可以避免类似的问题，总结这篇文章，力图从数据统计角度总结几个有效提升.net性能的方法。
本文基于.net core 3.0 preview4，采用[benchmark]进行测试，如果不了解benchmark，建议了解完之后再看本文。
集合-隐藏的初始容量及自动扩容
在.net里，list、dictionary、hashset这些集合类型都具有初始容量，当新增的数据大于初始容量时，会自动扩展，可能大家在使用的时候很少注意这个隐藏的细节（此处暂不考虑默认初始容量、加载因子、扩容增量）。
自动扩容给使用者的感知是无限容量，如果用的不是很好，可能会带来一些新的问题。因为每当集合新增的数据大于当前已经申请的容量的时候，会再申请更大的内存容量，一般是当前容量的两倍。这就意味着我们在集合操作过程中可能需要额外的内存开销。
在本次测试中，我用到了四种场景，可能并不是很完全，但是很有说明性，每个方法都是循环了1000次，时间复杂度均为o(1000)：
- dynamiccapacity：不设置默认长度
- largefixedcapacity：默认长度为2000
- fixedcapacity：默认长度为1000
- fixedanddynamiccapacity：默认长度为100
下图为list的测试结果，可以看到其综合性能排名是fixedcapacity>largefixedcapacity>dynamiccapacity>fixedanddynamiccapacity
下图为dictionary的测试结果，可以看到其综合性能排名是fixedcapacity>largefixedcapacity>fixedanddynamiccapacity>dynamiccapacity，在dictionary场景中，fixedanddynamiccapacity和dynamiccapacity的两个方法性能相差并不大，可能是量还不够大
下图为hashset的测试结果，可以看到其综合性能排名是fixedcapacity>largefixedcapacity>fixedanddynamiccapacity>dynamiccapacity，在hashset场景中，fixedanddynamiccapacity和dynamiccapacity的两个方法性能相差还是很大的
综上所述：
一个恰当的容量初始值，可以有效提升集合操作的效率，如果不太好设置一个准确的数据，可以申请比实际稍大的空间，但是会浪费内存空间，并在实际上降低集合操作性能，编程的时候需要特别注意。
以下是list的测试源码，另两种类型的测试代码与之基本一致：
1: public class listtest
2: {
3: private int size = 1000;
4:
5: [benchmark]
6: public void dynamiccapacity()
7: {
8: list<int> list = new list<int>();
9: for (int i = 0; i < size; i++)
10: {
11: list.add(i);
12: }
13: }
14:
15: [benchmark]
16: public void largefixedcapacity()
17: {
18: list<int> list = new list<int>(2000);
19: for (int i = 0; i < size; i++)
20: {
21: list.add(i);
22: }
23: }
24:
25: [benchmark]
26: public void fixedcapacity()
27: {
28: list<int> list = new list<int>(size);
29: for (int i = 0; i < size; i++)
30: {
31: list.add(i);
32: }
33: }
34:
35: [benchmark]
36: public void fixedanddynamiccapacity()
37: {
38: list<int> list = new list<int>(100);
39: for (int i = 0; i < size; i++)
40: {
41: list.add(i);
42: }
43: }
44: }
结构体与类
结构体是值类型，引用类型和值类型之间的区别是引用类型在堆上分配并进行垃圾回收，而值类型在堆栈中分配并在堆栈展开时被释放，或内联包含类型并在它们的包含类型被释放时被释放。 因此，值类型的分配和释放通常比引用类型的分配和释放开销更低。
一般来说，框架中的大多数类型应该是类。 但是，在某些情况下，值类型的特征使得其更适合使用结构。
如果类型的实例比较小并且通常生存期较短或者通常嵌入在其他对象中，则定义结构而不是类。
该类型具有所有以下特征，可以定义一个结构：
-
它逻辑上表示单个值，类似于基元类型（
int，double，等等） -
它的实例大小小于 16 字节
-
它是不可变的
-
它不会频繁装箱
在所有其他情况下，应将类型定义为类。由于结构体在传递的时候，会被复制，因此在某些场景下可能并不适合提升性能。
以上摘自msdn，可
可以看到struct的平均分配时间只有class的六分之一。
以下为该案例的测试源码：
1: public struct userstructtest
2: {
3: public int userid { get;set; }
4:
5: public int age { get; set; }
6: }
7:
8: public class userclasstest
9: {
10: public int userid { get; set; }
11:
12: public int age { get; set; }
13: }
14:
15: public class structtest
16: {
17: private int size = 1000;
18:
19: [benchmark]
20: public void testbystruct()
21: {
22: userstructtest[] test = new userstructtest[this.size];
23: for (int i = 0; i < size; i++)
24: {
25: test[i].userid = 1;
26: test[i].age = 22;
27: }
28: }
29:
30: [benchmark]
31: public void testbyclass()
32: {
33: userclasstest[] test = new userclasstest[this.size];
34: for (int i = 0; i < size; i++)
35: {
36: test[i] = new userclasstest
37: {
38: userid = 1,
39: age = 22
40: };
41: }
42: }
43: }
stringbuilder与string
字符串是不可变的，每次的赋值都会重新分配一个对象，当有大量字符串操作时，使用string非常容易出现内存溢出，比如导出excel操作，所以大量字符串的操作一般推荐使用stringbuilder，以提高系统性能。
以下为一千次执行的测试结果，可以看到stringbuilder对象的内存分配效率十分的高，当然这是在大量字符串处理的情况，少部分的字符串操作依然可以使用string，其性能损耗可以忽略
这是执行五次的情况，可以发现虽然string的内存分配时间依然较长，但是稳定且错误率低
测试代码如下：
1: public class stringbuildertest
2: {
3: private int size = 5;
4:
5: [benchmark]
6: public void testbystring()
7: {
8: string s = string.empty;
9: for (int i = 0; i < size; i++)
10: {
11: s += "a";
12: s += "b";
13: }
14: }
15:
16: [benchmark]
17: public void testbystringbuilder()
18: {
19: stringbuilder sb = new stringbuilder();
20: for (int i = 0; i < size; i++)
21: {
22: sb.append("a");
23: sb.append("b");
24: }
25:
26: string s = sb.tostring();
27: }
28: }
析构函数
析构函数标识了一个类的生命周期已调用完毕时，会自动清理对象所占用的资源。析构方法不带任何参数，它实际上是保证在程序中会调用垃圾回收方法 finalize()，使用析构函数的对象不会在g0中处理，这就意味着该对象的回收可能会比较慢。通常情况下，不建议使用析构函数，更推荐使用idispose，而且idispose具有刚好的通用性，可以处理托管资源和非托管资源。
以下为本次测试的结果，可以看到内存平均分配效率的差距还是很大的
测试代码如下：
1: public class destructiontest
2: {
3: private int size = 5;
4:
5: [benchmark]
6: public void nodestruction()
7: {
8: for (int i = 0; i < this.size; i++)
9: {
10: usertest usertest = new usertest();
11: }
12: }
13:
14: [benchmark]
15: public void destruction()
16: {
17: for (int i = 0; i < this.size; i++)
18: {
19: userdestructiontest usertest = new userdestructiontest();
20: }
21: }
22: }
23:
24: public class usertest: idisposable
25: {
26: public int userid { get; set; }
27:
28: public int age { get; set; }
29:
30: public void dispose()
31: {
32: console.writeline("11");
33: }
34: }
35:
36: public class userdestructiontest
37: {
38: ~userdestructiontest()
39: {
40:
41: }
42:
43: public int userid { get; set; }
44:
45: public int age { get; set; }
46: }