博客园_小城岁月

WCF X.509证书创建与IIS宿主设置

2012-01-17T03:48:00Z

首先说明，仅仅使用证书只解决了数据明文安全问题的，但请求是否合法，还要通过其它手段，如：双向证书验证或者证书+用户验证的方案

VS控制台下创建证书示意：

1，默认创建证书 makecert -n "CN=www.ecepdi.com" Wcf_EdocFileService.cer (-n搬发给)

2, 创建自签名搬发者证书 makecert -n "CN=www.ecepdi.com" -r Wcf_EdocFileService.cer (-r代表自签署)

3,创建带私钥部分.pvk的证书 makecert -n "CN=www.ecepdi.com" -r -sv Wcf_EdocFileService.pvk Wcf_EdocFileService.cer

4,创建指定位置证书 makecert -r -pe -n "CN=www.ecepdi.com" -sr LocalMachine -ss My -sky exchange (-sr 位置 -n 存储位置)

参数明细参与

MSDN http://msdn.microsoft.com/zh-cn/bfsktky3(vs.80).aspx

如果是IIS做宿主的话最好采好第4种方式，将证书生成到LocalMachine 下My目录，因为放到CurrentUser/My 下即使设置了密钥的Newwork Service/IIS_USER权限也没法正常读取密钥，

所以建议生成到LocalMachine/My下 makecert -r -pe -n "CN=www.ecepdi.com" -sr LocalMachine -ss My -sky exchange

完成证书制作后，可以通过mmc添加单元->证书->添加本地计算机找到个人下刚生成的证书。

你可以将证书复制到其它受信区（个人/受信人/受信任的搬发机构等），只要设置好对应的WCF节点指向这些区，当然设置None就会检索所有区域

<authentication certificateValidationMode="None"/> 可以访问所有受信区，如果需要设置固定位置，则证书位置与WCF此节点设置要一致

设置IIS宿主对密钥访问权限

此时WCF IIS宿主仍无法读取到读取密钥可以借助下面两种方式实现

1，下载FindPrivateKey.exe工具，通过命令查找指定证书

FindPrivateKey My LocalMachine -n "CN=www.ecepdi.com" 或

FindPrivateKey My LocalMachine -t "指纹密钥"

查找到对应的密钥存放位置，然后找到此文件，在文件属性安全添加Network Service/IIS_USERS 用户的读权限

2.下载winhttpcertcfg.exe工具（还要设置IIS_USERS的权限）

WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "证书名" -a Network Service

设置完成后，IIS宿主不是马上就可以访问密钥，所以不要急，可以iisreset命令重启IIS

此时在IIS宿主就可以正常访问WCF服务了，平时在VS调试时，大家用的都是VS的服务器，所以不会碰到此类问题，但部署到IIS就发现不能正常访问了。

建议WEB开发时，把项目属性->WEB->使用本地IIS WEB服务器，以免碰到VS里调试正常但到IIS就不正常了，就不知道怎么回事了。

使用证书应避免客户端与服务端时间差超过5分钟,当两端时间相差过长,则会证书安全错误.(可能原因加密过期)

WCF IIS 站点x.509证书Web.config配置

服务端:

<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="wsHttpEndpointBinding">
<security>
<message clientCredentialType="Certificate" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<services>
<service name="DemoService.FileService" behaviorConfiguration="DemoService.FileServiceBehavior">
<endpoint address="" binding="wsHttpBinding" contract="DemoService.IFileService" bindingConfiguration="wsHttpEndpointBinding">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="DemoService.FileServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None"/>
</clientCertificate>
<serviceCertificate findValue="WcfServer"
storeLocation="LocalMachine"
storeName="My"
x509FindType="FindBySubjectName" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>

客户端：

<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IFileService" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="1073741824"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="1073741824"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Certificate" negotiateServiceCredential="true"
algorithmSuite="Default" establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:8066/DemoService/FileService.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IFileService"
contract="Edoc.IFileService" name="WSHttpBinding_IFileService"
behaviorConfiguration="WSHttpBinding_IFileService" >
<identity>
<dns value="WcfServer" />
</identity>
</endpoint>
</client>
<behaviors>
<endpointBehaviors>
<behavior name="WSHttpBinding_IFileService">
<clientCredentials>
<clientCertificate findValue="WcfServer" x509FindType="FindBySubjectName" storeLocation="LocalMachine" storeName="My"/>
<serviceCertificate>
<authentication certificateValidationMode="None"/>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>

在测试过程中，客户端配置 <identity> <dns value="WcfServer" /></identity> 会被要求设置指向服务端的证书名，所以DNS这个位置不是IP地址而服务端的证书名。

WCF IIS站点双向证书配置

服务端:

<system.serviceModel>
<services>
<service behaviorConfiguration="DocumentFileService.FileServiceBehavior"
name="DocumentFileService.FileService">
<endpoint address="" binding="wsHttpBinding" contract="DocumentFileService.IFileService" bindingConfiguration="DocumentFileService.IFileService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="DocumentFileService.FileServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
<serviceThrottling maxConcurrentCalls="1000" maxConcurrentSessions="1000" maxConcurrentInstances ="1000"/> 
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="Custom" customCertificateValidatorType="DocumentFileService.ServiceX509CertificateValidator,DocumentFileService"/>
</clientCertificate>
<serviceCertificate findValue="EdocFileServer" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="DocumentFileService.IFileService">
<security mode="Message">
<message clientCredentialType="Certificate" />
</security>
</binding>
</wsHttpBinding>
</bindings>
</system.serviceModel>

客户端:

<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IFileService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288" maxReceivedMessageSize="1073741824" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="1073741824" maxBytesPerRead="4096" maxNameTableCharCount="16384"/>
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm=""/>
<message clientCredentialType="Certificate" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://ecepdi-da2:8066/FileService.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IFileService" contract="EdocFileService.IFileService" name="WSHttpBinding_IFileService" behaviorConfiguration="WSHttpBinding_IFileService">
<identity>
<dns value="EdocFileServer"/>
</identity>
</endpoint>
</client>
<behaviors>
<endpointBehaviors>
<behavior name="WSHttpBinding_IFileService">
<clientCredentials>
<clientCertificate findValue="EdocFileClient" x509FindType="FindBySubjectName" storeLocation="LocalMachine" storeName="My"/>
<serviceCertificate>
<authentication certificateValidationMode="Custom" customCertificateValidatorType="ECEPDI.Document.WCF_X509.ClientX509CertificateValidator,ECEPDI.Document"/>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>

本文链接

CLR Via笔记之ThreadPool/Task

2011-11-18T05:46:00Z

ThreadPool 是MTA设计，不像STA线程可以支持Com Interop互操作。而Task是ThreadPool的再封装简化，两者都支持异步取消的操作。

ThreadPool 通过CancellationTokenSource 取消线程操作

private static void CancellingAWorkItem() {
CancellationTokenSource cts = new CancellationTokenSource();
ThreadPool.QueueUserWorkItem(o => Count(cts.Token, 1000));
//取消线程
cts.Cancel();

}

private static void Count(CancellationToken token, Int32 countTo) {
for (Int32 count = 0; count < countTo; count++) {
//终止线程
if (token.IsCancellationRequested) {
break;
}
Thread.Sleep(200); // For demo, waste some time
}
}

如果在取消时还想通知或调用的其它的方法，可以针对CancellationTokenSource.Token.Register 的注册回调的方法

CancellationTokenSource cts = new CancellationTokenSource();
cts.Token.Register(() => Console.WriteLine("已经取消方法执行1"));
cts.Token.Register(() => Console.WriteLine("已经取消方法执行2"));
//执行取消操作
cts.Cancel();
//上面注册的两个Console.WriteLine会被执行

Task并行任务的处理（Task,Task<> 同Action,Func<>相似）,Task<>的返回结果为委托函数的返回结果

private static void DoTask() {
//创建任务
Task<Int32> t = new Task<Int32>(n => Sum((Int32)n), 10000);
t.Start();
//阻塞等待任务执行完成
t.Wait();
Console.WriteLine("The sum is: " + t.Result); // An Int32 value
}

private static Int32 Sum(Int32 n)
{
Int32 sum = 0;
for (; n > 0; n--) checked { sum += n; }
return sum;
}

