aspnetcore 的依赖注入

工厂方法

services.AddTransient<Func<string,string,BaseController>>((provider) =>
{
return (string server, string name) =>
{
name = “Gateway.Controllers.” + name;
var type = Assembly.GetEntryAssembly().GetType(name);
BaseController instance = null;
if (type != null)
{
instance = ActivatorUtilities.CreateInstance(provider, type, null) as BaseController;
}
return instance;
};
});

三种生命周期管理模式

只有在充分了解ServiceScope的创建过程以及它与ServiceProvider之间的关系之后,我们才会对ServiceProvider支持的三种生命周期管理模式(Singleton、Scope和Transient)具有深刻的认识。就服务实例的提供方式来说,它们之间具有如下的差异:

  • Singleton:ServiceProvider创建的服务实例保存在作为根节点的ServiceProvider上,所有具有同一根节点的所有ServiceProvider提供的服务实例均是同一个对象。
  • Scoped:ServiceProvider创建的服务实例由自己保存,所以同一个ServiceProvider对象提供的服务实例均是同一个对象。
  • Transient:针对每一次服务提供请求,ServiceProvider总是创建一个新的服务实例。

为了让读者朋友们对ServiceProvider支持的这三种不同的生命周期管理模式具有更加深刻的理解,我们照例来做一个简单的实例演示。我们在一个控制台应用中定义了如下三个服务接口(IFoo、IBar和IBaz)以及分别实现它们的三个服务类(Foo、Bar和Baz)。

现在我们在作为程序入口的Main方法中创建了一个ServiceCollection对象,并采用不同的生命周期管理模式完成了针对三个服务接口的注册(IFoo/Foo、IBar/Bar和IBaz/Baz分别Transient、Scoped和Singleton)。我们接下来针对这个ServiceCollection对象创建了一个ServiceProvider(root),并采用创建ServiceScope的方式创建了它的两个“子ServiceProvider”(child1和child2)。

为了验证ServiceProvider针对Transient模式是否总是创建新的服务实例,我们利用同一个ServiceProvider(root)获取针对服务接口IFoo的实例并进行比较。为了验证ServiceProvider针对Scope模式是否仅仅在当前ServiceScope下具有“单例”的特性,我们先后比较了同一个ServiceProvider(child1)和不同ServiceProvider(child1和child2)两次针对服务接口IBar获取的实例。为了验证具有“同根”的所有ServiceProvider针对Singleton模式总是返回同一个服务实例,我们比较了两个不同child1和child2两次针对服务接口IBaz获取的服务实例。如下所示的输出结构印证了我们上面的论述。

Centos安装Syncthing同步工具

Syncthing是一个开源的同步工具,支持多版本控制,同时支持Windows、Mac OS X、Linux等客户端,和Resilio有点类似,但是又略有不同,这篇文章介绍一下Centos安装Syncthing工具的方法。

syncthing

一、下载与安装

Syncthing工具配置非常的简单,小z博客以CentOS X64为例,如果您需要其它版本的客户端请访问:syncthing官网下载。言归正传,下面就开始分别执行命令:


### 下载客户端
wget http://soft.hixz.org/linux/syncthing-linux-amd64-v0.14.11.tar.gz
### 解压
tar -zxvf syncthing-linux-amd64-v0.14.11.tar.gz
### 进入目录
cd syncthing-linux-amd64-v0.14.11
### 复制到环境变量
cp syncthing /usr/local/bin/

接着我们需要先运行一次让Syncthing自动生成初始配置文件,上面已经加入环境变量,直接输入syncthing即可运行,会看到下面的运行结果。


[root@xiaoz ~]# syncthing
[monitor] 20:37:05 INFO: Starting syncthing
[start] 20:37:05 INFO: Generating ECDSA key and certificate for syncthing...
[7NYBG] 20:37:05 INFO: syncthing v0.14.11 "Dysprosium Dragonfly" (go1.7.3 linux-amd64) jenkins@build.syncthing.net 2016-11-15 06:23:48 UTC
[7NYBG] 20:37:05 INFO: My ID: 7NYBGD4-AL5FI6M-6P5ULKJ-QSPFASO-T57T4QW-WETWQXT-CAGTJ2I-3PFQGQP
[7NYBG] 20:37:06 INFO: Single thread hash performance is 154 MB/s using minio/sha256-simd (95 MB/s using crypto/sha256).
[7NYBG] 20:37:06 INFO: Default folder created and/or linked to new config
[7NYBG] 20:37:06 INFO: Defaults saved. Edit /root/.config/syncthing/config.xml to taste or use the GUI
[7NYBG] 20:37:06 INFO: Ready to synchronize sxdwy-d7npj (readwrite)
[7NYBG] 20:37:06 INFO: Using discovery server https://discovery-v4-2.syncthing.net/v2/?id=DVU36WY-H3LVZHW-E6LLFRE-YAFN5EL-HILWRYP-OC2M47J-Z4PE62Y-ADIBDQC
[7NYBG] 20:37:06 INFO: Using discovery server https://discovery-v4-3.syncthing.net/v2/?id=VK6HNJ3-VVMM66S-HRVWSCR-IXEHL2H-U4AQ4MW-UCPQBWX-J2L2UBK-NVZRDQZ
[7NYBG] 20:37:06 INFO: Using discovery server https://discovery-v4-4.syncthing.net/v2/?id=LYXKCHX-VI3NYZR-ALCJBHF-WMZYSPK-QG6QJA3-MPFYMSO-U56GTUK-NA2MIAW
[7NYBG] 20:37:06 INFO: Using discovery server https://discovery-v6-2.syncthing.net/v2/?id=DVU36WY-H3LVZHW-E6LLFRE-YAFN5EL-HILWRYP-OC2M47J-Z4PE62Y-ADIBDQC
[7NYBG] 20:37:06 INFO: Using discovery server https://discovery-v6-3.syncthing.net/v2/?id=VK6HNJ3-VVMM66S-HRVWSCR-IXEHL2H-U4AQ4MW-UCPQBWX-J2L2UBK-NVZRDQZ
[7NYBG] 20:37:06 INFO: Using discovery server https://discovery-v6-4.syncthing.net/v2/?id=LYXKCHX-VI3NYZR-ALCJBHF-WMZYSPK-QG6QJA3-MPFYMSO-U56GTUK-NA2MIAW
[7NYBG] 20:37:06 INFO: TCP listener ([::]:22000) starting
[7NYBG] 20:37:06 INFO: Completed initial scan (rw) of folder sxdwy-d7npj
[7NYBG] 20:37:06 INFO: Loading HTTPS certificate: open /root/.config/syncthing/https-cert.pem: no such file or directory
[7NYBG] 20:37:06 INFO: Creating new HTTPS certificate
[7NYBG] 20:37:07 INFO: GUI and API listening on 127.0.0.1:8384
[7NYBG] 20:37:07 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/
[7NYBG] 20:37:07 INFO: Device 7NYBGD4-AL5FI6M-6P5ULKJ-QSPFASO-T57T4QW-WETWQXT-CAGTJ2I-3PFQGQP is "xiaoz" at [dynamic]
[7NYBG] 20:37:11 INFO: Automatic upgrade (current "v0.14.11" < latest "v0.14.12")
[7NYBG] 20:37:17 INFO: Detected 0 NAT devices

二、修改配置文件

上一个步骤输入syncthing已经成功运行,并生成了对应的配置文件,输入Ctrl C退出客户端。我们需要修改下默认的配置文件:vi ~/.config/syncthing/config.xml大概在22行左右的配置,将127.0.0.1修改为0.0.0.0,如下截图。

2016-11-22_204409

三、放行端口

syncthing默认监听8384端口,我们需要在iptables放行这个端口,依次输入下面的命令。


