第二十三节: EF性能篇(三)之基于开源组件 Z.EntityFrameWork.Plus.EF6解决EF性能问题

 

一. 开篇说明

　　EF的性能问题一直以来经常被人所吐槽，究其原因在于“复杂的操作在生成SQL阶段耗时长，且执行效率不高”，但并不是没有办法解决，从EF本身举几个简单的优化例子：

　　①：如果仅是查询数据，并不对数据进行增、删、改操作，查询数据的时候可以取消状态追踪。

db.TestInfor.AsNoTracking().FirstOrDefault();

　　②：用什么查什么，比如一张表有100多个字段，本次业务只需要5个字段，一定是select这5个字段，然后toList，而不是全部查询，再toList()

　　③：利用EF调用原生SQL语句或者EF调用存储过程执行。 （目前为止，没有发现该方式存在什么问题，而且性能也很快，广大博友如果认为这种方式存在什么问题，可以留言给我普及扫盲一下）

　　以上的几种方式，或许在一定程度上能解决一些问题，但面对大数据量的增、删、改，还是心有力而力不足。

1. 前面的章节

　　前面的章节提到了Z.EntityFramework.Extensions 插件解决EF性能问题，该插件确实很nb，性能很高，而且功能很全，但是呵呵，天上没有掉馅饼的好事，该插件是收费的，如果你公司不差钱，或者你是土豪，那么强烈推荐使用该插件，性能确实不错，并且你可以直接右上角 x，不需要看该篇文章了^_^。

　　但往往现实是残酷，穷人居多，这个时候就需要找免费的解决方案了，前面章节提到了 SqlBulkCopy 类（与EF没有半毛钱关系），它可以实现增加操作，不得不说，它在处理大数据量的增加的时候，确实很出色！！！。

　　那么删除和更新怎么办呢？

　　答案是：可以借助 Z.EntityFrameWork.Plus.EF6 才解决。

2. 进入主题

　　Z.EntityFrameWork.Plus.EF6  和 Z.EntityFramework.Extensions 是同一公司的产物，该插件支持的功能很多，比如 删除、更新、缓存机制、过滤器等等，但唯独没有新增操作（都懂得，什么功能都有的话，他的兄弟 Z.EntityFramework.Extensions 怎么办？）。　

　　本章节仅介绍删除和更新两个最常用的功能。　

该插件的几点说明： 

　　①：仅支持EF5、EF6、EF Core，注意不同的版本对应该插件的后缀不同，该章节使用的是EF 6.2，所以对应 Z.EntityFrameWork.Plus.EF6 

　　②：官方号称：Improve EF Performance by 2000%

　　③：可以通过Nuget进行安装

　　④：文档地址    ：  http://entityframework-plus.net/batch-delete

　　　　GitHub地址： https://github.com/zzzprojects/EntityFramework-Plus

 3. 数据库准备

　　

1 public  class SThird
2     {
3         /// <summary>
4         /// 模拟耗时的构造函数
5         /// </summary>
6         private SThird()
7         {
8             long result = 0;
9             for (int i = 0; i < 1000000; i++)
10             {
11                 result += i;
12             }
13             Thread.Sleep(1000);
14             Console.WriteLine("{0}被构造...", this.GetType().Name);
15         }
16         /// <summary>
17         /// 静态变量：由CLR保证，在程序第一次使用该类之前被调用，而且只调用一次
18         /// </summary>
19         private static SThird _SThird = new SThird();
20
21         public static SThird CreateIntance()
22         {
23             return _SThird;
24         }
25     }

　　② 实例成员：只有创建了对象（即进行了类的实例化）才会存在于内存中。

　　证明：在StaticInstroduceDemo类中的静态变量a上加断点(方法体内部加断点，两次实例化类的时候加断点)，然后在客户端实例化两次 StaticInstroduceDemo类，分别调用ShowStaticInstroduce方法，

　　发现：第一次实例化的时候进入静态变量a上的断点，然后在调用对应的方法，而第二次实例化的时候不再进入静态变量a上的断点，直接进入调用的方法。从而验证了：静态成员优先于实例成员进入内存，且只在第一次使用该类的时候进行初始化分配内存，后续将不在分配.

3. 基于以上运行机制可以得出以下几个结论

① 普通类：

　　a. 普通类中可以存在静态成员（静态方法、静态字段），但里面的静态方法不能调用普通类中的普通字段<普通类没有实例化的话，普通字段是不存在的>。

　　b. 普通类中普通方法可以调用里面的静态字段<静态成员先于实例成员加载到内存中>

eg：

② 静态类：

静态类中只能存在静态成员（静态方法和静态字段）

4. 调用形式

　　① 静态成员： 类名.静态成员名

　　② 实例成员： 实例名.实例成员名

5. 声明周期

　　① 对于C/S程序：每启动一次，相当于一次生命周期，关闭程序生命周期结束，多次打开客户端程序互不干扰。 

验证：上述的ShowStaticInstroduce方法，两次实例化后调用输出的结果是2,3 。此时我再打开一个客户端，结果依旧是2,3，这也很好证明了声明周期的问题。

