谈谈多线程编程（二）- 不变对象

不变对象是指对象的状态在构造后不可改变。这从根本上消除了线程间同步的需求，与锁或者阻塞策略不同的是，不变对象对运行时和设计时不会带来任何额外的开销，因此不变对象是多线程编程中一个很基本的策略。

最简单的不变对象是没有任何状态变量（静态或实例变量）的对象，但在实际编程中出现得更多的是构造后状态不可变的对象，下面是一个简单的例子： 

 1     public class ImmutablePoint
 2     {
 3         private readonly int _x;
 4         private readonly int _y;
 5 
 6         public ImmutablePoint(int x, int y)
 7         {
 8             _x = x;
 9             _y = y;
         }
 
         public int X
         {
             get { return _x; }
         }
 
         public int Y
         {
             get { return _y; }
         }
     }

对习惯了普通编程语言的程序员来说，很少编写不变对象，但是有一些策略可以让我们开始使用它：

对数据容器使用不变对象

 对某些数据容器，比如应用程序的配置字典，可能应用程序一旦运行就不会改变，不变对象是个很合适的选择

 1     public class Configuration
 2     {
 3         private readonly Dictionary<string, string> _configs;
 4 
 5         public Configuration()
 6         {
 7             _configs = new Dictionary<string, string>();
 8             ReadConfig();
 9         }
 
         public string this[string key]
         {
             get { return _configs[key]; }
         }
 
         private void ReadConfig()
         {
             //从配置文件或数据库中读取配置值
         }
     }

Copy-on-Write技术

 看了上面的例子，有朋友可能会说：我们的应用程序配置是可以运行时更新的，那还能使用不变对象吗？答案是：用点小技巧，我们仍然可以享受不变对象的优点。

先看用锁的方法，因为配置的字典可能会变化，因此使用了一个读写锁对象，比起使用Lock，读写锁的优势在于读操作可以并行，只有在更新时才存在独占的情况：

 1         public string this[string key]
 2         {
 3             get 
 4             {
 5                 readWriteLockObject.Read();
 6                 try
 7                 {
 8                     return _configs[key];
 9                 }
                 finally
                 {
                     readWriteLockObject.ReleaseReadLock();
                 }
             }
         }
 
         public void ReadConfig()
         {
             readWriteLockObject.Write();
             try
             {
                 //从配置文件或数据库中读取配置值
             }
             finally
             {
                 readWriteLockObject.ReleaseWriteLock();
             }
         }

上面的方法有个缺点：当更新配置时，所以的读操作都必须等待，如果更新的时间比较长，在IIS中就意味着大量的页面请求被阻塞甚至可能超时。下面看看使用不变对象的例子：

 1     public class Configuration1
 2     {
 3         private ImmutableConfiguration _config;
 4         private RWLockObject _readWriteLockObject;
 5 
 6         public Configuration1()
 7         {
 8             _config = new ImmutableConfiguration();
 9         }
 
         public string this[string key]
         {
             get
             {
                 ImmutableConfiguration config;
                 _readWriteLockObject.Read();
                 try
                 {
                     config = _config;
                 }
                 finally
                 {
                     _readWriteLockObject.ReleaseReadLock();
                 }
                 return config[key];
             }
         }
 
         public void ReadConfig()
         {
             ImmutableConfiguration config = new ImmutableConfiguration();
             _readWriteLockObject.Write();
             try
             {
                 _config = config;
             }
             finally
             {
                 _readWriteLockObject.ReleaseWriteLock();
             }
         }
 
         class ImmutableConfiguration
         {
             private readonly Dictionary<string, string> _configs;
 
             public ImmutableConfiguration()
             {
                 _configs = new Dictionary<string, string>();
                 ReadConfig();
             }
 
             public string this[string key]
             {
                 get { return _configs[key]; }
             }
 
             private void ReadConfig()
             {
                 //从配置文件或数据库中读取配置值
             }
         }
     }

在上面的代码中， 更新配置时锁定的时间很短，从而减轻了读线程被阻塞的可能，更进一步，考虑到读写锁都只包含单个赋值语句，还可以考虑使用volatile read/write来完全取消对读写锁的要求。

使用Copy-on-Write方法的另一个例子是某些集合对象，对某些很少改变的集合对象，我们也可以建立一个存储了集合数据的内部不可变对象，当需要遍历集合时，返回此对象，而需要改变集合对象时，我们可以复制原来的数据建立起新的不可变对象进行替换，代码和上面的非常类似，这里就不写出来了。在合适的场景下，这种方法可以大大减少线程同步对并行性能的影响。