### 放行8384端口
/sbin/iptables -I INPUT -p tcp --dport 8384 -j ACCEPT
/etc/init.d/iptables save
service iptables restart 

四、测试访问

再次输入syncthing命令启动Syncthing客户端,然后在浏览器输入:http://您的服务器IP:8384进行访问。

runsyncthing

Syncthing默认支持中文语言,首次登录会让您设置用户名和密码,到这里基本上就完成了,如何添加其它设备和同步文件夹可以自行研究下。

五、其它说明

如果希望Syncthing在后台运行可以使用nohup命令来实现:nohup syncthing &

六、总结

Syncthing可以在不同设备之间实现同步,前提是已经安装Syncthing客户端,另外还支持历史版本的功能,如果有条件您完整可以利用Syncthing打造自己私有的同步工具。原创文章,转载请注明。

此文参考了:Syncthing: 一个在计算机之间同步文件/文件夹的私密安全同步工具
Syncthing官网:https://syncthing.net/

mac 装双系统..

1.U盘格式化为ms-dos(fat)  主引导记录..注意U盘名字不能是中文..否则格式化失败

2.无法创建可引导的USB驱动器—-要先在磁盘工具里面移除 windows 的ISO!

3.按options选项..进入efi硬盘

4.不能装docker  说虚拟化不能开启…任务管理器.cpu可以看到

https://apple.stackexchange.com/questions/120361/how-to-turn-on-hardware-virtualization-on-late-2013-macbook-pro-for-windows-8-1?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

It sounds like you\’re running into the same issue I did, where after booting into Windows the VT-x shows as \’Disabled\’ in Task Manager.

Not sure how or why, but after going into

  • OS X
  • System Preferences
  • Target Disk
  • Select the BOOTCAMP disk as the startup disk

Everything was well after that and I could happily use Hyper-V, even from a cold boot.

If I cold booted using the Options-key, and then selecting Windows, VT-x was disabled in Task Manager.

Go figure. Could some Mac genius out there explain this one?

This thread explains that you have to boot using the CSM-BIOS layer. discussions.apple.com/thread/6720461?tstart=0 ; In addition it also provides a command line to permanently fix this problem. First use diskutil list to work out Windows partition, then sudo /usr/sbin/bless --device /dev/disk0s4 --setBoot --legacy --legacydrivehint /dev/disk0 – Chui Tey Dec 23 \’16 at 23:10

接着上面的说,这个在mac本上就没有BIOS主板系统,但是昂贵的Mac肯定也是有虚拟化服务的~只不过Mac本不是手动启动,而是每次启动完OSX系统自动启动~ 但是如果 第一次启动的是 bootcamp的Windows 系统 那么 这个 虚拟化是启动不了的。。。这时候有一个解决办法就是先启动OSX系统,再更具目标磁盘重启到bootcamp的Windows系统~ 参考下图~

通过这个启动盘重启的Windows虚拟化是 打开的状态~ 如下图

虚拟化状态打开后就可以下载安装 HoloLens 的模拟器了 ~ 而且在开发调试中 也一定要把虚拟化打开

typescript

Typescript 2.0之后,tsd和typings都可以去掉了。要获得lodash的类型定义文件只需要

npm install @types/lodash

这样一来,typescript的工作流就和普通的Node.js项目没什么区别了。
更重要的是Typescript 2.1之后,async/await可以直接编译到ES5。babel什么的,再见吧

https://github.com/typings/typings

你真的了解volatile关键字吗?

一、Java内存模型

想要理解volatile为什么能确保可见性,就要先理解Java中的内存模型是什么样的。

Java内存模型规定了所有的变量都存储在主内存中。每条线程中还有自己的工作内存,线程的工作内存中保存了被该线程所使用到的变量(这些变量是从主内存中拷贝而来)。线程对变量的所有操作(读取,赋值)都必须在工作内存中进行。不同线程之间也无法直接访问对方工作内存中的变量,线程间变量值的传递均需要通过主内存来完成。

基于此种内存模型,便产生了多线程编程中的数据“脏读”等问题。

举个简单的例子:在java中,执行下面这个语句:

1
i  = 10 ;

执行线程必须先在自己的工作线程中对变量i所在的缓存行进行赋值操作,然后再写入主存当中。而不是直接将数值10写入主存当中。

比如同时有2个线程执行这段代码,假如初始时i的值为10,那么我们希望两个线程执行完之后i的值变为12。但是事实会是这样吗?

可能存在下面一种情况:初始时,两个线程分别读取i的值存入各自所在的工作内存当中,然后线程1进行加1操作,然后把i的最新值11写入到内存。此时线程2的工作内存当中i的值还是10,进行加1操作之后,i的值为11,然后线程2把i的值写入内存。

最终结果i的值是11,而不是12。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。

那么如何确保共享变量在多线程访问时能够正确输出结果呢?

在解决这个问题之前,我们要先了解并发编程的三大概念:原子性,有序性,可见性。

二、原子性

1.定义

原子性:即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断,要么就都不执行。

2.实例

一个很经典的例子就是银行账户转账问题:

比如从账户A向账户B转1000元,那么必然包括2个操作:从账户A减去1000元,往账户B加上1000元。

试想一下,如果这2个操作不具备原子性,会造成什么样的后果。假如从账户A减去1000元之后,操作突然中止。这样就会导致账户A虽然减去了1000元,但是账户B没有收到这个转过来的1000元。

所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。

同样地反映到并发编程中会出现什么结果呢?

举个最简单的例子,大家想一下假如为一个32位的变量赋值过程不具备原子性的话,会发生什么后果?

1
i = 9;

假若一个线程执行到这个语句时,我暂且假设为一个32位的变量赋值包括两个过程:为低16位赋值,为高16位赋值。

那么就可能发生一种情况:当将低16位数值写入之后,突然被中断,而此时又有一个线程去读取i的值,那么读取到的就是错误的数据。

3.Java中的原子性

在Java中,对基本数据类型的变量的读取和赋值操作是原子性操作,即这些操作是不可被中断的,要么执行,要么不执行。

上面一句话虽然看起来简单,但是理解起来并不是那么容易。看下面一个例子i:

请分析以下哪些操作是原子性操作:

1
2
3
4
x = 10;         //语句1
y = x;         //语句2
x ;           //语句3
x = x 1;     //语句4

咋一看,可能会说上面的4个语句中的操作都是原子性操作。其实只有语句1是原子性操作,其他三个语句都不是原子性操作。

语句1是直接将数值10赋值给x,也就是说线程执行这个语句的会直接将数值10写入到工作内存中。

语句2实际上包含2个操作,它先要去读取x的值,再将x的值写入工作内存,虽然读取x的值以及 将x的值写入工作内存 这2个操作都是原子性操作,但是合起来就不是原子性操作了。

同样的,x 和 x = x 1包括3个操作:读取x的值,进行加1操作,写入新的值。

所以上面4个语句只有语句1的操作具备原子性。

也就是说,只有简单的读取、赋值(而且必须是将数字赋值给某个变量,变量之间的相互赋值不是原子操作)才是原子操作。

从上面可以看出,Java内存模型只保证了基本读取和赋值是原子性操作,如果要实现更大范围操作的原子性,可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块,那么自然就不存在原子性问题了,从而保证了原子性。

关于synchronized和Lock的使用,参考:关于synchronized和ReentrantLock之多线程同步详解

三、可见性

1.定义

可见性是指当多个线程访问同一个变量时,一个线程修改了这个变量的值,其他线程能够立即看得到修改的值。

2.实例

举个简单的例子,看下面这段代码:

1
2
3
4
5
6
//线程1执行的代码
int i = 0;
i = 10;
//线程2执行的代码
j = i;