PS: Task有个IsCompleted属性，也可通过循环判断这个属性来阻塞线程。但是循环判断比Wait更浪费性能，唤醒线程毕况要比轮询调度CPU要有效率，即使你在轮询判断中增加主线程Sleep也是额外的一种消耗。

这点和异步编程模型APM很像，比如在异步执行BeginInvoke时，你可以调用EndInvoke阻塞主线程，也可以根据BeginInvoke的IAsyncReult.IsCompleted属性阻塞线程。

Task用一系的属性来定位异步任务的是以何种情况完成的 IsFaulted/IsCompleted/IsCanceled. 因此除了任务属性直接判断一个任务的完成情况，我们还可以通过后续任务观察前一个任务是何种方式完成的，是否有异常情况。

Task.ContinueWith((task) => { var _error = task.Exception; }, TaskContinuationOptions.OnlyOnFaulted);
Task.ContinueWith(task => { var _error = task.Exception; }, TaskContinuationOptions.OnlyOnCanceled);

Task取消任务的异步操作，同样是利用CancellationTokenSource

private static void CancelTask() {
CancellationTokenSource cts = new CancellationTokenSource();
Task<Int32> t = new Task<Int32>(() => Sum(cts.Token, 10000), cts.Token);
t.Start();

//取消异步任务
cts.Cancel();

try {
//由于异步任务被取消，任务未正常完成，因此取任务结果会扔出AggregateException异常
Console.WriteLine("The sum is: " + t.Result);
}
catch (AggregateException ae) {
ae.Handle(e => e is OperationCanceledException);
Console.WriteLine("Sum was canceled");
}
}

private static Int32 Sum(CancellationToken ct, Int32 n)
{
Int32 sum = 0;
for (; n > 0; n--)
{
ct.ThrowIfCancellationRequested();

checked { sum += n; }
}
return sum;
}

Task任务结束/中断/异常时等，以这个Task任务做为另一个任务开始的参数，可以通过Task.ContinueWith启动另一个任务执行。

private static void ContinueWith() {

Task<Int32> t = new Task<Int32>(n => Sum((Int32)n), 10000);
t.Start();

Task cwt = t.ContinueWith(task => Console.WriteLine("The sum is: " + task.Result));
cwt.Wait();
}

PS：Task.ContinueWith有多个重载，其中第6个重载枚举参数TaskContinuationOptions 可以控制在多种情况下延续任务执行，比如在异常/完成/取消/才执行另外的一个任务

Task并行多个子任务（比如类似多线程下载的情况：不停的阻塞主线程任务，并且跟踪所有子线程完任务成情况），当然我们用线程也可以解决这些问题，但是 Task简化了这些代码，优化了线程资源使用与回收。

private static void ParentChildTaskDemo() {
Task<Int32[]> parent = new Task<Int32[]>(() => {
var results = new Int32[3];

new Task(() => results[0] = Sum(10000), TaskCreationOptions.AttachedToParent).Start();
new Task(() => results[1] = Sum(20000), TaskCreationOptions.AttachedToParent).Start();
new Task(() => results[2] = Sum(30000), TaskCreationOptions.AttachedToParent).Start();

return results;
});

//ContinueWith的任务必须等Parent下的所有子任务全部执行完成才会触发
var cwt = parent.ContinueWith(parentTask => Array.ForEach(parentTask.Result, Console.WriteLine));
//开启并行多任务
parent.Start();
//等待所有任务执行完成
cwt.Wait();
}

枚举TaskCreationOptions，指定了子任务以何种方式创建与执行。当然还可以利用TaskFactory实现上述方式

Task<Int32[]> parent = new Task<Int32[]>(() => {
var results = new Int32[3];
var cts = new CancellationTokenSource();
//var tf = new TaskFactory<Int32>(cts.Token, TaskCreationOptions.AttachedToParent, TaskContinuationOptions.ExecuteSynchronously, TaskScheduler.Default);
//var tf = new TaskFactory<Int32>();
//var tf = new TaskFactory<Int32>(cts.Token);
var tf = new TaskFactory<Int32>(TaskCreationOptions.AttachedToParent, TaskContinuationOptions.ExecuteSynchronously);

var childTasks = new[] {
tf.StartNew(() => results[0] = Sum(10000)),
tf.StartNew(() => results[1] = Sum(20000)),
tf.StartNew(() => results[2] = Sum(30000))

};
return results;
});

当然你还可以变态点这么写

Task parent = Task.Factory.StartNew(
() => Task.Factory.StartNew(
() => Task.Factory.StartNew(
()=>Task.Factory.StartNew(
o=>Console.WriteLine(o.ToString()),"测试"
))));

Task还支持异步编程模型（APM），参照这段代码

Task.Factory.FromAsync<WebResponse>(webRequest.BeginGetResponse, webRequest.EndGetResponse, null, TaskCreationOptions.None);

Task.Factory.FromAsync的其中一个重载首个参数为异步模型BeginInvoke方法，第二个参数为EndInvoke方法，第三个参数object为首个方法的参数，第四个参数为任务类型枚举，其返回类型为第二个方法的返回类型。

Task的延续任务及工厂方式支持异步UI操作 TaskContinuationOptions.ExecuteSynchronously/ TaskScheduler.FromCurrentSynchronizationContext()

上面仅是CLR的读书笔记，想了解很多理论知识，可以参考CLR Via这本MVP联袂推荐的书。

Task相比手动ThreadPool/Thread编码简化了一系列任务的并行与串行执行问题，以及子任务的执行情况的控制回调变得相对容易。下面是很久以前写的一个多线程同步数据的例子，原理就是通过线程任务集合对象的所有属性的Finish情况来阻塞等待执行最后的任务。4.0编程下Task方便了这些操作，但是3.5以下我们仍然只能这样实现。

public abstract class MultiThreadWork
{

public void StartThreadWork(DataTable dtQueue, int taskCount, string userId, string userName)
{
try
{
//初始线程范围条件计算每个线程应该接收范围大小
int averageSize = dtQueue.Rows.Count / taskCount;//平均分配
int lastSize = averageSize + dtQueue.Rows.Count % taskCount;//剩余部分由最后一个线程完成

//生成参数线程对象
List<WorkItem> list = new List<WorkItem>();
for (int i = 0; i < taskCount; i++)
{
WorkItem item = new WorkItem();

item.DtQueue = dtQueue;
item.IsFinish = false;
item.UserId = userId;
item.UserName = userName;

item.StarIndex = averageSize * i;//每个线程接起始点
if (i < taskCount - 1)
item.EndIndex = item.StarIndex + averageSize;//每个线程接收结束点
else
item.EndIndex = item.StarIndex + lastSize; //最后一个结束点

list.Add(item);
}

//开启工作线程
foreach (WorkItem item in list)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(DoWork), item);
}

//阻塞主线程等待所有子线程结束
while (true)
{
//bool isAllFinish = true;

if (!list.Exists(o => o.IsFinish == false))
break;
else
Thread.Sleep(500);

}

//通知订阅对象
AllWorkEventArgs args = new AllWorkEventArgs
{
DtQueue = dtQueue,
IsError = false
};
this.AllFinishNotify(args);

}
catch (Exception ex)
{
//通知订阅对象
AllWorkEventArgs args = new AllWorkEventArgs
{
DtQueue = dtQueue,
IsError = true,
ErrorInfo = ex.Message
};
this.AllErrorNotify(args);
}
}

/// <summary>
/// 任务工作方式
/// </summary>
/// <param name="state"></param>
public virtual void DoWork(object state)
{
WorkItem item = state as WorkItem;
try
{

//ClientFileService service = new ClientFileService();
//service.UploadFile(item.QueueList, item.StarIndex, item.EndIndex, item.UserId, item.UserName);

//通知订阅对象
WorkEventArgs args = new WorkEventArgs();
args.IsError = false;
args.WorkItem = item;
this.SubFinishNotity(args);
}
catch (Exception ex)
{
//通知订阅对象
WorkEventArgs args = new WorkEventArgs();
args.IsError = true;
args.ErrorInfo = ex.Message;
args.WorkItem = item;
this.SubErrorNotify(args);
}
finally
{
//子线程完成标志
item.IsFinish = true;
}

}

#region 通知事件

/// <summary>
/// 错误通知
/// </summary>
public event EventHandler<WorkEventArgs> SubError;
/// <summary>
/// 全部下载完成通知
/// </summary>
public event EventHandler<AllWorkEventArgs> AllFinished;
/// <summary>
/// 子线程完成通知
/// </summary>
public event EventHandler<WorkEventArgs> SubFinished;

