对象性能模式
面向对象很好地解决了“抽象”的问题,但是必不可免地要付出定的代价。对于通常情况来讲，面向对象的成本大都可以忽略计。但是某些情况，面向对象所带来的成本必须谨慎处理。
典型模型：
- Singleton
- Flyweight
Singleton 单件模式
保证一个类仅有一个实例，并提供一个该实例的全局访问点。
动机
- 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。
- 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？
- 这应该是类设计者的责任，而不是使用者的责任。
就只需要一个实例，
例子
import "fmt"
type Singleton struct {
Name string
}
var instance *Singleton
// 线程不安全版本
func (self *Singleton) getInstance() *Singleton {
if instance == nil {//多个线程的话，可能会实例化多次
instance = &Singleton{}
fmt.Println("Nil")
}
return instance
}
线程安全版本一，高并发场景不适合，
var lock sync.Mutex
var once = &sync.Once{}
// 线程安全版
// 方法一：加锁
// 但成本高，每次访问都需要获取锁，就算已经不是nil了，此时每次还是需要获取锁阻塞。
func (self *Singleton) getInstance() *Singleton {
lock.Lock()
if instance == nil { //多个线程的话，可能会实例化多次
instance = &Singleton{}
fmt.Println("Nil")
}
lock.Unlock()
return instance
}
解决方法二
// 方法二:双检查锁
// 两个检查锁，只有第一次会都阻塞。
// 2000年左右，问题是内存读写的reorder
func (self *Singleton) getInstanceSecure2() *Singleton {
if instance == nil { //避免读代价高
lock.Lock()
if instance == nil {
instance = new(Singleton)
}
lock.Unlock()
}
return instance
}
对于instacne = new(Signleton)认为的执行顺序：
memory = allocate()//1. 分配内存空间
ctorInstance(memory)//2. 初始化对象，在memory上初始化Singleton对象
instance = memory//3. 设置instance指向分配的地址
但实际上由于多线程和指令优化，可能会是如下过程
memory = allocate()//1. 分配内存空间
instance = memory//3. 设置instance指向分配的地址
ctorInstance(memory)//2. 初始化对象，在memory上初始化Singleton对象
执行到3.然后释放锁，其他对象访问发现不为nil，但实际上是nil因为2还没有初始化，这样访问就会出问题。
方法三：once保证只执行一次
// go 的特殊解法
func (self *Singleton) getInstanceSecure3() *Singleton {
if instance == nil {
once.Do(func() {
instance = &Singleton{}
})
}
return instance
}
总结
-
Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初衷违背。
-
如何实现多线程环境下安全的Singleton？注意对双检查锁的正确实现。
Flyweight
运用共享技术有效地支持大量细粒度的对象。
动机
- 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价一主要指内存需求方面的代价。
- 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？
例如字符串，占用内存实际上比较大的，有的是编译器阶段。
问题
package flyweight
type Font struct {
FontName string
}
// 字体构造函数
func NewFont(name string) *Font {
return &Font{FontName: name}
}
// 字体工厂
type FontFactory struct {
FontPool map[string]*Font //字体资源池,Flyweight的思想体现
}
// 获取字体
func (self *FontFactory) GetFont(name string) *Font {
if font, ok := self.FontPool[name]; ok {
return font
} else {
font := NewFont(name)
self.FontPool[name] = font
return font
}
}
总结
- 面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
- Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。一般是只读的
- 对象的数量太大从而导致对象内存开销加大一一什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。
主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
- Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。一般是只读的
- 对象的数量太大从而导致对象内存开销加大一一什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。