由上面的分析可知,当线程1执行 i =10这句时,会先把i的初始值加载到工作内存中,然后赋值为10,那么在线程1的工作内存当中i的值变为10了,却没有立即写入到主存当中。

此时线程2执行 j = i,它会先去主存读取i的值并加载到线程2的工作内存当中,注意此时内存当中i的值还是0,那么就会使得j的值为0,而不是10.

这就是可见性问题,线程1对变量i修改了之后,线程2没有立即看到线程1修改的值。

3.Java中的可见性

对于可见性,Java提供了volatile关键字来保证可见性。

当一个共享变量被volatile修饰时,它会保证修改的值会立即被更新到主存,当有其他线程需要读取时,它会去内存中读取新值。

而普通的共享变量不能保证可见性,因为普通共享变量被修改之后,什么时候被写入主存是不确定的,当其他线程去读取时,此时内存中可能还是原来的旧值,因此无法保证可见性。

另外,通过synchronized和Lock也能够保证可见性,synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码,并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

四、有序性

1.定义

有序性:即程序执行的顺序按照代码的先后顺序执行。

2.实例

举个简单的例子,看下面这段代码:

1
2
3
4
5
6
int i = 0;             
boolean flag = false;
i = 1;                //语句1 
flag = true;          //语句2

上面代码定义了一个int型变量,定义了一个boolean类型变量,然后分别对两个变量进行赋值操作。从代码顺序上看,语句1是在语句2前面的,那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗?不一定,为什么呢?这里可能会发生指令重排序(Instruction Reorder)。

下面解释一下什么是指令重排序,一般来说,处理器为了提高程序运行效率,可能会对输入代码进行优化,它不保证程序中各个语句的执行先后顺序同代码中的顺序一致,但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

比如上面的代码中,语句1和语句2谁先执行对最终的程序结果并没有影响,那么就有可能在执行过程中,语句2先执行而语句1后执行。

但是要注意,虽然处理器会对指令进行重排序,但是它会保证程序最终结果会和代码顺序执行结果相同,那么它靠什么保证的呢?再看下面一个例子:

1
2
3
4
int a = 10;    //语句1
int r = 2;    //语句2
a = a 3;    //语句3
r = a*a;     //语句4

这段代码有4个语句,那么可能的一个执行顺序是:

那么可不可能是这个执行顺序呢: 语句2 语句1 语句4 语句3

不可能,因为处理器在进行重排序时是会考虑指令之间的数据依赖性,如果一个指令Instruction 2必须用到Instruction 1的结果,那么处理器会保证Instruction 1会在Instruction 2之前执行。

虽然重排序不会影响单个线程内程序执行的结果,但是多线程呢?下面看一个例子:

1
2
3
4
5
6
7
8
9
10
//线程1:
context = loadContext();   //语句1
inited = true;             //语句2
 //线程2:
while(!inited ){
   sleep()
}
doSomethingwithconfig(context);

上面代码中,由于语句1和语句2没有数据依赖性,因此可能会被重排序。假如发生了重排序,在线程1执行过程中先执行语句2,而此是线程2会以为初始化工作已经完成,那么就会跳出while循环,去执行doSomethingwithconfig(context)方法,而此时context并没有被初始化,就会导致程序出错。

从上面可以看出,指令重排序不会影响单个线程的执行,但是会影响到线程并发执行的正确性。

也就是说,要想并发程序正确地执行,必须要保证原子性、可见性以及有序性。只要有一个没有被保证,就有可能会导致程序运行不正确。

3.Java中的有序性

在Java内存模型中,允许编译器和处理器对指令进行重排序,但是重排序过程不会影响到单线程程序的执行,却会影响到多线程并发执行的正确性。

在Java里面,可以通过volatile关键字来保证一定的“有序性”。另外可以通过synchronized和Lock来保证有序性,很显然,synchronized和Lock保证每个时刻是有一个线程执行同步代码,相当于是让线程顺序执行同步代码,自然就保证了有序性。

另外,Java内存模型具备一些先天的“有序性”,即不需要通过任何手段就能够得到保证的有序性,这个通常也称为 happens-before 原则。如果两个操作的执行次序无法从happens-before原则推导出来,那么它们就不能保证它们的有序性,虚拟机可以随意地对它们进行重排序。

下面就来具体介绍下happens-before原则(先行发生原则):

①程序次序规则:一个线程内,按照代码顺序,书写在前面的操作先行发生于书写在后面的操作

②锁定规则:一个unLock操作先行发生于后面对同一个锁的lock操作

③volatile变量规则:对一个变量的写操作先行发生于后面对这个变量的读操作

④传递规则:如果操作A先行发生于操作B,而操作B又先行发生于操作C,则可以得出操作A先行发生于操作C

⑤线程启动规则:Thread对象的start()方法先行发生于此线程的每个一个动作

⑥线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生

⑦线程终结规则:线程中所有的操作都先行发生于线程的终止检测,我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行

⑧对象终结规则:一个对象的初始化完成先行发生于他的finalize()方法的开始

这8条规则中,前4条规则是比较重要的,后4条规则都是显而易见的。

下面我们来解释一下前4条规则:

对于程序次序规则来说,就是一段程序代码的执行在单个线程中看起来是有序的。注意,虽然这条规则中提到“书写在前面的操作先行发生于书写在后面的操作”,这个应该是程序看起来执行的顺序是按照代码顺序执行的,但是虚拟机可能会对程序代码进行指令重排序。虽然进行重排序,但是最终执行的结果是与程序顺序执行的结果一致的,它只会对不存在数据依赖性的指令进行重排序。因此,在单个线程中,程序执行看起来是有序执行的,这一点要注意理解。事实上,这个规则是用来保证程序在单线程中执行结果的正确性,但无法保证程序在多线程中执行的正确性。

第二条规则也比较容易理解,也就是说无论在单线程中还是多线程中,同一个锁如果处于被锁定的状态,那么必须先对锁进行了释放操作,后面才能继续进行lock操作。

第三条规则是一条比较重要的规则。直观地解释就是,如果一个线程先去写一个变量,然后一个线程去进行读取,那么写入操作肯定会先行发生于读操作。

第四条规则实际上就是体现happens-before原则具备传递性。

五、深入理解volatile关键字

1.volatile保证可见性

一旦一个共享变量(类的成员变量、类的静态成员变量)被volatile修饰之后,那么就具备了两层语义:

1)保证了不同线程对这个变量进行操作时的可见性,即一个线程修改了某个变量的值,这新值对其他线程来说是立即可见的。

2)禁止进行指令重排序。

先看一段代码,假如线程1先执行,线程2后执行:

1
2
3
4
5
6
7
8
//线程1
boolean stop = false;
while(!stop){
    doSomething();
}
//线程2
stop = true;

这段代码是很典型的一段代码,很多人在中断线程时可能都会采用这种标记办法。但是事实上,这段代码会完全运行正确么?即一定会将线程中断么?不一定,也许在大多数时候,这个代码能够把线程中断,但是也有可能会导致无法中断线程(虽然这个可能性很小,但是只要一旦发生这种情况就会造成死循环了)。

下面解释一下这段代码为何有可能导致无法中断线程。在前面已经解释过,每个线程在运行过程中都有自己的工作内存,那么线程1在运行的时候,会将stop变量的值拷贝一份放在自己的工作内存当中。

那么当线程2更改了stop变量的值之后,但是还没来得及写入主存当中,线程2转去做其他事情了,那么线程1由于不知道线程2对stop变量的更改,因此还会一直循环下去。

但是用volatile修饰之后就变得不一样了:

第一:使用volatile关键字会强制将修改的值立即写入主存;

第二:使用volatile关键字的话,当线程2进行修改时,会导致线程1的工作内存中缓存变量stop的缓存行无效(反映到硬件层的话,就是CPU的L1或者L2缓存中对应的缓存行无效);