public event EventHandler<AllWorkEventArgs> AllError;

/// <summary>
/// 全部任务完成触发事件通知方法
/// </summary>
protected void AllFinishNotify(AllWorkEventArgs args)
{
if (AllFinished != null)
{
AllFinished(this, args);
}
}

protected void AllErrorNotify(AllWorkEventArgs args)
{
if (AllError != null)
{
AllError(this, args);
}
}

/// <summary>
/// 子任务线程出错触发事件通知方法
/// <param name="args"></param>
protected void SubErrorNotify(WorkEventArgs args)
{
if (SubError != null)
{
SubError(this, args);
}
}

/// <summary>
/// 子任务线程完成触发事件通知方法
/// </summary>
/// <param name="args"></param>
protected void SubFinishNotity(WorkEventArgs args)
{
if (SubFinished != null)
{
SubFinished(this, args);
}
}
#endregion
}

本文链接

CLR Via笔记之.NET 4.0 并行Parallel

2011-11-16T03:56:00Z

4.0特性中扩展了并行任务处理，其实就是封装了ThreadPool的Task。园子里有很多介绍Parallel的并行计算，其实我更看好并行查询PLINQ。做过复杂SQL拼接报表的人应该深有体会，当复杂的SQL执行时间过长，你怎么做呢？当存储过程优化后的执行时间还是让人无法接受呢？之前的解决方案是将复杂的SQL拆分成几段（可能是多张表）分别并行执行，将查询结果加载至内存，利用LINQ处理获取交集数据最终达到目的，当然这个是牺牲内存的方式达到目的，但是如果查询的数据短期不会有太大变化时，这种方式解决查询速度过慢肯定是个较好的方案。而PLINQ在此基础上又进一步扩大了LINQ战果。下面是PLINQ 150W条记录查询测试代码与结果

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Practices.Unity;
using ECEPDI.Document.Application.FileModule;
using ECEPDI.Document.Infrastructure.UnitOfWork;
using ECEPDI.Document.Infrastructure.Repositories;
using ECEPDI.Document.Domain.Entities;
using System.Threading.Tasks;
using System.Diagnostics;

namespace ScanFileUploadDemo
{
class Program
{
static void Main(string[] args)
{
ScanFileRepository processRepository = Container.Current.Resolve(typeof(ScanFileRepository)) as ScanFileRepository;
Stopwatch sw = new Stopwatch();
sw.Start();
var query = processRepository.GetFiltered(o => o.FileName.Contains("F201502S-K0518"));
Console.WriteLine("直接查询结果:" + query.Count().ToString());
sw.Stop();
Console.WriteLine("直接查询数据用时：" + sw.ElapsedMilliseconds / 1000d);

sw.Reset();
sw.Start();
List<ScanFile> list = processRepository.GetAll().ToList();
sw.Stop();
Console.WriteLine("加载数据用时：" + sw.ElapsedMilliseconds / 1000d);

Console.WriteLine("-------------------------------------------------");
sw.Reset();
sw.Start();
var result = from u in list
where u.FileName.Contains("F201502S-K0518")
select u;
Console.WriteLine("单行查询结果:" + result.Count().ToString());
sw.Stop();
Console.WriteLine("单行查询用时:" + sw.ElapsedMilliseconds / 1000d);

Console.WriteLine("-------------------------------------------------");
sw.Reset();
sw.Start();
var result2 = from u in list.AsParallel()
where u.FileName.Contains("F201502S-K0518")
select u;
Console.WriteLine("并行查询结果:" + result2.Count().ToString());
sw.Stop();
Console.WriteLine("并行查询用时:" + sw.ElapsedMilliseconds / 1000d);

Console.ReadLine();
}

}
}

用时情况：

直接查询结果是生成SQL语句到数据库中查询，结果为5.453 而数据库直接执行相同SQL语然却用时7秒

LINQ内存单行查询结果仅为0.31秒，但是前提是数据必须加载到内存中。

PLINQ内存并行查询结果为0.114秒，优势非常明显。但是PLINQ并行查询结果排列是无序的（打乱了原先的单行查询结果的顺序），由于每个线程完成时间不一致，导致多个线程查询后合并的结果是无序的。

PLINQ提供了对查询结果的再排序AsOrdered ，当然这会损失一点优势。

Parallel.For/Parallel.ForEach 在现有的情况中很难表现中并行的优势，相比Parallel.Invoke的却有很多的表现机会。对于并行查询和并行任务的应用性能效率提高需要要远多于For/Foreach情况。

Parallel.Invoke 同Tasks一样，在并行任务处理中是个好的选择。

Test1();
Test2();
Test3();

//3件事同时做肯定要比一件一件来的快嘛
Parallel.Invoke(
() => Test1(),
() => Test2(),
() => Test3());

//Parallel.For/Parallel.Foreach 在普通的遍历中并不能发挥的太多的优势（以下情况反而不如For/Foreach)
Stopwatch sw = new Stopwatch();
sw.Start();
for (Int32 i = 0; i < 1000; i++) DoWork(i);
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds / 1000d);

sw.Reset();
sw.Start();
Parallel.For(0, 1000, i => DoWork(i));
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds / 1000d);

var collection = new Int32[0];
sw.Reset();
sw.Start();
foreach (var item in collection) DoWork(item);
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds / 1000d);

sw.Reset();
sw.Start();
Parallel.ForEach(collection, item => DoWork(item));
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds / 1000d);

PS：复杂的SQL语句以及存储过程报表，在写的时候非常清楚，但是过段时间再回来改的时候连自己也看不懂了-_-|||。

本文链接

.NET 序列化与反序化

2011-11-12T17:34:00Z

序列化与反序化目的是为了解决对象的传递与持久化操作，如在不同的进程，应用程序哉，服务间传递，对象的保存与状态还原.

.net 环境下提供的序列化方式至3.5版本，有二进制，SOAP，XML，DataContract，JavaScript等，开源的有如Json.net等。当然也有自己手动反射实现的，比如利用MemberInfo，或者FormatterServices （二进制，SOAP等方式是封装了FormatterServices 的操作）。以上的几中方式处理序列化的对象都有不同的要求，二进制，SOAP，XML方式要求对象必须属性标记可序列化[Serializable]，而DataContract，JavaScript则虽然没有强制这种要求，但是Serializable，NonSerialized，OnSerializing，OnDeserialized等属性标记仍然在DataContract，JavaScript格化器执行中有效。

ps:序列化与反序列化的对象是原对象的副本，并不是引用。封送传值的对象是要求必须可序列化的。

PS:属性标记 Attribute 在编译时是直接构建带构造参数的Attribute的实例写入元数据及IL中。所以在反射获取的都是Attribute的实例。可以通过Type.IsDefined判断是否标记过属性，这种效率最高。当然还可以通过GetCustomAttribute（获取实例并可以操作）/GetCustomAttributeData（只获取反射实例，但不操作）

在序列化和反序化的过程，可以对序列化过程做一些其它特殊处理操作。看下面示例的注释

[Serializable]
private class Demo {

[NonSerialized]
private string name;
public string Name
{
get { return name; }
set { name = value; }
}

[OnSerializing] //被序列化时会执行的方式解决一些特殊的情况处理
private void OnSerializing(StreamingContext context) { }
[OnSerialized] //序列化完成后会调用的方法解决一些特殊的情况处理
private void OnSerialized(StreamingContext context) { }

[OnDeserializing] //被反序列化时会执行的方式解决一些特殊的情况处理
private void OnDeserializing(StreamingContext context) { }
[OnDeserialized] //被反序列化完成后执行的方式解决一些特殊的情况处理
private void OnDeserialized(StreamingContext context) { }
}

1.微软提供直接实现序列化与反序列化的实现

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Serialization.Formatters.Binary;
using System.Runtime.Serialization.Formatters.Soap;
using System.Xml.Serialization;
using System.Web;

