博客园_不懈

Microsoft.Practices.Unity 的一个线程安全Bug浅析

2011-05-30T09:18:00Z

从接触Enterprise Library开始，到现在越来越感觉的Elib的强大。虽然单独看Elib里面的Block不一定是优秀的，但是作为一个整体其优势不言而喻。更重要的是Elib是MS的团队在维护，不用担心MS会把它吃掉。

这段时间一直在Elib上进行开发，Unity也是用的最多的一个Block了。由于都是在单机开发BS系统，因此很少应用到多线程，多线程的问题也没有怎么暴露出来。以前也潜意识的认为MS会把线程安全处理好，但是今天发现其实不然。测试代码如下：

1 class Program

2     {
3         static UnityContainer container;
4         static bool stop;
5         static void Main(string[] args)
6         {
7             container = new UnityContainer();
8
9             var t1 = new Thread(new ThreadStart(Read));
10             var t2 = new Thread(new ThreadStart(Write));
11
12             t1.Start();
13             t2.Start();
14
15             Console.ReadLine();
16             stop = true;
17         }
18
19         static void Read()
20         {
21             while (true)
22             {
23                 if (container.IsRegistered<int>("a"))
24                     Console.WriteLine("OK");
25                 Thread.Sleep(10);
26                 if (stop)
27                     break;
28             }
29         }
30
31         static void Write()
32         {
33             int index = 0;
34             while (true)
35             {
36                 container.RegisterType<Program>(index.ToString());
37                 Console.WriteLine("Regist " + index);
38                 Thread.Sleep(10);
39                 index++;
40                 if (stop)
41                     break;
42             }
43         }
44     }

运行这个简单的sample，不久就会出现：Collection was modified; enumeration operation may not execute.异常,就是说在循环一个集合时，这个集合被另一线程修改了。这个错误在多线程编程中算比较经典的异常了。查看Unity的Regist方法的代码发现其实现其实非常简单。

public static bool IsRegistered(this IUnityContainer container, Type typeToCheck, string nameToCheck)

        {
            Guard.ArgumentNotNull(container, "container");
            Guard.ArgumentNotNull(typeToCheck, "typeToCheck");

            var registration = from r in container.Registrations
                               where r.RegisteredType == typeToCheck && r.Name == nameToCheck
                               select r;
            return registration.FirstOrDefault() != null;
        }

通过遍历一个Resitrations查找符合记录的条件。Registrations通过

private void FillTypeRegistrationDictionary(IDictionary<Type, List<string>> typeRegistrations)
        {
            if(parent != null)
            {
                parent.FillTypeRegistrationDictionary(typeRegistrations);
            }

            foreach(Type t in registeredNames.RegisteredTypes)
            {
                if(!typeRegistrations.ContainsKey(t))
                {
                    typeRegistrations[t] = new List<string>();
                }

                typeRegistrations[t] =
                    (typeRegistrations[t].Concat(registeredNames.GetKeys(t))).Distinct().ToList();
            }

}

方法得到。到这里就可看到整个实现的核心所在：NamedTypesRegistry类型的registeredNames。这个类负责类型的注册，所有的注册信息都保存在这个类中。重点就在 public void RegisterType(Type t, string name)

        {
            if(!registeredKeys.ContainsKey(t))
            {
                registeredKeys[t] = new List<string>();
            }

            RemoveMatchingKeys(t, name);
            registeredKeys[t].Add(name);
        }

RegisterType方法，这个方法根本没有考虑到多线程同步问题直接对registeredKeys进行Add操作，同样在RegisteredTypes属性中也没有进行同步处理。很显然读写异步的情况肯定会出现上面所说的异常了。

虽然可以通过在外部调用Regist和IsRegist方法进行同步处理，但是这样的话调用外层的Lock就比较麻烦而且比较分散，性能也可能有问题。

本文链接

NET Reflector 7发布，其不再免费

2011-03-14T02:11:00Z

今天看到NET Reflector不再免费的消息感觉有点惊讶，这个工具已经成为每个开发人员必备的工具之一了。而且CodePlex上也有很多围绕NET Reflector开发的插件。今天其不再免费了，难道逼大家去Crack么？35美刀不便宜啊。

官方的原文:

10 Mar 2011

Version 7 is now available from $35.

