单例实例作为静态字段与getInstance（）方法中的静态变量
在这个线程中，关于单例实例的内容如下：
静态变量可以是GetInstance（）函数的静态变量，也可以是Singleton类中的静态变量。 那里有一些有趣的折衷。
这些折衷是什么？ 我知道，如果声明为static函数变量，那么在函数第一次调用之前，单例不会被构造。 我也读过一些关于线程安全的内容，但并不知道究竟是什么，或者这两种方法在这方面有何不同。
两者之间是否还有其他重大差异？ 哪种方法更好？
在我的具体例子中，我有一个工厂类设置为单例，并且将该实例作为static const字段存储在类中。 我没有getInstance()方法，而是期望用户直接访问实例，如下所示： ItemFactory::factory 。 默认构造函数是私有的，并且实例是静态分配的。
附录：重载operator()为singleton调用createItem()方法的想法有多好，例如Item的创建方法如下： ItemFactory::factory("id") ？
这些折衷是什么？
这是最重要的考虑因素：
static数据成员在程序启动时的静态初始化期间被初始化。 如果任何static对象依赖于单例，那么会有一个static初始化顺序失败。
当函数被第一次调用时，函数local static对象被初始化。 因为依赖单身人士的人会调用这个函数，所以单身人士会被适当地初始化，并且不会受到失败的影响。 破坏仍然存在 - 非常微妙的问题。 如果静态对象的析构函数依赖于单例，但该对象的构造函数不包含，那么最终会导致未定义的行为。
而且，在第一次调用函数时进行初始化，意味着可以在完成静态初始化并调用main之后调用该函数。 因此，该程序可能产生了多个线程。 初始化static本地时可能存在争用条件，导致构建多个实例。 幸运的是，自C ++ 11以来，该标准保证了初始化是线程安全的，并且这种折衷在编译器中不再存在。
线程安全性不是static数据成员的问题。
哪种方法更好？
这取决于您的要求和您支持的标准版本。
我投票给静态函数变量。 较新的C ++标准要求自动线程安全来初始化这些变量。 它已经在GNU C ++中实现了大约十年。 Visual Studio 2015也支持这一点。 如果你创建一个静态指针变量来保存对你的单例对象的引用，你将不得不手动处理线程问题。
另一方面，如果你创建一个如下代码片段所示的静态成员指针字段，你将能够从其他静态方法中改变它，也许在处理请求时重新初始化该字段以更改程序配置。 但是，下面的代码片段包含一个错误，只是为了提醒您多线程是多么的困难。
class ItemFactory {
static std::atomic_flag initialized = ATOMIC_FLAG_INIT;
static std::unique_ptr<ItemFactory> theFactoryInstance;
public:
static ItemFactory& getInstance() {
if (!initialized.test_and_set(std::memory_order_acquire)) {
theFactoryInstance = std::make_unique<ItemFactory>();
}
return *theFactoryInstance;
}
};
我不建议你在进入main()函数之前将你的单例实现为一个全局非指针变量。 线程安全问题会随着隐式高速缓存一致性消失而消失，但无法以任何精确或便携的方式控制全局变量的初始化顺序。
无论如何，这个选择并不会强迫任何永久设计的影响。 由于这个实例将驻留在你的类的private部分，所以你可以随时更改它。
我不认为为工厂重载operator（）是个好主意。 operator()在工厂中具有“执行”语义，它将代表“创建”。
什么是在C ++单身人士的最佳方法？
隐藏它是一个单例并给它赋值语义的事实。
怎么样？
所有的单例都应该是一个实现细节。 这样，如果你需要改变你实现你的单例的方式（或者如果你确定它不应该是单身人士），你的班级的消费者不需要重构他们的程序。
为什么？
因为现在你的程序永远不用担心引用，指针，生命期和什么。 它只是使用对象的一个实例，就好像它是一个值。 安全的知识，单身人士会照顾它所具有的任何生命/资源需求。
如何在不使用时释放资源的单身人士呢？
没问题。
下面是使用值语义隐藏在对象外观背后的两种方法的示例。
想象一下这个用例：
auto j1 = jobbie();
auto j2 = jobbie();
auto j3 = jobbie();
j1.log("doh");
j2.log("ray");
j3.log("me");
{
shared_file f;
f.log("hello");
}
{
shared_file().log("goodbye");
}
shared_file().log("here's another");
shared_file f2;
{
shared_file().log("no need to reopen");
shared_file().log("or here");
shared_file().log("or even here");
}
f2.log("all done");
jobbie对象只是一个singleton的外观，但shared_file对象想要在不使用时刷新/关闭自己。
所以输出应该如下所示：
doh
ray
me
opening file
logging to file: hello
closing file
opening file
logging to file: goodbye
closing file
opening file
logging to file: here's another
closing file
opening file
logging to file: no need to reopen
logging to file: or here
logging to file: or even here
logging to file: all done
closing file
我们可以用成语来实现这一点，我将其称为“价值语义 - 是一种单一的外观”：
#include <iostream>
#include <vector>
// interface
struct jobbie
{
void log(const std::string& s);
private:
// if we decide to make jobbie less singleton-like in future
// then as far as the interface is concerned the only change is here
// and since these items are private, it won't matter to consumers of the class
struct impl;
static impl& get();
};
// implementation
struct jobbie::impl
{
void log(const std::string& s) {
std::cout << s << std::endl;
}
};
auto jobbie::get() -> impl& {
//
// NOTE
// now you can change the singleton storage strategy simply by changing this code
// alternative 1:
static impl _;
return _;
// for example, we could use a weak_ptr which we lock and store the shared_ptr in the outer
// jobbie class. This would give us a shared singleton which releases resources when not in use
}
// implement non-singleton interface
void jobbie::log(const std::string& s)
{
get().log(s);
}
struct shared_file
{
shared_file();
void log(const std::string& s);
private:
struct impl;
static std::shared_ptr<impl> get();
std::shared_ptr<impl> _impl;
};
// private implementation
struct shared_file::impl {
// in a multithreaded program
// we require a condition variable to ensure that the shared resource is closed
// when we try to re-open it (race condition)
struct statics {
std::mutex m;
std::condition_variable cv;
bool still_open = false;
std::weak_ptr<impl> cache;
};
static statics& get_statics() {
static statics _;
return _;
}
impl() {
std::cout << "opening filen";
}
~impl() {
std::cout << "closing filen";
// close file here
// and now that it's closed, we can signal the singleton state that it can be
// reopened
auto& stats = get_statics();
// we *must* use a lock otherwise the compiler may re-order memory access
// across the memory fence
auto lock = std::unique_lock<std::mutex>(stats.m);
stats.still_open = false;
lock.unlock();
stats.cv.notify_one();
}
void log(const std::string& s) {
std::cout << "logging to file: " << s << std::endl;
}
};
auto shared_file::get() -> std::shared_ptr<impl>
{
auto& statics = impl::get_statics();
auto lock = std::unique_lock<std::mutex>(statics.m);
std::shared_ptr<impl> candidate;
statics.cv.wait(lock, [&statics, &candidate] {
return bool(candidate = statics.cache.lock())
or not statics.still_open;
});
if (candidate)
return candidate;
statics.cache = candidate = std::make_shared<impl>();
statics.still_open = true;
return candidate;
}
// interface implementation
shared_file::shared_file() : _impl(get()) {}
void shared_file::log(const std::string& s) { _impl->log(s); }
// test our class
auto main() -> int
{
using namespace std;
auto j1 = jobbie();
auto j2 = jobbie();
auto j3 = jobbie();
j1.log("doh");
j2.log("ray");
j3.log("me");
{
shared_file f;
f.log("hello");
}
{
shared_file().log("goodbye");
}
shared_file().log("here's another");
shared_file f2;
{
shared_file().log("no need to reopen");
shared_file().log("or here");
shared_file().log("or even here");
}
f2.log("all done");
return 0;
}
上一篇: Singleton instance as static field vs. static variable in getInstance() method