namespace EFTool.Test
{
///<summary>
/// 序列化与反序列化帮助类（二进制，SOAP,XML，DataContract格式化操作类）
/// SOAP在3.5以后废弃，取而代之尽量使用XmlSerializer,DataContractSerializer.
/// 流格式化可以选择多种方式如FileStream,MemoryStream等
/// 封送传值的对象要求必须可序列化标记（副本)，而封送引用的对象可以通过继承MarshalbyRefObject(代理)
///</summary>
public static class SerializationHelper
{
#region 二进制方式对象必须标记为Serializable
///<summary>
/// 以二进制序列化对象(不必知道对象的具体类型)
///</summary>
///<param name="graph">对象必须标记为Serializable</param>
///<returns></returns>
public static Stream SerializeByBinary(object graph)
{
MemoryStream memoryStream = new MemoryStream();
IRemotingFormatter formatter = new BinaryFormatter();
formatter.Serialize(memoryStream, graph); //已完成序列化到流中（此处我们借助其它的流格式，比如说FileStream 将序列化数据转至文件中）
//Byte[] arrGraph = memoryStream.ToArray(); //将序列化的结果转换为64位字符串（转成字符串类型后，可以将数据存至数据库中其传至其它地方）
return memoryStream;

}

///<summary>
/// 反序列化以二进制方式
///</summary>
///<typeparam name="T"></typeparam>
///<param name="graph"对象必须标记为Serializable></param>
///<returns></returns>
public static T DeserializeByBinary<T>(Stream stream)
{
stream.Position = 0;
IRemotingFormatter formatter = new BinaryFormatter();
return (T)formatter.Deserialize(stream);
}
#endregion

#region 二进制深度复制克隆 StreamingContextStates.Clone 对象必须标记为Serializable
///<summary>
/// 以二进制序列化对象(不必知道对象的具体类型)
///</summary>
///<param name="graph"></param>
///<returns></returns>
public static Stream DeepCloneSerializeByBinary(object graph)
{
MemoryStream memoryStream = new MemoryStream();
IRemotingFormatter formatter = new BinaryFormatter();
//深度复制
formatter.Context = new StreamingContext(StreamingContextStates.Clone);
formatter.Serialize(memoryStream, graph);
return memoryStream;

}

///<summary>
/// 反序列化以二进制方式
///</summary>
///<typeparam name="T"></typeparam>
///<param name="graph"></param>
///<returns></returns>
public static T DeepCloneDeserializeByBinary<T>(Stream stream)
{
stream.Position = 0;
IRemotingFormatter formatter = new BinaryFormatter();
formatter.Context = new StreamingContext(StreamingContextStates.Clone);
return (T)formatter.Deserialize(stream);
}
#endregion

#region SOAP方式（过时）对象必须标记为Serializable
///<summary>
/// 以SOAP序列化对象(不必知道对象的具体类型)
///</summary>
///<param name="graph"></param>
///<returns></returns>
public static Stream SerializeBySoap(object graph)
{
MemoryStream memoryStream = new MemoryStream();
IRemotingFormatter formatter = new SoapFormatter();
formatter.Serialize(memoryStream, graph);
return memoryStream;

}

///<summary>
/// 反序列化以SOAP方式
///</summary>
///<typeparam name="T"></typeparam>
///<param name="graph"></param>
///<returns></returns>
public static T DeserializeBySoap<T>(Stream stream)
{
stream.Position = 0;
IRemotingFormatter formatter = new SoapFormatter();
return (T)formatter.Deserialize(stream);
}
#endregion

#region XML方式取代SOAP->不能处理复杂对象对象必须标记为Serializable
///<summary>
/// 以XML序列化（XML序列化的对象中包含集合类属性可能会引发异常，XML序列对集合类属性序列化有特殊要求）
///</summary>
///<typeparam name="T"></typeparam>
///<param name="graph"></param>
///<returns></returns>
public static Stream SerializeByXml<T>(object graph)
{
MemoryStream memoryStream = new MemoryStream();
XmlSerializer formatter = new XmlSerializer(typeof(T));
formatter.Serialize(memoryStream, graph);
return memoryStream;
}

///<summary>
/// 字符串反序列化对象（XML）
///</summary>
///<typeparam name="T"></typeparam>
///<param name="graph"></param>
///<returns></returns>
public static T DeserializeByXml<T>(Stream stream)
{
stream.Position = 0;
XmlSerializer formatter = new XmlSerializer(typeof(T));
return (T)formatter.Deserialize(stream);
}

#endregion

#region DataContractSerialzer方式对象不必标记为Serializable
///<summary>
/// DataContractSerialzer序列化对象
///</summary>
///<typeparam name="T"></typeparam>
///<param name="graph"></param>
///<returns></returns>
public static Stream SerializeByDataContract<T>(object graph)
{
MemoryStream memoryStream = new MemoryStream();
DataContractSerializer formatter = new DataContractSerializer(typeof(T));
formatter.WriteObject(memoryStream,graph);
return memoryStream;
}

///<summary>
/// DataContractSerialzer反序列化对象
///</summary>
///<typeparam name="T"></typeparam>
///<param name="graph"></param>
///<returns></returns>
public static T DeserializeByDataContract<T>(Stream stream)
{
stream.Position = 0;
DataContractSerializer formatter = new DataContractSerializer(typeof(T));
return (T)formatter.ReadObject(stream);
}
#endregion

}

}

利用FormatterServices反射实现（同MemberInfo类似）

BlogCategory cate = new BlogCategory();
cate.CateID = 1;
cate.CateName = "llj";
cate.CreateTime = DateTime.Now;
cate.SortID = 10;
cate.BlogArticle.Add(new BlogArticle()
{
UserID=20,
ArticleID = 1,
BlogCategory_CateID = 1,
Title = "love",
CreateTime = DateTime.Now

});

//获取字段成员及对应的值
MemberInfo[] members = FormatterServices.GetSerializableMembers(cate.GetType());
object[] membersValues = FormatterServices.GetObjectData(cate, members);

for (int i = 0; i < members.Length; i++)
{
//构建序列化的二进制数据或者XML/JSON等，当然自己要处理大量复杂的业务
//members[i].Name
//membersValues[i]
}

//反序化为对象
BlogCategory cate2 = (BlogCategory)FormatterServices.GetUninitializedObject(typeof(BlogCategory));
//BlogCategory cate2 = new BlogCategory();
FormatterServices.PopulateObjectMembers(cate2, members, membersValues);

当然这是一种便捷的方式，也可以通过手动反射实现，要手动实现就得考虑性能与复杂类型的处理问题。比如碰到导航类，或者泛型集合，而Nullable<T>这种泛型值类型通常用以处理非空值类型也会被误认为泛型集合。上一节介绍的CLR几种反射性能的例子都可以实现同样的目的。

本文链接

CLR VIA反射性能比较的例子

2011-11-11T18:15:00Z

