Three major issues of STL in server program development

When I asked some friends from the same company about the serverProgramWhen using STL in, they all answered in their own company's server program development, generally not using STL.
Why is the standard library unpopular in the server program development environment? I think STL has three major problems in a highly stable, high-performance, and high-concurrency environment like server programs.

Question 1: You cannot determine how STL manages memory. Assuming that the content is managed according to the default STL method, after a long period of memory allocation and release, the server may easily cause memory fragmentation and affect the stability of the server. However, if I have not read the source code of STL, who can find out exactly how STL manages memory? Although you can use your own distributor in STL, can you confirm that some parts of STL will not be allocated memory outside the distributor?
Of course, memory management is not a problem caused by STL. Any server program should consider this issue. The reason is that few people read the source code of STL to understand the internal implementation mechanism of STL. I doubt it because I don't know it. I doubt it, so it is not easy to use it.

Problem 2: the performance of STL in massive data cannot be determined. Servers generally have a large amount of memory. To improve performance, a large amount of data is stored in the memory. Can STL meet the requirements of stability and efficiency in a very large scale of data?

Question 3: the performance of STL in a multi-threaded environment cannot be determined. The above memory and scale problems can be solved through a deeper understanding of STL and testing, but the concurrency problem under multithreading is not so easy to solve. STL is NOT thread-safe. In a multi-threaded environment, you must lock all operations on STL containers to ensure they are correct. In some high-performance scenarios, You need to optimize the concurrency under the "Read-read" condition, and some lock-independent special conditions can not be locked, even using popular RCU mechanisms ............ In this era of multi-core and concurrency, STL seems to lag behind.

Of course, STL is still a very good library. Memory Management, massive data, and concurrency problems, even if you do not use STL, you will also face these problems in your own library. At the same time, we also look forward to a standard library in a multi-threaded environment, standing on the shoulders of giants to quickly build applications.