“对象性能”模式
面向对象很好的解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。
- 典型模式
- Sington
- Flyweight
单例模式Singleton
保证一个类仅有一个实例，并提供一个该实例的全局访问点。
——《设计模式》GoF
- 动机
在软件系统中，经常有这样一个特殊的类，必须保证它们在系统中只存在一个示例，才能确保他们的逻辑正确性、以及良好的效率。
这个应该类设计者的责任，而不是使用者的责任。
单例模式的代码：
class Singleton{
private:
Singleton();
Singleton(const Singleton& other);
public:
static Singleton* getInstance();
static Singleton* m_instance;
};
Singleton* Singleton::m_instance=nullptr;
//线程非安全版本
Singleton* Singleton::getInstance() {
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
/*
在单线程环境下，以上的代码没问题，但是在多线程的情况下会出问题。
当线程1执行到 if (m_instance == nullptr) 时，如果这时候正好线程2获得了CPU的执行权，
那么，此时对于两个线程来说，都检测到了这个对象为空，
那么两者都会创建该对象，也就是会破坏了单例的本质
*/
/*
为了解决以上多线程的问题，就出现了下面的线程安全的版本，通过锁对象的方案来解决。
也就是说在一个线程执行到getInstance方法时，在锁对象未被释放前，不会交出CPU的执行权。
那么此时可以解决好多线程问题，但是另外一个问题同时产生，
那就是这样的代码，效率相对比较低，破坏了多线程机制。
如果在代码部署在服务器端，在对象创建的开始时，如果有两个客户端访问，
那么一个进入了锁对象，那么他必然会获得锁对象，
而另一个只有等待第一个用户完成后才能进入getIntances方法来获取对象。
并且对于对象创建完成之后，所有的getInstance方法来说，
都是读取这个进程，
但每次都会有一个锁对象。那么资源是浪费的。如果高并发的情况，也会拖累效率。
*/
//线程安全版本，但锁的代价过高
Singleton* Singleton::getInstance() {
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
/*
那么，为了解决以上的问题，如果为空的情况，
也就是创建的时候才去创建锁对象
通过这样的方法可以避免在读取的时候每次都创建锁对象。
但是在这个代码中，必须要对所创建的对象判空两次。
因为如果只判一次空，还是会出现线程安全的问题。
*/
//双检查锁，但由于内存读写reorder不安全
Singleton* Singleton::getInstance() {
if(m_instance==nullptr){
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
}
return m_instance;
}
/*
对于双检查看起来已经很好的完成了Singleton的要求和线程安全的问题。但实际上很容易出问题。
但是以上的代码实际存在漏洞，双检查在内存读写时会出现reorder不安全的情况。
reorder：我们看代码有一个指令序列，但代码在汇编之后，可能在执行的时候，抢CPU的指向权的时候，可能和我们预想的不一样。
一般m_instance = new Singleton();只想的时候我们认为是先分配内存，再调用构造函数创建对象，再把对象的地址赋值给变量。
但在CPU实际执行的时候，以上的三个步骤可能会被重新打乱顺序执行。
可能会是先分配内存，然后就把内存地址直接赋值给变量，最后在调用构造函数来创建对象。
那么如果出现以上的reorder的情况，变量已经被赋值了对象的指针，但实际却指向了没被初始化的内存。
那么此时，线程安全问题就再次出现了。
*/
/*
在java和C#这类语言来说，增加了一个volatile关键字，通过他来修饰单例的对象，此时编译器不会在进行reorder的优化编译，以此保证代理的正确性。
2005年VC的编译器自己添加了volatile关键字，但跨平台的问题没办法解决。直到C++11后才真正的解决了这个问题，实现了跨平台。
具体代码如下：
*/
//C++ 11版本之后的跨平台实现 (volatile)
std::atomic<Singleton*> Singleton::m_instance; //首先声明了一个原子的对象。
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance.load(std::memory_order_relaxed);//通过原子的对象的load方法获得对象的指针。
std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence
//此时编译不会被reorder
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(m_mutex);
tmp = m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton;
std::atomic_thread_fence(std::memory_order_release);//释放内存fence
m_instance.store(tmp, std::memory_order_relaxed);
}
}
return tmp;
}
Singleton的UML
要点总结
- Singleton模式中的实力构造器可以设置为protected，以允许子类派生
- Singleton模式一般不要支持拷贝构造函数和Clone接口，因为有可能会导致多个对象实例，与Singleton模式的初衷相违背。
- 如何实现多线程环境下安全的Singleton？注意对双检查锁的正确实现。
享元模式FlyWeight
运用共享技术有效地支持大量的细粒度对象
——《设计模式》GoF
- 动机
在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行是代价——主要指内存需求方面的代价。
FlyWeight的UML
以下是一个示意性的伪码，具体FlyWeight的实现可能千差万别
而他的主要思想其实就是设置好一个对象池，如果对象的销毁则返回到池中，需要使用对象则可以从池中获取所需要的对象，进而把创建对象变为一种取用的模式。而避免在在每次使用该对象的时候都重新创建。如此的方案，第一可以解决某个对象数量不可控的问题，第二也可以解决对于某些对象创建过程消耗很大的问题。
以下的代码为一个字处理的系统，把字体看做为一种对象。
严格意义上讲，每个字符都对应着他的字体。但实际在使用的过程中，一篇文章来说也就只有几种字体对象而已，如果为每个对象都创建了一个字体对象，那么会造成字体对象的大量膨胀，并且这样的膨胀也更是没有意义的。
class Font {
private:
//unique object key
string key;
//object state
//....
public:
Font(const string& key){
//...
}
};
class FontFactory{
private:
//字体对象池
map<string,Font* > fontPool;
public:
Font* GetFont(const string& key){
//根据key来在池子中查找字体对象
map<string,Font*>::iterator item=fontPool.find(key);
if(item!=footPool.end()){
return fontPool[key]; //查找到的就返回这个字体对象
}
else{
//没有被创建过的对象，则新创建一个，并放入池中
Font* font = new Font(key);
fontPool[key]= font;
return font;
}
}
void clear(){
//...
}
};
通过以上的字体池的问题，可以避免一篇文章具有十万个字符，用到了十万个字体对象，而大量的字体对象都是重复的。FlyWeight共享的对象一旦创建则无法改变，所以该对象应该是只读的。
要点总结
- 面向对象很好的解决了抽相性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向的代价问题，一般不触及面向对象的抽象性问题。
- Flyweight采用对象共享的做法来降低系统中的对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对像状态的处理。
- 对象的数量太大，从而导致对像内存开销加大——什么样的数量才算大？这需要我们仔细根据具体应用情况进行评估，而不能凭空臆断。