We're happy to announce that we've released .NET Reflector 7. Please visit the new website at www.reflector.net to find out more and download a free 14 day trial.

The free version of .NET Reflector is no longer available. Please see our original announcement below.

本文链接

(抽象)工厂的另一种实现方式

2010-08-19T09:51:00Z

工厂模式是在设计模式中比较容易理解和掌握的一种模式，其使用非常的普遍。在项目实践中个人对常用的工厂模式做了一个调整，整个实现有点像工厂模式和抽象工厂模式的混合体，这样做的好处在于结合工厂模式的易用和抽象工厂的灵活。具体的实现可能如下：

在这个Case中有2个类，2个接口。其中IServiceFactory定义了工厂的职责GetService<T>,ServiceFactory实现IServiceFactory接口（注意接口是显示实现，这个很重要，因为类的静态方法和实例方法签名不能相同）。

ServiceFactory.cs

1     public class ServiceFactory:IServiceFactory
2     {
3         private static IServiceFactory _inc;
4
5         private ServiceFactory()
6         {
7
8         }
9         static ServiceFactory()
10         {
11
12             _inc = Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.Current.GetInstance<IServiceFactory>();
13             if (_inc == null)
14
15                 _inc = new ServiceFactory();
16         }
17
18         public static T GetService<T>()
19         {
20             return _inc.GetService<T>();
21         }
22
23         T IServiceFactory.GetService<T>()
24         {
25             return default(T);
26         }
27     }

作为ServiceFactory的调用者在使用上和普通的工厂没有任何区别，利用IOC容器可以非常方便的用Mok对象来降低对具体业务的依赖性，极大的了方便单元测试。同时我们也可以通过条件编译在发布的时候去掉对IoC容器的依赖。

Test:

1  IUnityContainer container;
2         [Test]
3         public void CalculateTest()
4         {
5             Setup();
6
7             var factoryMock = new Mock<IServiceFactory>();//Mock Factory
8             var calcMock = new Mock<ICalculateService>();//Mock Service
9             calcMock.Setup(c => c.Sum(It.IsAny<int>(), It.IsAny<int>())).Returns<int, int>((x, y) => x + y); //Mock Calculate Sum Method
10             factoryMock.Setup(c => c.GetService<ICalculateService>()).Returns(calcMock.Object); //Mock GetService<T> Method
11
12             container.RegisterInstance<IServiceFactory>(factoryMock.Object);//向容器中注入Mock的Factory
13
14             var calc = ServiceFactory.GetService<ICalculateService>();
15
16             Assert.IsNotNull(calc);
17             int a = 1;
18             int b = 2;
19             int experct = a + b;
20             int actual = calc.Sum(a, b);
21             Assert.IsTrue(experct == actual);
22         }
23
24         public void Setup()
25         {
26             container = new UnityContainer();
27             Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.Current = new UnityServiceLocator(container);
28         }

本文链接

自定义EF4 Model 代码生成

2010-08-13T02:41:00Z

在VS2010中EF4提供了三种代码生成方式：EntityObject,POCO,Self-Tacking。默认VS2010只带有EntityObject模板，可以通过浏览Online Templates中的项目将剩余的两种添加到本地模板文件中来。三种代码模板都是通过T4模板引擎来实现的，因此通过分析一下模板文件我们也能够实现自己的代码生成器。

在项目中添加一个模板文件，打开.tt的文件，在文件的头部会有一行代码<#@ include file="EF.Utility.CS.ttinclude"#>，EF.Utility.CS.ttinclude是一个非常有用的文件，主要是用来分析edmx文件和生成模型代码的，要实现自己的代码生成器首先得找到这个文件，通过搜索这个文件放置在：\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\Templates\Includes目录。用VS打开这个文件发现它其实就是个代码文件。新建一个Project将文件中的CS代码copy到一个新的CodeGenerationTools类中，引用必要的Assembly和Namespace就可以了。在本文附件中找到两个Dll：Microsoft.VisualStudio.TextTemplating.10.0.dll和Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll 这两个dll是T4模板的引擎，具体的使用在网上有很多介绍这里就不再赘述了。在项目中添加EntityObject,POCO,Self-Tacking三个模板文件，将默认文件名改成对应的模板名称，这样便于区分。在添加模板文件的时候IDE可能会出现很多Error信息，直接跳过可以了。在出错信息中会有个错误信息说需要用实际的edmx文件路径替换掉 $edmxInputFile$ 。这个地方就是后面我们需要修改的地方。选择tt模板文件在文件属性中将Customer Tool里面的内容清空，这样IDE就不会自动生成不必要的cs文件也不会提示错误了。在项目文件中新增一个新类EntityFrameworkTemplateHost实现ITextTemplatingEngineHost接口。这类将来主要负责传递一些配置信息。具体的代码可以在附件中找到这里面就不贴了，网上关于T4模板介绍的中都有其使用介绍。