在CLR VIA 的Demo中看到关于反射性能的几个例子，演示了反射操作实例及性能表现。反射的过程其实就是根据要查找的反射信息（字段名，方法名，类名等），在元数据中逐字符匹配的查找字段名，类型名等，然后定位到IL代码编译执行（所以会有大小写区分）。由于元数据是记录了程序集所有类型以及成员的描述信息，所以在其中查找指定的信息是件浪费性能的事情。如何快速匹配到对应的元数据信息，然后定位到IL执行代码去执行，这是本身反射性能提升的直接途径，当然这个过程已经很难优化，但是可以通过缓存管理首次的结果提高效率。类似JIT对IL方法指令的编译，首次编译后保存CLR 元数据相关的结构表中，再下一次执行时直接上次编译的CPU指令。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Dynamic;
namespace Demo
{
class Program
{
static void Main(string[] args)
{
Type t = typeof(SomeType);
//方法一 InvokeMember
Invoker.UseInvokeMemberToBindAndInvokeTheMember(t);
//方法二 MemberInfo派生类 SetValue->GetSetValueMethod->调用SetValueMethod
Invoker.BindToMemberThenInvokeTheMember(t);
//方法三委托操作看IL的调用栈要比上个浅，因为直接查找了GetMethod，但没有缓存仍然每次都要查找
Invoker.BindToMemberCreateDelegateToMemberThenInvokeTheMember(t);

//方法四 Dynamic动态(4.0特性)，dynamic经过语法糖编译为IL时对实现了类似方法三的效果，
//但是利用了CallSite的委托缓存容器，一次查找重复利用
Invoker.UseDynamicToBindAndInvokeTheMember(t);

Console.ReadLine();
}
}

///<summary>
/// 要反射的类型DEMO
///</summary>
public sealed class SomeType
{
private Int32 m_someField;
public SomeType(ref Int32 x) { x *= 2; }
public override String ToString() { return m_someField.ToString(); }
public Int32 SomeProp
{
get { return m_someField; }
set { m_someField = value; }
}
public event EventHandler SomeEvent;
private void NoCompilerWarnings()
{
SomeEvent.ToString();
}
}

public static class Invoker
{
///<summary>
/// 过滤成员标志
///</summary>
private const BindingFlags c_bf = BindingFlags.DeclaredOnly | BindingFlags.Public |
BindingFlags.NonPublic | BindingFlags.Instance;

///<summary>
/// 通过类型的InvokeMember实例的反射成员操作（最差，次次反射对象）
///</summary>
///<param name="t"></param>
public static void UseInvokeMemberToBindAndInvokeTheMember(Type t)
{
// Construct an instance of the Type
Object[] args = new Object[] { 12 }; // Constructor arguments
Object obj = t.InvokeMember(null, c_bf | BindingFlags.CreateInstance, null, null, args);

// Read and write to a field
t.InvokeMember("m_someField", c_bf | BindingFlags.SetField, null, obj, new Object[] { 5 });
Int32 v = (Int32)t.InvokeMember("m_someField", c_bf | BindingFlags.GetField, null, obj, null);

// Call a method
String s = (String)t.InvokeMember("ToString", c_bf | BindingFlags.InvokeMethod, null, obj, null);

// Read and write a property
try
{
t.InvokeMember("SomeProp", c_bf | BindingFlags.SetProperty, null, obj, new Object[] { 0 });
}
catch (TargetInvocationException e)
{

}
t.InvokeMember("SomeProp", c_bf | BindingFlags.SetProperty, null, obj, new Object[] { 2 });
v = (Int32)t.InvokeMember("SomeProp", c_bf | BindingFlags.GetProperty, null, obj, null);

// Add and remove a delegate from the event by invoking the event抯 add/remove methods
EventHandler eh = new EventHandler(EventCallback);
t.InvokeMember("add_SomeEvent", c_bf | BindingFlags.InvokeMethod, null, obj, new Object[] { eh });
t.InvokeMember("remove_SomeEvent", c_bf | BindingFlags.InvokeMethod, null, obj, new Object[] { eh });
}

///<summary>
/// 通过获取构造实例，获取成员反射类型设置（反射一次对象，效率高于上个)
/// MemberInfo派生类 SetValue->GetSetValueMethod->调用SetValueMethod
///</summary>
///<param name="t"></param>
public static void BindToMemberThenInvokeTheMember(Type t)
{
// Construct an instance
// ConstructorInfo ctor = t.GetConstructor(new Type[] { Type.GetType("System.Int32&") });
ConstructorInfo ctor = t.GetConstructor(new Type[] { typeof(Int32).MakeByRefType() });
Object[] args = new Object[] { 12 }; // Constructor arguments
Object obj = ctor.Invoke(args);

// Read and write to a field
FieldInfo fi = obj.GetType().GetField("m_someField", c_bf);
fi.SetValue(obj, 33);

// Call a method
MethodInfo mi = obj.GetType().GetMethod("ToString", c_bf);
String s = (String)mi.Invoke(obj, null);

// Read and write a property
PropertyInfo pi = obj.GetType().GetProperty("SomeProp", typeof(Int32));
try
{
pi.SetValue(obj, 0, null);
}
catch (TargetInvocationException e)
{

}
pi.SetValue(obj, 2, null);

// Add and remove a delegate from the event
EventInfo ei = obj.GetType().GetEvent("SomeEvent", c_bf);
EventHandler eh = new EventHandler(EventCallback); // See ei.EventHandlerType
ei.AddEventHandler(obj, eh);
ei.RemoveEventHandler(obj, eh);
}

///<summary>
/// 通过委托执行实例成员的IL方法（效率高于上个,比较适合批量处理大量未知对象的序列化)
///</summary>
///<param name="t"></param>
public static void BindToMemberCreateDelegateToMemberThenInvokeTheMember(Type t)
{
// Construct an instance (You can't create a delegate to a constructor)
Object[] args = new Object[] { 12 }; // Constructor arguments
Object obj = Activator.CreateInstance(t, args);

// NOTE: You can't create a delegate to a field
// Call a method
MethodInfo mi = obj.GetType().GetMethod("ToString", c_bf);
var toString = (Func<String>)Delegate.CreateDelegate(typeof(Func<String>), obj, mi);
String s = toString();

// Read and write a property
PropertyInfo pi = obj.GetType().GetProperty("SomeProp", typeof(Int32));
var setSomeProp = (Action<Int32>)Delegate.CreateDelegate(typeof(Action<Int32>), obj, pi.GetSetMethod());
try
{
setSomeProp(0);
}
catch (ArgumentOutOfRangeException)
{

}
setSomeProp(2);
var getSomeProp = (Func<Int32>)Delegate.CreateDelegate(typeof(Func<Int32>), obj, pi.GetGetMethod());

// Add and remove a delegate from the event
EventInfo ei = obj.GetType().GetEvent("SomeEvent", c_bf);
var addSomeEvent = (Action<EventHandler>)Delegate.CreateDelegate(typeof(Action<EventHandler>), obj, ei.GetAddMethod());
addSomeEvent(EventCallback);
var removeSomeEvent = (Action<EventHandler>)Delegate.CreateDelegate(typeof(Action<EventHandler>), obj, ei.GetRemoveMethod());
removeSomeEvent(EventCallback);
}

///<summary>
/// 动态代理方式UseDynamic，但是利用了CallSite的委托缓存容器，性能要高于方法三
///</summary>
///<param name="t"></param>
public static void UseDynamicToBindAndInvokeTheMember(Type t)
{
// Construct an instance (You can't create a delegate to a constructor)
Object[] args = new Object[] { 12 }; // Constructor arguments
dynamic obj = Activator.CreateInstance(t, args);

// Read and write a property
try
{
obj.SomeProp = 0;
}
catch (ArgumentOutOfRangeException ex)
{
throw ex;
}
obj.SomeProp = 2;
Int32 val = (Int32)obj.SomeProp;

// Add and remove a delegate from the event
obj.SomeEvent += new EventHandler(EventCallback);
obj.SomeEvent -= new EventHandler(EventCallback);
}

// Callback method added to the event
private static void EventCallback(Object sender, EventArgs e) { }
}
}

本文链接

进程/线程/线程安全/静态类杂谈

2011-11-07T17:05:00Z

进程

是应用程序的一个实例要使用的资源的一个集合，每个进程都被赋予了一个虚拟空间，以确保另一个其它进程无法访问。

进程在者创建时需要分配大量的内存并且初始化加载EXE以及大量的DLL资源。

线程

相当于逻辑CPU用以解决进程长时间占用资源的问题，在创建时被分配大约1M的内存。线程以CPU时间片单位运行，当时间片到期后自动切换到另一个线程执行，从而缓解一个进程或线程长期占用资源的情况。线程切换伴随着上下文资源的切换，所以大量的线程切换也是浪费性能的事情。

一个进程拥有一个专用线程，理论上有多少进程最少就有多少线程，当然实际情况上一个进程可能拥有很多线程。我们可以通过任务管理器的添加选项列线程数来查看一个进程拥有多少线程。可以看出大部分进程的CPU使用率为零，但是线程却占据着大量内存资源。（一个线程栈要分配1M内存）。

一般进程的主线程会被标记[STAThread]属性指示应用程序的默认线程模型是单线程单元 (STA)。这个属性主要针对与COM Interop互操作，如果在当前操作COM Interop对象的线程未标记STAThread或设置线程STAThread属性，则会出现异常。如果没有使用COM Interop，一般不需要这个Attribute。

线程安全

只有在多个线程争夺共享资源并且进行破坏操作（如：写操作等）的情况才会有线程安全问题，如果多个线程在调用同一个实例的同一方法时并没出现资源争夺与破坏（如：只读），当然不会存在安全问题。但是大多数情况，非静态类的实例方法大都是操作某些属性字段资源，因此不可必免的出现对同一字段的资源的写操作，从而破坏了数据。同理，静态方法如果引用静态字段也会碰到线程安全的问题。判断一个方法是否线程安全，是看该方法是否存在对共享资源的争夺破坏。

静态类/静态字段/静态方法

静态构造函数（类型构造器）以互斥方式只被CLR执行一次，保证静态构造函数只被执行一次。

静态字段是非线程安全的，在多个线程中共享着同一个实例或静态类的静态字段。