第三:由于线程1的工作内存中缓存变量stop的缓存行无效,所以线程1再次读取变量stop的值时会去主存读取。

那么在线程2修改stop值时(当然这里包括2个操作,修改线程2工作内存中的值,然后将修改后的值写入内存),会使得线程1的工作内存中缓存变量stop的缓存行无效,然后线程1读取时,发现自己的缓存行无效,它会等待缓存行对应的主存地址被更新之后,然后去对应的主存读取最新的值。

那么线程1读取到的就是最新的正确的值。

2.volatile不能确保原子性

下面看一个例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Test {
    public volatile int inc = 0;
    public void increase() {
        inc ;
    }
    public static void main(String[] args) {
        final Test test = new Test();
        for(int i=0;i<10;i ){
            new Thread(){
                public void run() {
                    for(int j=0;j<1000;j )
                        test.increase();
                };
            }.start();
        }
        while(Thread.activeCount()>1//保证前面的线程都执行完
            Thread.yield();
        System.out.println(test.inc);
    }
}

大家想一下这段程序的输出结果是多少?也许有些朋友认为是10000。但是事实上运行它会发现每次运行结果都不一致,都是一个小于10000的数字。

可能有的朋友就会有疑问,不对啊,上面是对变量inc进行自增操作,由于volatile保证了可见性,那么在每个线程中对inc自增完之后,在其他线程中都能看到修改后的值啊,所以有10个线程分别进行了1000次操作,那么最终inc的值应该是1000*10=10000。

这里面就有一个误区了,volatile关键字能保证可见性没有错,但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值,但是volatile没办法保证对变量的操作的原子性。

在前面已经提到过,自增操作是不具备原子性的,它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行,就有可能导致下面这种情况出现:

假如某个时刻变量inc的值为10,

线程1对变量进行自增操作,线程1先读取了变量inc的原始值,然后线程1被阻塞了;

然后线程2对变量进行自增操作,线程2也去读取变量inc的原始值,由于线程1只是对变量inc进行读取操作,而没有对变量进行修改操作,所以不会导致线程2的工作内存中缓存变量inc的缓存行无效,也不会导致主存中的值刷新,所以线程2会直接去主存读取inc的值,发现inc的值时10,然后进行加1操作,并把11写入工作内存,最后写入主存。

然后线程1接着进行加1操作,由于已经读取了inc的值,注意此时在线程1的工作内存中inc的值仍然为10,所以线程1对inc进行加1操作后inc的值为11,然后将11写入工作内存,最后写入主存。

那么两个线程分别进行了一次自增操作后,inc只增加了1。

根源就在这里,自增操作不是原子性操作,而且volatile也无法保证对变量的任何操作都是原子性的。

解决方案:可以通过synchronized或lock,进行加锁,来保证操作的原子性。也可以通过AtomicInteger。

在java 1.5的java.util.concurrent.atomic包下提供了一些原子操作类,即对基本数据类型的 自增(加1操作),自减(减1操作)、以及加法操作(加一个数),减法操作(减一个数)进行了封装,保证这些操作是原子性操作。atomic是利用CAS来实现原子性操作的(Compare And Swap),CAS实际上是利用处理器提供的CMPXCHG指令实现的,而处理器执行CMPXCHG指令是一个原子性操作。

3.volatile保证有序性

在前面提到volatile关键字能禁止指令重排序,所以volatile能在一定程度上保证有序性。

volatile关键字禁止指令重排序有两层意思:

1)当程序执行到volatile变量的读操作或者写操作时,在其前面的操作的更改肯定全部已经进行,且结果已经对后面的操作可见;在其后面的操作肯定还没有进行;

2)在进行指令优化时,不能将在对volatile变量的读操作或者写操作的语句放在其后面执行,也不能把volatile变量后面的语句放到其前面执行。

可能上面说的比较绕,举个简单的例子:

1
2
3
4
5
6
7
8
//x、y为非volatile变量
//flag为volatile变量
x = 2;        //语句1
y = 0;        //语句2
flag = true//语句3
x = 4;         //语句4
y = -1;       //语句5

由于flag变量为volatile变量,那么在进行指令重排序的过程的时候,不会将语句3放到语句1、语句2前面,也不会讲语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序是不作任何保证的。

并且volatile关键字能保证,执行到语句3时,语句1和语句2必定是执行完毕了的,且语句1和语句2的执行结果对语句3、语句4、语句5是可见的。

那么我们回到前面举的一个例子:

1
2
3
4
5
6
7
8
9
//线程1:
context = loadContext();   //语句1
inited = true;             //语句2
//线程2:
while(!inited ){
  sleep()
}
doSomethingwithconfig(context);

前面举这个例子的时候,提到有可能语句2会在语句1之前执行,那么久可能导致context还没被初始化,而线程2中就使用未初始化的context去进行操作,导致程序出错。

这里如果用volatile关键字对inited变量进行修饰,就不会出现这种问题了,因为当执行到语句2时,必定能保证context已经初始化完毕。

六、volatile的实现原理

1.可见性

处理器为了提高处理速度,不直接和内存进行通讯,而是将系统内存的数据独到内部缓存后再进行操作,但操作完后不知什么时候会写到内存。

如果对声明了volatile变量进行写操作时,JVM会向处理器发送一条Lock前缀的指令,将这个变量所在缓存行的数据写会到系统内存。 这一步确保了如果有其他线程对声明了volatile变量进行修改,则立即更新主内存中数据。

但这时候其他处理器的缓存还是旧的,所以在多处理器环境下,为了保证各个处理器缓存一致,每个处理会通过嗅探在总线上传播的数据来检查 自己的缓存是否过期,当处理器发现自己缓存行对应的内存地址被修改了,就会将当前处理器的缓存行设置成无效状态,当处理器要对这个数据进行修改操作时,会强制重新从系统内存把数据读到处理器缓存里。 这一步确保了其他线程获得的声明了volatile变量都是从主内存中获取最新的。

2.有序性

Lock前缀指令实际上相当于一个内存屏障(也成内存栅栏),它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置,也不会把前面的指令排到内存屏障的后面;即在执行到内存屏障这句指令时,在它前面的操作已经全部完成。

七、volatile的应用场景

synchronized关键字是防止多个线程同时执行一段代码,那么就会很影响程序执行效率,而volatile关键字在某些情况下性能要优于synchronized,但是要注意volatile关键字是无法替代synchronized关键字的,因为volatile关键字无法保证操作的原子性。通常来说,使用volatile必须具备以下2个条件:

1)对变量的写操作不依赖于当前值

2)该变量没有包含在具有其他变量的不变式中

下面列举几个Java中使用volatile的几个场景。

①.状态标记量

1
2
3
4
5
6
7
8
9
volatile boolean flag = false;
 //线程1
while(!flag){
    doSomething();
}
  //线程2
public void setFlag() {
    flag = true;
}

根据状态标记,终止线程。