完成这些就需要对模板文件和CodeGenerationTools中的内容做一些调整。首先是修改每个模板文件在在每个模板的头中添加必要的名称空间引用，如果后面的执行中出现类型找不到就是在这里没有添加必要的名称空间了。在模板文件中找到带有$edmxInputFile$文本的哪行，将其替换为：

EntityFrameworkTemplateHost host = (EntityFrameworkTemplateHost)(Host);
string inputFile = host.EDMXFile;//EDMXFile是EntityFrameworkTemplateHost定义的一个属性由外部传入。

打开CodeGenerationTools文件，去掉EnvDTE引用，因为这个是在IDE环境中用到的，这里我们不需要和IDE交互所以可以完全移除了。这个过程比较简单，根据编译错误可以很容易调整过了，这里限于篇幅限制就不详细介绍了。最后的调用代码可能是这样：

整个过程其实比较简单的，就不放完整的代码了，动动手有益健康。附件

本文链接

.net 4.0 中对多线程新特性（四）--任务和任务工厂

2010-08-12T09:12:00Z

在4.0前如果需要进行并行任务往往都是自己实现Task和Task Factory来管理任务，其中难免会牵涉到大量的线程和线程池的管理工作。到了4.0 这部分内容都已经集成到基础类库中了。在System.Threading.Task中新增了几个类：

Task

TaskFactory

TaskScheduler

这几个类一看名字就知道干啥的了,先看看Task的一个简单例子

1 [STAThread]
2         static void Main()
3         {
4             var tasks = new Task[10];
5             for (int i = 0; i < 10; i++)
6             {
7                 tasks[i] =   new Task(Action,TaskCreationOptions.LongRunning);
8                 tasks[i].Start();
9             }
10
11             //Task.WaitAll(tasks);
12
13             Console.WriteLine("Finished");
14             Console.ReadLine();
15         }
16
17         static Random rd = new Random();
18         static void Action()
19         {
20             var threadId = Thread.CurrentThread.ManagedThreadId;
21             Console.WriteLine("Current Thread Id:{0}" ,threadId);
22             Thread.Sleep(rd.Next(100, 1000));//随机休眠一段时间，模拟线程实际调用时间消耗
23         }

程序输出如下：

Current Thread Id:11

Finished

Current Thread Id:12

Current Thread Id:14

Current Thread Id:13

...

（实际的输出可能和这里有所不同）

细心的你可能会发现代码中的第11行已经被注释了，WaitAll的名字是不是非常熟悉？是的，这在我们做线程同步时经常会用到WaitHandle类的WaitAll效果是一样的

取消注释运运行一下我们会得到如下输出：

Current Thread Id:11

Current Thread Id:12

Current Thread Id:14

Current Thread Id:13

...

Finished

在输出中的Finished一定会等所有的Task完成之后才会输出。是不是非常容易了。Task启动的时候会自动使用到线程池，系统会给Task自动分配线程。

如果任务很多的时时候我们需要细粒度的控制每个Taks的调度Schedule可以用TaskFactory就是来完成做这个工作的，看个简单的例子：

1 [STAThread]
2         static void Main()
3         {
4             var factory = new TaskFactory();
5             var tasks = new Task[10];
6             for (int i = 0; i < 10; i++)
7             {
8                 tasks[i] = factory.StartNew(Action );
9             }
10
11             Task.WaitAll(tasks);
12
13             Console.WriteLine("Finished");
14             Console.ReadLine();
15         }
16
17         static Random rd = new Random();
18         static void Action()
19         {
20             var threadId = Thread.CurrentThread.ManagedThreadId;
21             Console.WriteLine("Current Thread Id:{0}" ,threadId);
22             Thread.Sleep(rd.Next(100, 1000));//随机休眠一段时间，模拟线程实际调用时间消耗
23         }