如果对象的一组成员变量具有内在的联系或者约束，那么我们可以将这些变量放到一个新的不变对象中，使用Copy-on-Write，可以减少同步一组变量的开销。
例如，一个人的地址是由国家、省（州）、城市等变量描述的，下面是对此问题的两种代码：

使用多个成员变量的代码：

 1     public class Person
 2     {
 3         private string _country;
 4         private string _state;
 5         private string _city;
 6         private string _name;
 7         private object _lock = new object();
 8 
 9         public string Country
         {
             get { lock(_lock) return _country; }
         }
         //State、City、Name等其他属性的代码。。。
 
         public void ChangeAddress(string country, string state, string city)
         {
             lock (_lock)
             {
                 _country = country;
                 _state = state;
                 _city = city;
             }
         }
     }

 

使用不变对象的代码：

 1     public class Person
 2     {
 3         private Address _address;
 4         private string _name;
 5         private object _lock = new object();
 6 
 7         public string Country
 8         {
 9             get 
             {
                 Address address = Thread.VolatileRead(ref _address);
                 return address.Country;
             }
         }
         //Name等其他属性的代码。。。
 
         public void ChangeAddress(string country, string state, string city)
         {
             Address address = new Address(country, state, city);
             Thread.VolatileWrite(ref _address, address);
         }
 
         //新的不变对象类
         class Address
         {
             private readonly string _country;
             private readonly string _state;
             private readonly string _city;
 
             public Address(string country, string state, string city)
             {
                 _country = country;
                 _state = state;
                 _city = city;
             }
 
             public string Country { get { return _country; } }
             public string State { get { return _state; } }
             public string City { get { return _city; } }
         }
     }

 

从上面代码的对比可以看到，使用不变对象减少了对多个读写操作协调的需要，当多个变量被一个不变对象取代后，我们就可以使用轻量级的volatile read/write来完全消除锁的使用。

为普通对象加上只读适配器

 在有些时候，我们需要为一个普通的可读写对象返回一个只读的版本，这时候如果我们能建立一个只读的适配器，就无需在外部代码中加入同步代码。

例如我们在编写帐务管理系统时可能有一个Account对象，可以读取账户的余额或者修改其余额，但很多时候我们只需要查询账户，这时就可以提供一个不变版本的Account对象：

 1     public interface IImmutableAccount
 2     {
 3         int Balance { get; }
 4     }
 5 
 6     public interface IAccount : IImmutableAccount
 7     {
 8         void Credit(int credit);
 9     }
 
     public class Account : IAccount
     {
         private int _balance;
         private RWLockObject _readWriteLockObject;
 
         public Account(int balance)
         {
             _balance = balance;
         }
 
         public int Balance
         {
             get
             {
                 _readWriteLockObject.Read();
                 try
                 {
                     return _balance;
                 }
                 finally
                 {
                     _readWriteLockObject.ReleaseReadLock();
                 }
             }
         }
 
         public void Credit(int amount)
         {
             _readWriteLockObject.Write();
             try
             {
                 _balance = _balance + amount;
             }
             finally
             {
                 _readWriteLockObject.ReleaseWriteLock();
             }
         }
 
         public void Dedit(int amount)
         {
             return Credit(-1 * amount);
         }
     }
 
     public class ImmutableAccount : IImmutableAccount
     {
         private readonly Account _account;
         public ImmutableAccount(Account account)
         {
             _account = account;
         }
 
         public int Balance
         {
             get { return _account.Balance; }
         }
     }

 

Flyweight(享元)模式

 Flyweight模式是GOF《设计模式》中的一个经典标准设计模式，里面的共享对象就是典型的不变对象，这方面的文章可以从Google上找到很多，这里就不班门弄斧了。

关于This逸出问题

我们在使用不可变对象时，要要格外注意下面的原则：

• 在构造函数执行前，不要访问对象的数据

这一点不光是不可变对象，也是设计任何类都应该遵守的原则。通常会导致这个问题的因素是在构造函数中以This为参数调用非私有函数或其他外部函数，这使得其他线程有机会访问到未完全初始化的对象。

对不变模式的总结

不变对象由于其优点，值得在多线程编程中予以重视。但不变对象也有明显的缺点，就是大量对象导致的内存占用巨大的问题。因此在使用不变对象前，需要我们在设计上进行权衡，变化过于频繁的对象是不适合使用这种策略的。

                                                                                                                            待续。。。