Object performance mode-single-piece mode and Hengyuan mode

Single-piece mode; the
previous modes are all related to the overall design of the project, such as high cohesion, loose coupling, polymorphism, and isolation. But the object performance model is not based on these design patterns, but from the performance of the software. In fact, the singleton implemented with many types of objects in the company code has the same meaning, and the only purpose is if the objects of this type are in When the project has a high frequency, if you need to constantly new objects in a routine, then the memory consumption is not conducive to the performance of the project. Therefore, there are two modes of object performance mode. The purpose is to achieve that in the entire project, there is no need to always go to the new object, but only the new one, which is good for judging if there is no new one, and if there is, use the previous one directly. The meaning is very simple, but it is more troublesome to implement it and consider multi-threading.

For example:

For multi-threading, locking can be solved. For
example,

reading variables does not require locking, and locking is only required when writing to prevent repeating different operations. Therefore, if you are reading and acquiring the lock, it will also cause the cost of the lock.

Then we double check the lock, if the object is empty, we will acquire the lock before going to the new object

class Signal
{
public:
	Signal();
	~Signal();
	static Signal * getSignal();
private:
	static Signal * stdSignal;
};
Signal * Signal::getSignal()
{
	if (stdSignal == nullptr)//两次检查、如果只是读那么就不需要去获取锁了。
	{
		Lock lock;
		if (stdSignal == nullptr)
		{
			return new(Signal);
		}
	}
	return stdSignal;

}

But there are also problems, because we judge based on if (stdSignal == nullptr)//, but our computer compiler is actually divided into three steps when we new an object, 1. apply for memory, 2. call Constructor, 3, Assignment, but this is only the default order. In a multi-core computer, the order of execution may also be 132. Then in combination with multithreading, there may be threads that set the value without calling the constructor when creating the object. Back out, this is the famous Reoeder insecurity problem.

Finally, there is a safe method in C++ 11

Sharing source mode uses sharing technology to effectively support a large number of fine-grained objects. (The popular point is to use a shared pool (which can be a variety of containers) to manage objects. If it exists, it will return directly, if not, create and return, similar It is used when the single-piece mode is single, and the Flyweight is a series of a large number of fine-grained objects) Therefore, whether it is necessary to use the Flyweight mode needs to be evaluated.
For example

Fornt::Fornt()
{
	string key;
	Fornt(string key){};
}
class ForntFactory
{
public:
	ForntFactory();
	~ForntFactory();
	map<string, Fornt*> forntPoll;
	Fornt * GetFornt(string key)
	{
		bool isExit = forntPoll.find(key);//查找共享池是否存在
		if (!isExit)//存在
		{
			;//返回
		}
		else
		{
			//否则创建。
			//加入共享池，再返回
		}
	}
private:

};

The general logic is like this