程序输出如下：

Current Thread Id:11
Current Thread Id:11
Current Thread Id:12
Current Thread Id:11
Current Thread Id:11
Current Thread Id:12
Current Thread Id:11
Current Thread Id:12
Current Thread Id:11
Current Thread Id:12
Finished

从结果中看到10个任务只分配到了2个线程来处理，线程被最大的限度的复用了。如果需要更好的控制任务的调度，你需显示的配置TaskScheduler，对于你来说应该非常easy的

本文链接

.net 4.0 中对多线程新特性（三）

2010-08-10T06:32:00Z

在4.0之前如果需要在多线程环境下操作集合类型的对象往往需要额为每种操作添加比较复杂的锁机制才能保证每个线程对资源的访问安全，在4.0的Collection名称空间下面又多了一个新的名称空间Concurrent，在这个名称空间下面增加了几个非常有用的线程安全的类：
BlockingCollection<T>                    为实现 IProducerConsumerCollection<(Of <(T>)>) 的线程安全集合提供阻止和限制功能。
ConcurrentBag<T>                        表示对象的线程安全的无序集合。
ConcurrentDictionary<key,value>    表示可由多个线程同时访问的键值对的线程安全集合。
ConcurrentQueue<T>                    表示线程安全的先进先出 (FIFO) 集合。
ConcurrentStack<T>                     表示线程安全的后进先出 (LIFO) 集合。
OrderablePartitioner<T>                 表示将一个可排序数据源拆分成多个分区的特定方式。
Partitioner                                     提供针对数组、列表和可枚举项的常见分区策略。
Partitioner<T>                               表示将一个数据源拆分成多个分区的特定方式。

通一个简单的例子可以非常容易的来应用这些特性

程序输出如下：

Thread 11 add 0 success
Thread 11 add 1 success
Thread 12 add 0 fail
Thread 13 add 0 fail
Thread 11 add 2 success
Thread 12 add 1 fail
Thread 14 add 0 fail
Thread 12 add 2 fail
Thread 13 add 1 fail

…

从输出结果我们看到在多线程竞争的情况下ConcurrentDictionary能够很好的处理锁竞争的问题。

生产消费模式在多线程中是非常常见的一种模式了，在4.0之前需要一套比较复杂的读写锁来处理处理并发资源竞争的问题，在4.0中借助BlockingCollection<T> 类可以很容易的实现了。即使一个新手也能够非常容易的掌握而不需太多去了解多线程的细节问题。来个简单的例子：

Consume Product Product 0
Produce Product Product 1
Consume Product Product 1
Produce Product Product 2
Consume Product Product 2
Produce Product Product 3
Consume Product Product 3
Produce Product Product 4
Consume Product Product 4

本文链接

.net 4.0 中对多线程新特性（二）

2010-08-09T05:51:00Z

上篇已经简单介绍了.net 4.0中Lazy<T>类，通过Lazy<T>我们可以很容易的延迟初始化一些对象。如果我们需要在多线程环境下建立一些线程级别应用可以使用ThreadLocal<T>。在MSND中我们可以了解到除了Dispose之外，ThreadLocal<T> 的所有公共和受保护的成员都是线程安全的，可从多个线程同时使用。Value 和 IsValueCreated 属性返回的值是特定的线程在其访问该属性。

在4.0之前为了实现线程级别存储会使用ThreadStatic标签来标识某个变量是线程级别存储的，例如：

class Program
{
static void Main(string[] args)
{
for (int i = 0; i < 5; i++)
{
var thread = new Thread( new ThreadStart( ()=>
{
using( var scope = new ThreadStaticScope() )
{
Console.WriteLine("Thread Id:{0}",ThreadStaticScope.Current.Value);
}
}) );
thread.Start();
}

Console.Read();
}
}

public class ThreadStaticScope:IDisposable
{
[ThreadStatic]
static ThreadStaticScope __inc;

public ThreadStaticScope()
{
Value = Thread.CurrentThread.ManagedThreadId;
__inc = this;
}

public int Value
{
get;
private set;
}

public static ThreadStaticScope Current
{
get { return __inc; }
}

public void Dispose()
{
__inc = null;
GC.SuppressFinalize(this);
}
}

输出结果：