静态方法在多个线程中为同一个实例或静态类的副本，所以是安全的。但是一理静态方法引用了静态字段，就不是线程安全了，因此应在静态方法必免使用静态字段，要么以互斥体的方式操作静态。

大多数据库操作类如SQLHelper此类都设计为静态类的，因为静态方法在不引用静态字段的前提下是线程安全的，所以基本上看到SQL 单连接的情况都是使用静态方法，可以防止单连接并发操作。

静态字段设计

定义静态字段时需要考虑线程安全

const常量定义（const在IL编译自动缀加static，所以不需要在static修饰），常量字段需要定义时就必须初始化一个值。

static readonly 只读静态变量，有一次构造初始化静态变量的机会。

当然你如果确实需要线程中修改静态变量的时，那就需要设计一个互斥锁或者InterLocked.CompareExchange方式操作。

静态事件

静态事件同非静态事件一样，区别就在于一个需要类实例化才能注册订阅，而另一个则是直接注册订阅。来看一下场景：

1.当A类（非静态事件）一个实例做一件事想同时通知X，Y，Z几个对象时，则我们要保证传递给X，Y，Z的A的实例必须是同一个。也就是说无论通过构造注入或者属性注入或者方法参数传递，都要保证是同一个A的实例，这样才能保证X，Y，Z注册到的是同一个事件。

但是如果A类是静态事件呢，则我们直接在X，Y，Z中直接注册订阅静态事件，并不需要解决同一个实例传递的问题。想想如果有大量的不同的对象要通知，那如何保证同一个非静态事件的实例在这些对象中传递呢？

2.假如希望A类（非静态事件）的所有实例做的任何事情都通知到X，Y，Z ，那我们应该怎么做呢？那肯定是要A所有实例的非静态事件都被X，Y，Z订阅，这样才能保证X，Y，Z接收到所有A实例事件触发的通知，但是想想这有多困难呢，你怎么知道A类会在哪些地方被实例化呢？并且还要在所有实例化的地方都要重复相同订阅的代码，这是否麻烦呢？我们看一下静态事件怎么解决这个问题的

假如A类使用了静态事件，而X，Y，Z则分别订阅了这个静态事件（只要针对静态事件订阅一次）。我们让A类的非静态方法完成时触发这个静态事件，想想会是什么情况？不管A有多少实例化的对象，只要这些对象调用了非态方法触发了静态事件，则X，Y，Z都会收到通知。是不是简单多少了，不用担心A所有实例做的事件你不知道了。这个应用场景很容易让人联想到数据库操作类，你想知道所有SQL操作，完全可以为你的数据库操作类设计一个静态事件的通知以便能在某个地方监控到的所有SQL语句。

以上两种情况可以看出，静态事件很容易的解决了一对多订阅以及多对一或多对多的订阅通知。当然我们也可以利用单例模式或者IOC容器容易的实现非静态事件分散通知的困难，但是要注意到一点静态字段不等同于静态类，单例模式以静态字段的形式保证了唯一实例，却很可能导致了线程的不安全。因为静态变量资源是被多个线程共享，你无法保证你的实例做为静态使用时，其中不会出资源争夺的情况发生。

lock/using/foreach/前台线程/后台线程

在多线程使用lock时，lock代码IL会自动编译为try..catch..finally... ，以确保在发生异常时lock可以正常解锁释放资源。相比Moniter.Entry与Monitr.Exit 就要自己解决异常释放锁的操作。

在using使用时也会自动封装try..catch..finally... ，在finally时会调用资源的Dispose释放对象资源. foreach同样也是如此。

开启线程时，要注意设置前台线程还是后台线程，因为线程终结的方式不一样。

前台线程：进程在关闭时，必须等待前台线程执行完成。

后台线程：进程在关闭时，会直接终止后台线程，导致线程任务无法完成。

本文链接

EF 最近发展小记

2011-10-29T06:49:00Z

最近一直学习硬件负载均衡设备和CLR VIA这本书，没太关注EF的发展。最近可能没时间研究，先做个标记

目前EF 已发展4.2版本

EF 4.2 Release Candidate Available

同时官方博客也推出了Code First的辅助工具用于解决 EF Code First Fluent API 手动编码的方案

EF Power Tools CTP1 Released

确实很方便，生成干净的POCO类以及Map映射类，但这种是基于数据库表驱动的方式。Fluent API 类似模型驱动。

个人不太喜欢Fluent API ，编码工作多，并且不好维护。

简介：NLayerApp项目就是Fluent API 方式。

本文链接

VS IDE 引用.net 项增加其它DLL项方法

2011-10-28T09:03:00Z

打开注册表找到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\ 这一项

创建自己的DLL文件夹假如Mongo 将注册值指向自己的DLL文件夹。

保存之后我们VS IDE引用一下试试

果然可以了，只要做一个就可以了，有新的DLL 直接扔到指定的文件夹下，在VS .NET 引用项中就可以找到这些DLL。小技巧，估计控件商都是这么处理的。

本文链接

GC/Windbg/IDisposable/IL/MeteData/JIT 杂谈

2011-10-27T05:34:00Z

GC工作原理大家都已经知道，简单的说就是按代回收托管对象。哪些托管对象会被回收，是通过每个程序的Root来识记，被Root标记的引用对象以及递归出所有相同的引用对象都是活对象，而未被标记的则意味着要被回收。何时回收对象？对于每个对象，CLR首先尝试把对象分配在0代中，如果0代已满，那么GC才会开始工作，把0代中的对象转移到1代中；如果1代也满，GC将会把1代中的对象转移到2代中。也就是说，CLR会在适当的时机，才开始进行垃圾回收。但是对于非托管对象的处理就显得无能为力，但是GC仍然有自己的解决方式。如果非托管对象实现了Finalize方法，代表此非托管对象可终结。因此在非托管对象被创建时，这些对象引用会被GC维护到一个特殊的全局队列中，这个队列被称为终结队列即FinalizeQueue. FinzlizeQueue标记的这些对象，程序中没有正确回收或者没有调用这些对象的Finalize/Close，亦或者实现析构，GC的Finalize线程也不会去回收这些对象。因此，根据上面GC的分析，这里就引出了如何得知这些非托管对象没有被正确的释放掉呢？当我们的程序中大量使用了非托管资源时，经常出现内存不可读不可用的问题时，windbg就是一个好的调试工作，至少最简单的情况可以帮助我们分析哪些对象的Dispose没有被调用，这里只是针对.net 简单使用。上面标记红色的字是windbg中会用到的命令。

windbg怎么用，园子里可以找到很多文章，这里不多介绍了。下面是测试使用的代码

static void Main(string[] args)
{
for (int i = 0; i < 3; i++)
{
Thread t1 = new Thread(new ThreadStart(Create));
t1.Start();
}

Console.ReadLine();
}

static void Create()
{
Mongo mongo = new Mongo("Server=172.16.0.25:27017;Pooled=true");
mongo.Connect();
IMongoDatabase simple = mongo["simple"];
mongo.Disconnect();
mongo.Dispose();
}

运行Demo.exe 开启windbg 将demo.exe附加进来首次使用windbg 调试.net 程序要加载mscorwks.dll 命令 .loadby sos mscorwks

0:006> !threads
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
PDB symbol for mscorwks.dll not loaded
ThreadCount: 7
UnstartedThread: 0
BackgroundThread: 3
PendingThread: 0
DeadThread: 3
Hosted Runtime: no
PreEmptive GC Alloc Lock
ID OSID ThreadOBJ State GC Context Domain Count APT Exception
0 1 12a4 004c99f0 a020 Enabled 01b1c108:01b1c4ac 004c5428 1 MTA
2 2 610 004d8a18 b220 Enabled 00000000:00000000 004c5428 0 MTA (Finalizer)
XXXX 3 0 00544d88 9820 Enabled 00000000:00000000 004c5428 0 MTA
XXXX 4 0 00546558 9820 Enabled 00000000:00000000 004c5428 0 Ukn
XXXX 5 0 005583b0 9820 Enabled 00000000:00000000 004c5428 0 Ukn
3 6 17dc 0055bb30 80a220 Enabled 00000000:00000000 004c5428 0 MTA (Threadpool Completion Port)
5 7 e58 0056c2c0 180b220 Enabled 01b6c0a8:01b6dfe8 004c5428 0 MTA (Threadpool Worker)