　　② 对于B/S程序：static修饰的成员存储在服务器端中，与客户端关闭与否无关。《详见HomeController下的TestStatic方法》

验证：打开不同浏览器，分别调用TestStatic1方法，发现每点击一次按钮，返回值增加1，关闭该浏览器，重新点击，返回值在原基础上加1. 关闭IIS重新运行，返回值重新计数。证明：在B/S模式下，static修饰的成员存储在服务器端内存中，与客户端关闭与否无关。

 

 

6. 使用场景

　　① 对于C/S程序：static修饰的变量可以当作缓存来使用。

　　② 对于B/S程序：可以利用static的特性来设计单例模式，或者面向多线程存储数据，进行资源的共享<PS: 不考虑性能方面问题和一些极端情况>。

　　③ 作为工具类，全局资源共享。

二. 拆箱和装箱

1. 补充两个概念：

　　值类型：int、double、char、bool、decimal、struct、enum

　　引用类型：各种class类、string、数组、接口、委托、object

2. 装箱：

　　将值类型→引用类型

3. 拆箱：

　　将引用类型→值类型

4. 经典面试题

请问下面代码涉及到几次拆箱和装箱。

分析:

　　① 第一次装箱发生在 object m2 = m1;

　　② 第一次拆箱发生在 (int)m2 上;

　　所以很多人认为答案是：1次装箱和1次拆箱，显然是不对的。

　　　　我们继续分析，熟悉 Console.WriteLine原理的知道内部调用string.Concat()方法进行拼接，而Contact有很多重载，F12看源码可知，

　　　　该案例只能使用 public static String Concat(object arg0, object arg1); 这个重载，

　　　　所以第2次装箱和第3次装箱发生在 m1→object 和（int）m2→object上。

　　所以最终答案是 1次拆箱和3次装箱

5.  特别注意：用什么类型进行装箱的，拆箱就拆成什么类型，否则会抛异常，无法进行类型转换。

 

 

 PS：如果你对.Net其他知识感兴趣，可以参考  DotNet进阶系列(持续更新)  ASP.NET MVC深入浅出系列(持续更新) ORM系列之Entity FrameWork详解（持续更新）    

       那些年我们一起追逐的多线程(Thread、ThreadPool、委托异步调用、Task/TaskFactory、Parallerl、async和await)

 

 

 

 

那些年我们一起追逐的多线程(Thread、ThreadPool、委托异步调用、Task/TaskFactory、Parallerl、async和await)

 

一. 背景

 　　在刚接触开发的头几年里，说实话，根本不考虑多线程的这个问题，貌似那时候脑子里也有没有多线程的这个概念，所有的业务都是一个线程来处理，不考虑性能问题，当然也没有考虑多线程操作一条记录存在的并发问题，后面随着处理的系统业务越来越复杂，多线程再也回避不了了，也就借此机会深入研究了一下.Net中的多线程的处理方案。

　　发现在.Net领域领域中，多线程的处理大致经历了这么几个阶段：Thread→ThreadPool→委托的异步调用→Task→TaskFactory→Parallerl→异步编程模型(async和await)。

　　关注我博客的人会发现，早在2017年6月份的时候，就开始整理多线程问题了，大约用了6篇文章的来介绍了.Net中的线程的使用方法，主要是介绍相应类的实例方法的使用，有点帮助文档的意思了哦，最近多线程使用的相当频繁，借此机会重新结合一些实际业务系统介绍一下.Net领域的多线程问题，本次将整合原先的六篇文章(删除或覆盖更新)。

本质：  充分发掘CPU的性能，把一些并没有先后强依赖关系、且耗时代码块放到一个新的线程里去处理，那么原先按顺序执行的业务就会变成并行执行，让主线程继续往后执行，节约了时间了，提高了效率。

下面补充一下多线程在时间和空间上的开销：

(一). 时间上：

①：开启或销毁一个线程都会通知进出中的dll程序集，让这些dll进行相应的操作。

②：时间片切换：4个逻辑处理器(不考虑Inter的超线程技术，一核对多个线程)，同时并行只能处理4个线程，多余的休眠，很多时候，我们看似很多线程在并行执行，实际上是间歇性的串行。

《关于这个说法有异议的话，请留下您的见解，欢迎讨论，请勿谩骂》

(二). 空间上：

①：用户模式堆栈，一个线程分配1M的堆栈空间。

②：内核模式的堆栈，用户模式的参数需要传递到内核模式。

③：线程的内核数据结构，会存放一下变量。

　

二. 概念的梳理

 1. 进程、线程和多线程

　　进程：当一个程序开始运行时，它就是一个进程（或者多个，eg：游戏），进程包括运行中的程序和程序所使用到的内存和系统资源，而一个进程又是由多个线程组成。

　　线程：线程是程序中的一个执行流，每个线程都有自己的专有寄存器(栈指针、程序计数器等)，但代码区是共享的，即不同的线程可以执行同样的函数。

　　多线程：多线程是指程序中包含多个执行流，即在一个程序中可以同时运行多个不同的线程来执行不同的任务，也就是说允许单个程序创建多个并行执行的线程来完成各自的任务。