Thread Id:11

Thread Id:12

Thread Id:13

Thread Id:14

Thread Id:15

从输出结果可以看到每个线程都是独享一个ThreadStaticScope.

换作ThreadLocal<T>可以非常方便的实现同样的效果。

class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i < 5; i++)
            {
                var thread = new Thread( new ThreadStart( ()=>
                    {
                        using (var scope = new ThreadLocalScope())
                        {
                            Console.WriteLine("Thread Id:{0}", ThreadLocalScope.Current.Value);
                        }
                    }) );
                thread.Start();
            }

            Console.Read();
        }
    }

public class ThreadLocalScope:IDisposable
    {
        static ThreadLocal<ThreadLocalScope> __inc = new ThreadLocal<ThreadLocalScope>( );

        public ThreadLocalScope()
        {
            Value = Thread.CurrentThread.ManagedThreadId;
            __inc.Value = this;
        }

        public int Value
        {
            get;
            private set;
        }

        public static ThreadLocalScope Current
        {
            get { return __inc.Value; }
        }

        public void Dispose()
        {
            __inc.Dispose();
            GC.SuppressFinalize(this);
        }
    }

输出结果：

Thread Id:11

Thread Id:12

Thread Id:13

Thread Id:14

Thread Id:15

利用好ThreadLazy可以非常方便的实现一些以前表较复杂的实现。Lazy<T>中由于多线程共享同一个实例因此其value值一旦初始化之后是不允许修改的，但是ThreadLazy是允许多次修改，这个是需要注意的地方。

本文链接

.net 4.0 中对多线程新特性（一）

2010-07-30T08:32:00Z

在.net 40中对多线程的处理增加了很多新的类以方便多线程环境下的编程实现，首先需要了解的是两个非常有用的类Lazy<T>和ThreadLazy<T>,通过这两个类我们可以很方便实现一个单例模式而不用考虑太多的线程安全的问题。

Lazy<T>:类简化了执行对象的延迟初始化和实例化的工作。通过以延迟方式实例化对象，可避免在根本不需要的情况下必须创建所有的对象，或者可以将对象的初始化延迟到第一次访问它们的时候.例如：

    class Program
    {
        public static Lazy<int> __current = new Lazy<int>(() => Thread.CurrentThread.ManagedThreadId);

        static void Main(string[] args)
        {
            for (int i = 0; i < 5; i++)
            {
                var thread = new Thread( new ThreadStart( ()=>
                    {
                        Console.WriteLine(string.Format("Current Thread Id:{0} Current Value:{1}"
                                ,Thread.CurrentThread.ManagedThreadId,__current.Value ) );
                    }) );
                thread.Start();
            }

            Console.Read();
        }

    }

程序输出如下：

可以看到__current.Value在不同的线程下面的值始终为第一个线程的ID，需要注意的是__current.Value属性一旦被调用就会回调构造函数中传入的Fun，如果调用失败__current也不会再次调用Fun，其__current.IsValueCreated始终为真，__current.Value是不能够被修改的。通过Lazy<T>可以非常优雅的实现一个简单的单例：

public class Singleton
    {
        private Singleton()
        {
        }

        private static Lazy<Singleton> __inc = new Lazy<Singleton>(() => new Singleton());

        public static Singleton Current
        {
            get { return __inc.Value; }
        }
    }

本文链接

Flex&.Net开篇

2007-12-13T03:43:00Z

Flex学习心得和一些Flex资料推荐

SqlSever N层表数据查询效率

2007-11-02T03:08:00Z

在做数据内联查询时，随着Join的表越多查询的性能会急剧下降。为了提高查询这种深层次对象的效率，采用了一种折中的办法就是将相邻两个表作join将主键插入一个表变量，然后作为下一个表查询的条件

博客园_不懈

Microsoft.Practices.Unity 的一个线程安全Bug浅析

NET Reflector 7发布，其 不再免费

(抽象)工厂的另一种实现方式

自定义EF4 Model 代码生成

.net 4.0 中对多线程新特性（四）--任务和任务工厂

.net 4.0 中对多线程新特性（三）

.net 4.0 中对多线程新特性（二）

.net 4.0 中对多线程新特性（一）

Flex&.Net开篇

SqlSever N层表数据查询效率

NET Reflector 7发布，其不再免费