可以看到有7个线程，DeadThread的线程就是我们循环创建的3个线程 .（说明Thread创建的线程不会被马上回收掉）

通过FinalizeQueue查看哪些对象未被回收掉

0:005> !FinalizeQueue
SyncBlocks to be cleaned up: 0
MTA Interfaces to be released: 0
STA Interfaces to be released: 0
----------------------------------
generation 0 has 151 finalizable objects (03dd3a80->03dd3cdc)
generation 1 has 0 finalizable objects (03dd3a80->03dd3a80)
generation 2 has 0 finalizable objects (03dd3a80->03dd3a80)
Ready for finalization 0 objects (03dd3cdc->03dd3cdc)
Statistics:
MT Count TotalSize Class Name
51bb4a04 1 20 Microsoft.Win32.SafeHandles.SafeFileMappingHandle
51bb49ac 1 20 Microsoft.Win32.SafeHandles.SafeViewOfFileHandle
5134a69c 1 20 Microsoft.Win32.SafeHandles.SafeFileMapViewHandle
51b971ac 1 24 System.Threading.TimerBase
51ba12a4 2 40 Microsoft.Win32.SafeHandles.SafePEFileHandle
5134a644 2 40 Microsoft.Win32.SafeHandles.SafeFileMappingHandle
5134a5ec 2 40 Microsoft.Win32.SafeHandles.SafeLocalMemHandle
00168fd4 3 60 MongoDB.Connections.Connection
517a9fd4 3 72 System.Net.Sockets.TcpClient
5133ec98 3 72 System.Net.SafeCloseSocket
00e00a10 3 96 MongoDB.Connections.RawConnection
5133e590 5 100 System.Net.SafeCloseSocket+InnerSafeCloseSocket
51baeab4 6 120 Microsoft.Win32.SafeHandles.SafeFileHandle
5134a6f4 6 120 Microsoft.Win32.SafeHandles.SafeProcessHandle
51334fb0 1 160 System.Diagnostics.Process
51baa298 11 176 System.WeakReference
51b97b24 10 200 Microsoft.Win32.SafeHandles.SafeWaitHandle
51bb10bc 4 224 System.Threading.Thread
5133e420 3 228 System.Net.Sockets.Socket
51b85070 4 320 System.IO.FileStream
51bab304 18 360 Microsoft.Win32.SafeHandles.SafeRegistryHandle
51baa2f0 11 484 System.Threading.ReaderWriterLock
51b981a8 40 800 Microsoft.Win32.SafeHandles.SafeTokenHandle
51349f2c 10 1200 System.Diagnostics.PerformanceCounter
Total 151 objects

其中mongodb Connection 3条 RawConnection 3条以及 Socket 3条是由掉死的3个线程创建的

看一下RawConnection 的情况 MT00e00a10

0:005> !dumpheap -mt 00e00a10
Address MT Size
01b116e8 00e00a10 32
01b12db4 00e00a10 32
01b1f924 00e00a10 32
total 3 objects
Statistics:
MT Count TotalSize Class Name
00e00a10 3 96 MongoDB.Connections.RawConnection
Total 3 objects

看看为什么GC没有回收，说明有根在标记这个对象为活动状态，我们通过GCRoot 来查看根的情况 address 01b116e8

0:005> !GCRoot 01b116e8
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread 15b8
Scan Thread 2 OSTHread 1340
Scan Thread 3 OSTHread 1298
DOMAIN(003A5428):HANDLE(Pinned):1213ec:Root:02a73250(System.Object[])->
01b14e1c(System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[MongoDB.Connections.IConnectionFactory, MongoDB]])->
01b1f8c0(System.Collections.Generic.Dictionary`2+Entry[[System.String, mscorlib],[MongoDB.Connections.IConnectionFactory, MongoDB]][])->
01b1f36c(MongoDB.Connections.PooledConnectionFactory)->
01b1f39c(System.Collections.Generic.Queue`1[[MongoDB.Connections.RawConnection, MongoDB]])->
01b1fed4(System.Object[])->
01b116e8(MongoDB.Connections.RawConnection)

冒似是mongo连接池的队列一直在活动，导致RawConnetion没有被回收掉。看一下是不是RawConnection中Socket连接未关闭

0:010> !dumpobj 01b32db4
Name: MongoDB.Connections.RawConnection
MethodTable: 008f0a10
EEClass: 0086adc8
Size: 32(0x20) bytes
(E:\MongGo\samus-mongodb-csharp-6397a0f\Demo\bin\Debug\MongoDB.dll)
Fields:
MT Field Offset Type VT Attr Value Name
517a9fd4 4000234 4 ...Sockets.TcpClient 0 instance 01b32dd4 _client
00000000 4000235 8 0 instance 01b32e64 _authenticatedDatabases
51b845b4 4000236 10 System.Boolean 1 instance 0 _isDisposed
51b845b4 4000237 11 System.Boolean 1 instance 0 <IsInvalid>k__BackingField
51b88148 4000238 14 System.DateTime 1 instance 01b32dc8 <CreationTime>k__BackingField
008f011c 4000239 c ...ngoServerEndPoint 0 instance 01b401c8 <EndPoint>k__BackingField

->gcroot address 01b32dd4

0:010> !GCRoot 01b32dd4
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread 1300
Scan Thread 2 OSTHread a38
Scan Thread 3 OSTHread 6b0
Scan Thread 5 OSTHread 10b4
DOMAIN(00215428):HANDLE(Pinned):1b13ec:Root:02a93250(System.Object[])->
01b31750(System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[MongoDB.Connections.IConnectionFactory, MongoDB]])->
01b40210(System.Collections.Generic.Dictionary`2+Entry[[System.String, mscorlib],[MongoDB.Connections.IConnectionFactory, MongoDB]][])->
01b3fcbc(MongoDB.Connections.PooledConnectionFactory)->
01b3fcec(System.Collections.Generic.Queue`1[[MongoDB.Connections.RawConnection, MongoDB]])->
01b3308c(System.Object[])->
01b32db4(MongoDB.Connections.RawConnection)->
01b32dd4(System.Net.Sockets.TcpClient)

windbg对于调试非托管资源泄漏很方便，想了解更多读读这本书<CLRViaCS.第3版> . 书有点贵啊！详细windbg gc的调试可参照MSDN的这篇文章 CLR 完全介绍: 研究内存问题

然而在实际应用很可能非托管资与托管资源是相互引用，所以就要按照一定的顺序来释放。.net 下提供了实现标准Dispose模式的IDisposable接口用以实现非托管资源的释放，当然你也可以自己手动释放，只要合理其实都一样。只是继承IDisposable我们多了选择，可以选择自己释放，也可以交由于GC代为管理。结合MSDN的例子，IDisposable的实现方式如下，详细介绍写在代码里。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ECEPDI.Utility
{
/*为什么有时候要使用IDisposable接口
* 因为我们的类中使用了非托管资源如COM接口，句柄等等，如你在使用完这些非托管资源能及时释放掉也不必实现IDisposable接口
* 或者，我们通过继承IDisposable接口后，在这个对象被使用完自己手动调用Dispose释放掉，或者等GC Finalize调用析构回收
*
*/
public class MyResource:IDisposable
{
// Pointer to an external unmanaged resource.
private IntPtr handle;
// Other managed resource this class uses.
//private Component component = new Component();
// Track whether Dispose has been called.

// The class constructor.
public MyResource(IntPtr handle)
{
this.handle = handle;
}

///<summary>
/// 垃圾回收器会通过析构函数调用Finalize回收FinalizeQueu对象(析构函数会被Finalize方法调用的)
///</summary>
~MyResource()
{
Dispose(false); //析构被编译后会加入try,catch包装 base.Finalize
}
#region IDisposable 成员

///<summary>
/// 提供给使用者自己释放对象
///</summary>
public void Dispose()
{
//由程序使用者自己释放对象
Dispose(true);

//因为调用者释放了对象，因此不需要垃圾回收器再次终结对象
GC.SuppressFinalize(this);
}

#endregion

///<summary>
/// 必须重复调用Dispose方法的标记
///</summary>
private bool disposed = false;

///<summary>
/// 所有工作都由此方法完成
/// （其它方法都是调用此方法,为何设计此方法就是要把非托管资源手动释放掉，
/// 析构和手动都要如此操作，只是手动操作还在主动把非托管资源释放掉)
///</summary>
///<param name="disposing"></param>
protected virtual void Dispose(bool disposing)
{

if (!this.disposed)
{
if (disposing)
{
//托管资源的释放--------------------------------
//component.Dispose();
//没有dispose方法就设置为null-------------------
}

//-----------------------------------------------
//此处释放非托管资源
//-----------------------------------------------
CloseHandle(handle);
handle = IntPtr.Zero;
this.disposed = true;

}
}

// Use interop to call the method necessary
// to clean up the unmanaged resource.
[System.Runtime.InteropServices.DllImport("Kernel32")]
private extern static Boolean CloseHandle(IntPtr handle);

///<summary>
/// 类似dbconnection Close方式释放对象（其实调用的是Dispose)
///</summary>
public void Close()
{
Dispose();
}

}
}