2. 多线程的好处和弊端

　　好处：可以提高CPU的利用率。在多线程程序中，一个线程必须等待的时候，CPU可以运行其它的线程而不是等待，这样就大大提高了程序的效率。（牺牲空间资源，来换取时间）

　　弊端：

　　①：线程也是程序，所以线程需要占用内存，线程越多占用内存也越多；（占内存多）

　　②：多线程需要协调和管理，所以需要CPU时间跟踪线程； （占cpu多）

　　③：线程之间对共享资源的访问会相互影响，必须解决竞用共享资源的问题；（多线程存在资源共享问题）

　　④：线程太多会导致控制太复杂，最终可能造成很多Bug。（管理麻烦，产生意外bug）

3. 何时建议使用多线程

　　①. 当主线程试图执行冗长的操作，但系统会卡界面，体验非常不好，这时候可以开辟一个新线程，来处理这项冗长的工作。

　　②. 当请求别的数据库服务器、业务服务器等，可以开辟一个新线程，让主线程继续干别的事。

　　③. 利用多线程拆分复杂运算，提高计算速度。

4. 何时不建议使用多线程

　　当单线程能很好解决，就不要为了使用多线程而用多线程。

5. 同步调用和异步调用

　　①单线程同步调用：方法从上而下一次执行，一步一步执行，有先后顺序。

           

　　②异步调用（区别于异步方法）：开启新的线程去执行业务，主线程单独执行，可以选择是否等待子线程执行完后再执行

　　　　

同步方法 VS 异步方法： 

　　1. 一个误区：异步方法指的是一些特有的方法（并不开启新线程），它和开启一个新的线程比如“很多情况下我们会说，开启一个新的线程去异步调用”，这不是一回事，典型的异步方法，比如js 的ajax请求。

　　2. 同步方法：我们平时封装的一些普通方法大多数都是同步方法，同步方法典型的特点：就是在没有得到方法的返回值或者该方法没有执行完，该调用就需要在这等待，不能继续执行。

　　3. 异步方法：异步方法在调用后，调用这在没有得到返回结果前，就可以继续执行后续业务，异步方法通常是通过通知、回调的方式告诉调用者，无须消耗过多的性能。

举例1：

　　$.Post("url",{},function(data){     });

　　$("#div1").html("");

这两行代码，第一行发送异步请求的时候，即使得到回调返回值，下面清空div1内容的操作同样也将执行，Post就是异步方法。

举例2：

　　先封装1个方法： function  Add(a,b){  先休眠5s;   return a+b}

　　调用：

　　Add（1,2）;

　　$("#div1").html("");

这两行代码，Add方法就属于同步方法，所以必须等5s后，Add方法执行完，才能执行下面清空div1内容的操作。

　　总结：同步方法和异步方法的区别就是：是否需要等待返回结果，才能执行后续操作。

　　

6. 异步多线程的三个特点

　　①：同步方法卡界面，原因是主线程被占用；开启新线程去异步调用不卡界面，原因是计算交给了别的线程，主线程空闲.

　　②：同步方法慢，原因是只有一个线程计算；开启新线程去异步调用快，原因是多个线程同时计算，但是更消耗资源，不宜太多.

　　②：异步多线程是无序的，启动顺序不确定、执行时间不确定、结束时间不确定.

 

三. 系列章节

 　　第一节：复习委托，并且通过委托的异步调用开启一个新线程和异步回调、异步等待。

 　　第二节：深入剖析Thread的五大方法、数据槽、内存栅栏。

 　　第三节：ThreadPool的线程开启、线程等待、线程池的设置、定时功能。

 　　第四节：Task的启动的四种方式以及Task、TaskFactory的线程等待和线程延续的解决方案。

 　　第五节：Task构造函数之TaskCreationOptions枚举处理父子线程之间的关系。

 　　第六节：深入研究Task实例方法ContinueWith的参数TaskContinuationOptions。

 　　第七节：利用CancellationTokenSource实现任务取消和利用CancellationToken类检测取消异常。

 　　第八节：Task的各类Task<TResult>返回值以及通用线程的异常处理方案。

 　　第九节：深究并行编程Parallel类中的三大方法 (For、ForEach、Invoke）和几大编程模型(SPM、APM、EAP、TAP）

 　　第十节：利用async和await简化异步编程模式的几种写法

 　　第十一节：深究用户模式锁的使用场景(异变结构、互锁、旋转锁)

 　　第十二节：深究内核模式锁的使用场景(自动事件锁、手动事件锁、信号量、互斥锁、读写锁、动态锁)

 　　第十三节：实际开发中使用最多的监视锁Monitor、lock语法糖的扩展、混合锁的使用(ManualResetEvent、SemaphoreSlim、ReaderWriterLockSlim)

 　　第十四节: 介绍四大并发集合类并结合单例模式下的队列来说明线程安全和非安全的场景及补充性能调优问题。

 　　第十五节：深入理解async和await的作用及各种适用场景和用法

 　　第十六节：

 　　第十七节：