②.单例模式中的double check

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Singleton{
    private volatile static Singleton instance = null;
    private Singleton() {
    }
    public static Singleton getInstance() {
        if(instance==null) {
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}
为什么要使用volatile 修饰instance?

主要在于instance = new Singleton()这句,这并非是一个原子操作,事实上在 JVM 中这句话大概做了下面 3 件事情:

1.给 instance 分配内存

2.调用 Singleton 的构造函数来初始化成员变量

3.将instance对象指向分配的内存空间(执行完这步 instance 就为非 null 了)。

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的,最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者,则在 3 执行完毕、2 未执行之前,被线程二抢占了,这时 instance 已经是非 null 了(但却没有初始化),所以线程二会直接返回 instance,然后使用,然后顺理成章地报错。

参考文章

Java并发编程:volatile关键字解析
【死磕Java并发】—–深入分析volatile的实现原理
Java并发机制的底层实现原理
Volatile的实现原理

关于udp的一些问题总结

 

socket 的端口号

客户端的 socket 很少调用 bind() 来指明 socket 的端口号。 相反通常是让操作系统自动分配一个端口号。

TCP客户端 socket 的端口号是在调用了 connect() 之后,系统 会自动分配端口号。

UDP客户端 socket 的端口号是在第一次调用 sendto() 之后, 系统会自动分配端口号。

如果 UDP 的端口是自动分配的话,那么系统不会再改变这个端 口号。如果 UDP 的IP 地址也是自动分配的话,那么每一次调用 sendto() 系统都可能会根据目的 IP 地址而改变源IP地址。

weak end system VS strong end system

网络接口会接收所有和本地 IP 地址一致的数据包,叫做 weak end system .

网络接口只会接收所有和本接口的 IP 地址一致的数据包,叫做 strong end system 。

不同点, 在一个 multihome 的主机有多个网络接口,那么 strong end system 的过滤检查会更强大一些。

UDP 发送数据的地址和接收数据的地址不一致的问题。

UDP 的客户端发送给服务器,如果服务器的用于接收的网络接口 有多个 IP 地址,那么服务器送响应的时候就会自动选择一个 primary IP 地址回送给客户端。primary IP 地址有可能和客户 端发送的 IP 地址不一样。

如果客户端根据接收的响应的 IP 地址来判断是否是服务器发送 的响应,那么就有可能出错。

解决办法,一个是改造客户端,不再用 IP 地址判断是否是一个 服务器发送的数据包,而是根据 DNS 得到的域名来判断。缺点 是系统一定要有域名服务器,而且查询域名会影响效率。 一个办法是服务器不是用 wildcard 来绑定 socket ,而是为每 一个 IP 地址绑定一个 socket 。 缺点是系统如果动态改变了 IP 地址就需要重新起动服务器,而且增加服务器必须 select() 检查所有的 socket 。

UDP ICMP

sendto() 成功返回后,意思是说主机的网络接口有足够的缓冲 队列空间,用以容纳下要发送的数据。

如果接收端回送 ICMP 消息,那么是 socket 不能够知道的,除 非 UDP socket 也调用了 connect() 变成了 connected UDP socket.

linux 的实现中,则会 unconnected socket 也会返回 ICMP 错 误,只要 SO_BSDCOMPAT socket option 没有置位。

ICMP 消息会在下一个 read() 中返回, 错误值是 ECONNREFUSED。

有些 System V 系统有 Bug ,不会为 connected socket 返回 ICMP 错误。

connected UDP socket VS unconnected UDP socket

调用了 connect() 函数的 UDP socket 就从 unconnected UDP socket 变成了 connected UDP socket 。

connect() 并不是真正建立连接,只是把 socket 和一个 peer name 联系在一起。

函数 connect() 函数的操作完全是本地操作, 不涉及网络。

系统会根据 connect() 函数指定的目的地址寻找网络接口,选 择该网络接口的 primary IP 地址作为本地地址。

不同点:

  1. connected socket 调用 send 而不是 sendto 。
  2. connected socket 调用 recv 而不是 recvfrom 。 只有目的地址 和 connect() 函数指定的地址一致才会被接收到。
  • 问题:如果系统也是根据 IP 地址来判断一个连接的话,那么也有可能出现 上面说的发送命令的目的地址和接收响应的源地址是不一样的问题。
  • 答案:只有改造服务器了。
  1. ICMP 错误会收到。
  2. 发送数据的时候,由于不用指定目的 IP 地址,在用户程序 和内核之间传递的数据少,所以效率稍微高一些。

connected UDP socket 是否可以再调用 connect()

和 TCP 不一样,connected socket 可以多次调用 connect()。

connect() 的目的地址中的 address family 如果是 AF_UNSPEC 那么 connected socket 会变成 unconnected socket 。

可能会返回 EAFNOSUPPORT ,但是没有关系。

 

 

 

 

WireShark如何抓取本地localhost的包

今天将自己的电脑既作为客户端又作为服务端进行一个程序的测试,想着用WireShark来抓包分析一下问题,但由于WireShark只能抓取经过电脑网卡的包,由于我是使用localhost或者127.0.0.1进行测试的,流量是不经过电脑网卡的,所以WireShark无法抓包,一番查找之下找到了解决方法。

1 . 以管理员身份打开命令提示符

2 . 输入 route add 本机ip mask 255.255.255.255 网关ip
如果不知道本机ip和网关ip,可以在命令行输入ipconfig查看
例如我的 : route add 192.168.0.106 mask 255.255.255.255 192.168.0.1

这句话的作用是将发给电脑的包转发给路由器,路由器再发给自己的电脑。。避免本地回环

3 . 将我们程序里面的localhost或者127.0.0.1替换成本机ip

4 . 使用WireShark即可抓到本地包

注:在测试完之后,使用route delete 本机ip mask 255.255.255.255 网关ip来删除我们上面的更改,不然我们本机的所有报文都会先经过网卡再回到本机,会比较消耗性能。

 

三、使用 RawCap

需要管理员权限运行 RawCap 。

进入终端(cmd),然后运行:

RawCap.exe 127.0.0.1 dumpfile.pcapRawCap.exe 本地IP dumpfile.pcap

抓好包后,按 Ctrl C,停止抓包。此时会在 RawCap 的同级目录下生成一个dumpfile.pcap文件。用 Wireshark 打开,就可以看到本地环回的数据包了。

四、使用 Npcap

Npcap 是对当前最流行的 WinPcap 工具包进行改进的一个项目。

安装前请先卸载 WinPcap(可以在Wireshark 的Help一栏查看是否在使用 Npcap) 。

安装时要勾选

Use DLT_NULL protocol sa Loopback ...

install npcap in winpcap api-compat mode(选这个,是要兼容 WinPcap)

npcap-0.78-r2

npcap-0.78-r2

安装完成启动 Wireshark, 可以看到在网络接口列表中,多了一项 Npcap Loopback adapter,这个就是来抓本地环回包的网络接口。

wireshark-npcap 捕获界面

wireshark-npcap 捕获界面

异步编程中的最佳做法

近日来,涌现了许多关于 Microsoft .NET Framework 4.5 中新增了对 async 和 await 支持的信息。 本文旨在作为学习异步编程的“第二步”;我假设您已阅读过有关这一方面的至少一篇介绍性文章。 本文不提供任何新内容,Stack Overflow、MSDN 论坛和 async/await FAQ 这类在线资源提供了同样的建议。 本文只重点介绍一些淹没在文档海洋中的最佳做法。

本文中的最佳做法更大程度上是“指导原则”,而不是实际规则。 其中每个指导原则都有一些例外情况。 我将解释每个指导原则背后的原因,以便可以清楚地了解何时适用以及何时不适用。 图 1 中总结了这些指导原则;我将在以下各节中逐一讨论。

“名称”

说明

异常

避免 Async Void

最好使用 async Task 方法而不是 async void 方法

事件处理程序

始终使用 Async

不要混合阻塞式代码和异步代码

控制台 main 方法

配置上下文

尽可能使用 ConfigureAwait(false)

需要上下文的方法

Async 方法有三种可能的返回类型: Task、Task<T> 和 void,但是 async 方法的固有返回类型只有 Task 和 Task<T>。 当从同步转换为异步代码时,任何返回类型 T 的方法都会成为返回 Task<T> 的 async 方法,任何返回 void 的方法都会成为返回 Task 的 async 方法。 下面的代码段演示了一个返回 void 的同步方法及其等效的异步方法:

  1.  
  2.           void MyMethod()
  3. {
  4.   // Do synchronous work.
  5.           Thread.Sleep(1000);
  6. }
  7. async Task MyMethodAsync()
  8. {
  9.   // Do asynchronous work.
  10.           await Task.Delay(1000);
  11. }
  12.         

返回 void 的 async 方法具有特定用途: 用于支持异步事件处理程序。 事件处理程序可以返回某些实际类型,但无法以相关语言正常工作;调用返回类型的事件处理程序非常困难,事件处理程序实际返回某些内容这一概念也没有太大意义。 事件处理程序本质上返回 void,因此 async 方法返回 void,以便可以使用异步事件处理程序。 但是,async void 方法的一些语义与 async Task 或 async Task<T> 方法的语义略有不同。

Async void 方法具有不同的错误处理语义。 当 async Task 或 async Task<T> 方法引发异常时,会捕获该异常并将其置于 Task 对象上。 对于 async void 方法,没有 Task 对象,因此 async void 方法引发的任何异常都会直接在 SynchronizationContext(在 async void 方法启动时处于活动状态)上引发。 图 2 演示本质上无法捕获从 async void 方法引发的异常。

图 2 无法使用 Catch 捕获来自 Async Void 方法的异常

  1.  
  2.           private async void ThrowExceptionAsync()
  3. {
  4.   throw new InvalidOperationException();
  5. }
  6. public void AsyncVoidExceptions_CannotBeCaughtByCatch()
  7. {
  8.   try
  9.   {
  10.     ThrowExceptionAsync();
  11.   }
  12.   catch (Exception)
  13.   {
  14.     // The exception is never caught here!
  15.           throw;
  16.   }
  17. }
  18.         

可以通过对 GUI/ASP.NET 应用程序使用 AppDomain.UnhandledException 或类似的全部捕获事件观察到这些异常,但是使用这些事件进行常规异常处理会导致无法维护。

Async void 方法具有不同的组合语义。 返回 Task 或 Task<T> 的 async 方法可以使用 await、Task.WhenAny、Task.WhenAll 等方便地组合而成。 返回 void 的 async 方法未提供一种简单方式,用于向调用代码通知它们已完成。 启动几个 async void 方法不难,但是确定它们何时结束却不易。 Async void 方法会在启动和结束时通知 SynchronizationContext,但是对于常规应用程序代码而言,自定义 SynchronizationContext 是一种复杂的解决方案。

Async void 方法难以测试。 由于错误处理和组合方面的差异,因此调用 async void 方法的单元测试不易编写。 MSTest 异步测试支持仅适用于返回 Task 或 Task<T> 的 async 方法。 可以安装 SynchronizationContext 来检测所有 async void 方法都已完成的时间并收集所有异常,不过只需使 async void 方法改为返回 Task,这会简单得多。

显然,async void 方法与 async Task 方法相比具有几个缺点,但是这些方法在一种特定情况下十分有用: 异步事件处理程序。 语义方面的差异对于异步事件处理程序十分有意义。 它们会直接在 SynchronizationContext 上引发异常,这类似于同步事件处理程序的行为方式。 同步事件处理程序通常是私有的,因此无法组合或直接测试。 我喜欢采用的一个方法是尽量减少异步事件处理程序中的代码(例如,让它等待包含实际逻辑的 async Task 方法)。 下面的代码演示了这一方法,该方法通过将 async void 方法用于事件处理程序而不牺牲可测试性:

  1.  
  2.           private async void button1_Click(object sender, EventArgs e)
  3. {
  4.   await Button1ClickAsync();
  5. }
  6. public async Task Button1ClickAsync()
  7. {
  8.   // Do asynchronous work.
  9.           await Task.Delay(1000);
  10. }
  11.         

如果调用方不希望 async void 方法是异步的,则这些方法可能会造成严重影响。 当返回类型是 Task 时,调用方知道它在处理将来的操作;当返回类型是 void 时,调用方可能假设方法在返回时完成。 此问题可能会以许多意外方式出现。 在接口(或基类)上提供返回 void 的方法的 async 实现(或重写)通常是错误的。某些事件也假设其处理程序在返回时完成。 一个不易察觉的陷阱是将 async lambda 传递到采用 Action 参数的方法;在这种情况下,async lambda 返回 void 并继承 async void 方法的所有问题。 一般而言,仅当 async lambda 转换为返回 Task 的委托类型(例如,Func<Task>)时,才应使用 async lambda。

总结这第一个指导原则便是,应首选 async Task 而不是 async void。 Async Task 方法更便于实现错误处理、可组合性和可测试性。 此指导原则的例外情况是异步事件处理程序,这类处理程序必须返回 void。 此例外情况包括逻辑上是事件处理程序的方法,即使它们字面上不是事件处理程序(例如 ICommand.Execute implementations)。

异步代码让我想起了一个故事,有个人提出世界是悬浮在太空中的,但是一个老妇人立即提出质疑,她声称世界位于一个巨大乌龟的背上。 当这个人问乌龟站在哪里时,老夫人回答:“很聪明,年轻人,下面是一连串的乌龟!”在将同步代码转换为异步代码时,您会发现,如果异步代码调用其他异步代码并且被其他异步代码所调用,则效果最好 — 一路向下(或者也可以说“向上”)。 其他人已注意到异步编程的传播行为,并将其称为“传染”或将其与僵尸病毒进行比较。 无论是乌龟还是僵尸,无可置疑的是,异步代码趋向于推动周围的代码也成为异步代码。 此行为是所有类型的异步编程中所固有的,而不仅仅是新 async/await 关键字。

“始终异步”表示,在未慎重考虑后果的情况下,不应混合使用同步和异步代码。 具体而言,通过调用 Task.Wait 或 Task.Result 在异步代码上进行阻塞通常很糟糕。 对于在异步编程方面“浅尝辄止”的程序员,这是个特别常见的问题,他们仅仅转换一小部分应用程序,并采用同步 API 包装它,以便代码更改与应用程序的其余部分隔离。 不幸的是,他们会遇到与死锁有关的问题。 在 MSDN 论坛、Stack Overflow 和电子邮件中回答了许多与异步相关的问题之后,我可以说,迄今为止,这是异步初学者在了解基础知识之后最常提问的问题: “为何我的部分异步代码死锁?”

图 3 演示一个简单示例,其中一个方法发生阻塞,等待 async 方法的结果。 此代码仅在控制台应用程序中工作良好,但是在从 GUI 或 ASP.NET 上下文调用时会死锁。 此行为可能会令人困惑,尤其是通过调试程序单步执行时,这意味着没完没了的等待。 在调用 Task.Wait 时,导致死锁的实际原因在调用堆栈中上移。

图 3 在异步代码上阻塞时的常见死锁问题

  1.  
  2.           public static class DeadlockDemo
  3. {
  4.   private static async Task DelayAsync()
  5.   {
  6.     await Task.Delay(1000);
  7.   }
  8.   // This method causes a deadlock when called in a GUI or ASP.NET context.
  9.           public static void Test()
  10.   {
  11.     // Start the delay.
  12.           var delayTask = DelayAsync();
  13.     // Wait for the delay to complete.
  14.           delayTask.Wait();
  15.   }
  16. }
  17.         

这种死锁的根本原因是 await 处理上下文的方式。 默认情况下,当等待未完成的 Task 时,会捕获当前“上下文”,在 Task 完成时使用该上下文恢复方法的执行。 此“上下文”是当前 SynchronizationContext(除非它是 null,这种情况下则为当前 TaskScheduler)。 GUI 和 ASP.NET 应用程序具有 SynchronizationContext,它每次仅允许一个代码区块运行。 当 await 完成时,它会尝试在捕获的上下文中执行 async 方法的剩余部分。但是该上下文已含有一个线程,该线程在(同步)等待 async 方法完成。 它们相互等待对方,从而导致死锁。

请注意,控制台应用程序不会形成这种死锁。 它们具有线程池 SynchronizationContext 而不是每次执行一个区块的 SynchronizationContext,因此当 await 完成时,它会在线程池线程上安排 async 方法的剩余部分。该方法能够完成,并完成其返回任务,因此不存在死锁。 当程序员编写测试控制台程序,观察到部分异步代码按预期方式工作,然后将相同代码移动到 GUI 或 ASP.NET 应用程序中会发生死锁,此行为差异可能会令人困惑。

此问题的最佳解决方案是允许异步代码通过基本代码自然扩展。 如果采用此解决方案,则会看到异步代码扩展到其入口点(通常是事件处理程序或控制器操作)。 控制台应用程序不能完全采用此解决方案,因为 Main 方法不能是 async。 如果 Main 方法是 async,则可能会在完成之前返回,从而导致程序结束。 图 4演示了指导原则的这一例外情况: 控制台应用程序的 Main 方法是代码可以在异步方法上阻塞为数不多的几种情况之一。

图 4 Main 方法可以调用 Task.Wait 或 Task.Result

  1.  
  2.           class Program
  3. {
  4.   static void Main()
  5.   {
  6.     MainAsync().Wait();
  7.   }
  8.   static async Task MainAsync()
  9.   {
  10.     try
  11.     {
  12.       // Asynchronous implementation.
  13.           await Task.Delay(1000);
  14.     }
  15.     catch (Exception ex)
  16.     {
  17.       // Handle exceptions.
  18.           }
  19.   }
  20. }
  21.         

允许异步代码通过基本代码扩展是最佳解决方案,但是这意味着需进行许多初始工作,该应用程序才能体现出异步代码的实际好处。 可通过几种方法逐渐将大量基本代码转换为异步代码,但是这超出了本文的范围。在某些情况下,使用 Task.Wait 或 Task.Result 可能有助于进行部分转换,但是需要了解死锁问题以及错误处理问题。 我现在说明错误处理问题,并在本文后面演示如何避免死锁问题。

每个 Task 都会存储一个异常列表。 等待 Task 时,会重新引发第一个异常,因此可以捕获特定异常类型(如 InvalidOperationException)。 但是,在 Task 上使用 Task.Wait 或 Task.Result 同步阻塞时,所有异常都会用 AggregateException 包装后引发。 请再次参阅图 4。 MainAsync 中的 try/catch 会捕获特定异常类型,但是如果将 try/catch 置于 Main 中,则它会始终捕获 AggregateException。 当没有 AggregateException 时,错误处理要容易处理得多,因此我将“全局”try/catch 置于 MainAsync 中。

至此,我演示了两个与异步代码上阻塞有关的问题: 可能的死锁和更复杂的错误处理。 对于在 async 方法中使用阻塞代码,也有一个问题。 请考虑此简单示例:

  1.  
  2.           public static class NotFullyAsynchronousDemo
  3. {
  4.   // This method synchronously blocks a thread.
  5.           public static async Task TestNotFullyAsync()
  6.   {
  7.     await Task.Yield();
  8.     Thread.Sleep(5000);
  9.   }
  10. }
  11.         

此方法不是完全异步的。 它会立即放弃,返回未完成的任务,但是当它恢复执行时,会同步阻塞线程正在运行的任何内容。 如果此方法是从 GUI 上下文调用,则它会阻塞 GUI 线程;如果是从 ASP.NET 请求上下文调用,则会阻塞当前 ASP.NET 请求线程。 如果异步代码不同步阻塞,则其工作效果最佳。 图 5 是将同步操作替换为异步替换的速查表。

图 5 执行操作的“异步方式”

执行以下操作…

替换以下方式…

使用以下方式

检索后台任务的结果

Task.Wait 或 Task.Result

await

等待任何任务完成

Task.WaitAny

await Task.WhenAny

检索多个任务的结果

Task.WaitAll

await Task.WhenAll

等待一段时间

Thread.Sleep

await Task.Delay

总结这第二个指导原则便是,应避免混合使用异步代码和阻塞代码。 混合异步代码和阻塞代码可能会导致死锁、更复杂的错误处理及上下文线程的意外阻塞。 此指导原则的例外情况是控制台应用程序的 Main 方法,或是(如果是高级用户)管理部分异步的基本代码。

在本文前面,我简要说明了当等待未完成 Task 时默认情况下如何捕获“上下文”,以及此捕获的上下文用于恢复 async 方法的执行。 图 3 中的示例演示在上下文上的恢复执行如何与同步阻塞发生冲突从而导致死锁。此上下文行为还可能会导致另一个问题 — 性能问题。 随着异步 GUI 应用程序在不断增长,可能会发现 async 方法的许多小部件都在使用 GUI 线程作为其上下文。 这可能会形成迟滞,因为会由于“成千上万的剪纸”而降低响应性。

若要缓解此问题,请尽可能等待 ConfigureAwait 的结果。 下面的代码段说明了默认上下文行为和 ConfigureAwait 的用法:

  1.  
  2.           async Task MyMethodAsync()
  3. {
  4.   // Code here runs in the original context.
  5.           await Task.Delay(1000);
  6.   // Code here runs in the original context.
  7.           await Task.Delay(1000).ConfigureAwait(
  8.     continueOnCapturedContext: false);
  9.   // Code here runs without the original
  10.   // context (in this case, on the thread pool).
  11.           }
  12.         

通过使用 ConfigureAwait,可以实现少量并行性: 某些异步代码可以与 GUI 线程并行运行,而不是不断塞入零碎的工作。

除了性能之外,ConfigureAwait 还具有另一个重要方面: 它可以避免死锁。 再次考虑图 3;如果向 DelayAsync 中的代码行添加“ConfigureAwait(false)”,则可避免死锁。 此时,当等待完成时,它会尝试在线程池上下文中执行 async 方法的剩余部分。 该方法能够完成,并完成其返回任务,因此不存在死锁。 如果需要逐渐将应用程序从同步转换为异步,则此方法会特别有用。

如果可以在方法中的某处使用 ConfigureAwait,则建议对该方法中此后的每个 await 都使用它。 前面曾提到,如果等待未完成的 Task,则会捕获上下文;如果 Task 已完成,则不会捕获上下文。 在不同硬件和网络情况下,某些任务的完成速度可能比预期速度更快,需要谨慎处理在等待之前完成的返回任务。 图 6 显示了一个修改后的示例。

图 6 处理在等待之前完成的返回任务

  1.  
  2.           async Task MyMethodAsync()
  3. {
  4.   // Code here runs in the original context.
  5.           await Task.FromResult(1);
  6.   // Code here runs in the original context.
  7.           await Task.FromResult(1).ConfigureAwait(continueOnCapturedContext: false);
  8.   // Code here runs in the original context.
  9.           var random = new Random();
  10.   int delay = random.Next(2); // Delay is either 0 or 1
  11.   await Task.Delay(delay).ConfigureAwait(continueOnCapturedContext: false);
  12.   // Code here might or might not run in the original context.
  13.           // The same is true when you await any Task
  14.   // that might complete very quickly.
  15.           }
  16.         

如果方法中在 await 之后具有需要上下文的代码,则不应使用 ConfigureAwait。 对于 GUI 应用程序,包括任何操作 GUI 元素、编写数据绑定属性或取决于特定于 GUI 的类型(如 Dispatcher/CoreDispatcher)的代码。 对于 ASP.NET 应用程序,这包括任何使用 HttpContext.Current 或构建 ASP.NET 响应的代码(包括控制器操作中的返回语句)。 图 7 演示 GUI 应用程序中的一个常见模式:让 async 事件处理程序在方法开始时禁用其控制,执行某些 await,然后在处理程序结束时重新启用其控制;因为这一点,事件处理程序不能放弃其上下文。

图 7 让 async 事件处理程序禁用并重新启用其控制

  1.  
  2.           private async void button1_Click(object sender, EventArgs e)
  3. {
  4.   button1.Enabled = false;
  5.   try
  6.   {
  7.     // Can’t use ConfigureAwait here …
  8.           await Task.Delay(1000);
  9.   }
  10.   finally
  11.   {
  12.     // Because we need the context here.
  13.           button1.Enabled = true;
  14.   }
  15. }
  16.         

每个 async 方法都具有自己的上下文,因此如果一个 async 方法调用另一个 async 方法,则其上下文是独立的。 图 8 演示的代码对图 7 进行了少量改动。

图 8 每个 async 方法都具有自己的上下文

  1.  
  2.           private async Task HandleClickAsync()
  3. {
  4.   // Can use ConfigureAwait here.
  5.           await Task.Delay(1000).ConfigureAwait(continueOnCapturedContext: false);
  6. }
  7. private async void button1_Click(object sender, EventArgs e)
  8. {
  9.   button1.Enabled = false;
  10.   try
  11.   {
  12.     // Can’t use ConfigureAwait here.
  13.           await HandleClickAsync();
  14.   }
  15.   finally
  16.   {
  17.     // We are back on the original context for this method.
  18.           button1.Enabled = true;
  19.   }
  20. }
  21.         

无上下文的代码可重用性更高。 尝试在代码中隔离上下文相关代码与无上下文的代码,并尽可能减少上下文相关代码。 在图 8 中,建议将事件处理程序的所有核心逻辑都置于一个可测试且无上下文的 async Task 方法中,仅在上下文相关事件处理程序中保留最少量的代码。 即使是编写 ASP.NET 应用程序,如果存在一个可能与桌面应用程序共享的核心库,请考虑在库代码中使用 ConfigureAwait。

总结这第三个指导原则便是,应尽可能使用 Configure­Await。 无上下文的代码对于 GUI 应用程序具有最佳性能,是一种可在使用部分 async 基本代码时避免死锁的方法。 此指导原则的例外情况是需要上下文的方法。

关于 async 和 await 有许多需要了解的内容,这自然会有点迷失方向。 图 9 是常见问题的解决方案的快速参考。

图 9 常见异步问题的解决方案

问题

解决方案

创建任务以执行代码

Task.Run 或 TaskFactory.StartNew(不是 Task 构造函数或 Task.Start)

为操作或事件创建任务包装

TaskFactory.FromAsync 或 TaskCompletionSource<T>

支持取消

CancellationTokenSource 和 CancellationToken

报告进度

IProgress<T> 和 Progress<T>

处理数据流

TPL 数据流或被动扩展

同步对共享资源的访问

SemaphoreSlim

异步初始化资源

AsyncLazy<T>

异步就绪生产者/使用者结构

TPL 数据流或 AsyncCollection<T>

第一个问题是任务创建。 显然,async 方法可以创建任务,这是最简单的选项。 如果需要在线程池上运行代码,请使用 Task.Run 如果要为现有异步操作或事件创建任务包装,请使用 TaskCompletionSource<T>。下一个常见问题是如何处理取消和进度报告。 基类库 (BCL) 包括专门用于解决这些问题的类型: CancellationTokenSource/CancellationToken IProgress<T>/Progress<T> 异步代码应使用基于任务的异步模式(或称为 TAPmsdn.microsoft.com/library/hh873175),该模式详细说明了任务创建、取消和进度报告。

出现的另一个问题是如何处理异步数据流。 任务很棒,但是只能返回一个对象并且只能完成一次。 对于异步流,可以使用 TPL 数据流或被动扩展 (Rx)。 TPL 数据流会创建类似于主角的“网格”。 Rx 更加强大和高效,不过也更加难以学习。 TPL 数据流和 Rx 都具有异步就绪方法,十分适用于异步代码。

仅仅因为代码是异步的,并不意味着就安全。 共享资源仍需要受到保护,由于无法在锁中等待,因此这比较复杂。 下面是一个异步代码示例,该代码如果执行两次,则可能会破坏共享状态,即使始终在同一个线程上运行也是如此:

int value;

Task<int> GetNextValueAsync(int current);

async Task UpdateValueAsync()

{

  value = await GetNextValueAsync(value);

}

问题在于,方法读取值并在等待时挂起自己,当方法恢复执行时,它假设值未更改。 为了解决此问题,使用异步就绪 WaitAsync 重载扩展了 SemaphoreSlim 类。 图 10 演示 SemaphoreSlim.WaitAsync。

图 10 SemaphoreSlim 允许异步同步

SemaphoreSlim mutex = new SemaphoreSlim(1);

int value;

Task<int> GetNextValueAsync(int current);

async Task UpdateValueAsync()

{

  await mutex.WaitAsync().ConfigureAwait(false);

  try

  {

    value = await GetNextValueAsync(value);

  }

  finally

  {

    mutex.Release();

  }

}

异步代码通常用于初始化随后会缓存并共享的资源。 没有用于此用途的内置类型,但是 Stephen Toub 开发了 AsyncLazy<T>,其行为相当于 Task<T> Lazy<T> 合二为一。 该原始类型在其博客 (bit.ly/dEN178) 上进行了介绍,并且在我的 AsyncEx (nitoasyncex.codeplex.com) 中提供了更新版本。

最后,有时需要某些异步就绪数据结构。 TPL 数据流提供了 BufferBlock<T>,其行为如同异步就绪生产者/使用者队列。 而 AsyncEx 提供了 AsyncCollection<T>,这是异步版本的 BlockingCollection<T>。

我希望本文中的指导原则和指示能有所帮助。 异步真的是非常棒的语言功能,现在正是开始使用它的好时机!

TCP粘包/拆包问题的解决办法

一、什么是TCP粘包/拆包

如图所示,假如客户端分别发送两个数据包D1和D2给服务端,由于服务端一次读取到的字节数是不确定的,故可能存在以下4中情况:

  • 第一种情况:Server端分别读取到D1和D2,没有产生粘包和拆包的情况。
  • 第二种情况:Server端一次接收到两个数据包,D1和D2粘合在一起,被称为TCP粘包。
  • 第三种情况:Server端分2次读取到2个数据包,第一次读取到D1包和D2包的部分内容D2_1,第二次读取到D2包的剩余内容,被称为TCP拆包。
  • 第四中情况:Server端分2次读取到2个数据包,第一次读取到D1包的部分内容D1_1 ,第二次读取到D1包的剩余内容D1_2和D2包的整包。

如果此时服务端TCP接收滑动窗非常小,而数据包D1和D2都很大,很有可能发送第五种可能,即服务端多次才能把D1和D2接收完全,期间多次发生拆包情况。(TCP接收滑动窗:是接收端的大小,随着流量大小而变化,如果我的解释还不明确,请读者自行百度,或者查阅《计算机网络》、《TCP/IP》中TCP的内容)

粘包问题的解决策略

由于底层的TCP无法理解上层的业务逻辑,所以在底层是无法确保数据包不被拆分和重组的,这个问题只能通过上层的应用协议栈设计来解决,根据业界的主流协议的解决方案,归纳如下:

  • 1.消息定长,例如每个报文的大小为固定长度200字节,如果不够,空位补空格;
  • 2.在包尾增加回车换行符进行分割,例如FTP协议;
  • 3.将消息分为消息头和消息体,消息头中包含表示消息总长度(或者消息体长度)的字段,通常设计思路是消息头的第一个字段用int来表示消息的总长度;(我之前linux C开发,就用的这种)。
  • 4.更复杂的应用层协议;