实现IDisposable 接口后，我们有了两种方式释放对象中引用的资源，一种手动调用Dispose释放，另一种就是通过析构函数交由GC处理。析构函数只是把我们dispose 非托管资源的代码交给GC Finalize调用，但是C#（或者其他的支持CLR的语言）中，由于GC的不确定性，析构方法被调用的时机我们无法确定，因此正常情况还是要我们及时手动的using或调用Dispose方法回收掉。

PS:注意析构函数的对象，至少要两次以上GC.Collect()才能回收掉，第一次GC回收只做了一次移动标记的工作，第二次GC才认为此对象不可到达才真正回收。

当然你可以在程序结束时执行GC.Collect()，GC.WaitForPendingFinalizers()强制回收。

强调一下：调用Dispose释放对象，不是释放对象本身，而是释放对象引用的的资源（非托管以及托管资源，一般托管资源都是交给GC处理的）.调用Dispose的当前对象肯定属于活动对象，不可能在执行自己的Dispose时被释放或者被GC回收。当然我们可以在对象调用Dispose后，将其设置为null释放掉内存。

补充：

0:004> !dumpmt -md 00194438
EEClass: 006d6d28
Module: 00193488
Name: MongoDB.Mongo
mdToken: 020000ae (E:\MongGo\samus-mongodb-csharp-0.90.0.1\Demo\bin\Debug\MongoDB.dll)
BaseSize: 0x10
ComponentSize: 0x0
Number of IFaces in IFaceMap: 2
Slots in VTable: 17
--------------------------------------
MethodDesc Table
Entry MethodDesc JIT Name
6f9e6a90 6f86494c PreJIT System.Object.ToString()
6f9e6ab0 6f864954 PreJIT System.Object.Equals(System.Object)
6f9e6b20 6f864984 PreJIT System.Object.GetHashCode()
6fa57540 6f8649a8 PreJIT System.Object.Finalize()
0019c099 001943d0 NONE MongoDB.Mongo.Dispose()
0019c09d 001943d8 NONE MongoDB.Mongo.get_ConnectionString()
00593968 001943e0 JIT MongoDB.Mongo.GetDatabase(System.String)
00593918 001943e8 JIT MongoDB.Mongo.get_Item(System.String)
0019c0a9 001943f0 NONE MongoDB.Mongo.Connect()
0019c0ad 001943f8 NONE MongoDB.Mongo.TryConnect()
0019c0b1 00194400 NONE MongoDB.Mongo.Disconnect()
0019c08d 001943b0 NONE MongoDB.Mongo..ctor()
005901e8 001943b8 JIT MongoDB.Mongo..ctor(System.String)
00591878 001943c4 JIT MongoDB.Mongo..ctor(MongoDB.Configuration.MongoConfiguration)
0019c0b5 00194408 NONE MongoDB.Mongo.GetDatabases()
0019c0b9 00194414 NONE MongoDB.Mongo.<GetDatabases>b__1(MongoDB.Document)
0019c0bd 00194420 NONE MongoDB.Mongo.<GetDatabases>b__2(System.String)

留意JIT项，会发现很多项为NONE ，说是这些方法从未被调用过，故JIT函数从未编译这些项IL代码为CPU指令。PreJIT指这些方法被提前预编译好为本地指令。看一下下面JIT编译的相关信息 !u + md地址查看JIT编译方法的相关信息

0:004> !U 001943e0
Normal JIT generated code
MongoDB.Mongo.GetDatabase(System.String)
Begin 00593968, size 5b
00593968 55 push ebp
00593969 8bec mov ebp,esp
0059396b 83ec14 sub esp,14h
0059396e 894dfc mov dword ptr [ebp-4],ecx
00593971 8955f8 mov dword ptr [ebp-8],edx
00593974 833d4036190000 cmp dword ptr ds:[193640h],0
0059397b 7405 je 00593982
0059397d e8efdb1670 call mscorwks!CorLaunchApplication+0xe99e (70701571) (JitHelp: CORINFO_HELP_DBG_IS_JUST_MY_CODE)
00593982 33d2 xor edx,edx
00593984 8955f4 mov dword ptr [ebp-0Ch],edx
00593987 90 nop
00593988 b908138f00 mov ecx,8F1308h (MT: MongoDB.MongoDatabase)
0059398d e88ae6baff call 0014201c (JitHelp: CORINFO_HELP_NEWSFAST)
00593992 8945f0 mov dword ptr [ebp-10h],eax

通过dumpmt -md +MT地址可获取该类型下的所有方法信息

0:004> !dumpmd 001943f0
Method Name: MongoDB.Mongo.Connect()
Class: 006d6d28
MethodTable: 00194438
mdToken: 060005a9
Module: 00193488
IsJitted: no
CodeAddr: ffffffff

通过dumpmd +methoddesc地址获取方法的信息
0:004> !DumpModule 00193488 (dumpModule +module地址) 获取模块（dll,module）信息：模块中定义的类/模块引用的类

0:004> !DumpAssembly 004727b0
Parent Domain: 00445598
Name: E:\MongGo\samus-mongodb-csharp-0.90.0.1\Demo\bin\Debug\MongoDB.dll
ClassLoader: 00472820
SecurityDescriptor: 005b5f60
Module Name
00193488 E:\MongGo\samus-mongodb-csharp-0.90.0.1\Demo\bin\Debug\MongoDB.dll
0:004> !DumpAssembly 004727b0
Parent Domain: 00445598
Name: E:\MongGo\samus-mongodb-csharp-0.90.0.1\Demo\bin\Debug\MongoDB.dll
ClassLoader: 00472820
SecurityDescriptor: 005b5f60
Module Name
00193488 E:\MongGo\samus-mongodb-csharp-0.90.0.1\Demo\bin\Debug\MongoDB.dll

从methodTable/methodDesc 可以查出module信息从dumpModule可获得assembly的信息 dumpAssembly 查询程序集相关信息

不管是dumpmt/dumpmd

mdToken可以获得对应类型或方法的元数据4位字节的2进制标识

而MethodTable （元数据+IL被加载后的数据）并且记录了所有方法的结构数据MethodsDesc（IL+CALL JIT/或者已经编译的本地CPU指令）

而MethodsDesc 则保存对应方法IL代码以及指向JIT的地址，当首方法首先被调用，JIT会将IL编译成本地指令，并且保在MethodsDesc 中，

这样在下次调时就不必被JIT函数编译而直接执行。(我们平时代码中反射的程序集信息其实就是元数据)

下面是JIT工作的具体方式：

Calling a method for the first time:

Your program code calls a method Foo()
The CLR looks at the type that implements Foo() and gets the metadata associated with it
From the metadata, the CLR knows what memory address the IL (Intermediate byte code) is stored in.
The CLR allocates a block of memory, and calls the JIT.
The JIT compiles the IL into native code, places it into the allocated memory, and then changes the function pointer in Foo()'s type metadata to point to this native code.
The native code is ran.

Calling a method for the second time:

Your program code calls a method Foo()
The CLR looks at the type that implements Foo() and finds the function pointer in the metadata.
The native code at this memory location is ran.

当执行到某一个方法，CLR 根据从元数据（应该指的是MethodTable）查找到此方法地址（根据mdtoken找到MethodDesc，MethodDesc），CLR此时会从托管堆上分配空间，并且调用JIT 编译IL为本地CPU指令，并改变函数指针到这堆内存上执行本地CPU指令。

PS:在园子里看文章说debug/relased 两个模式编译的IL代码是一样的，但是IL经JIT编译本地指令的时候，released模式的指令被优化了。

本文链接