STL Memory Management

STL provides a variety of containers, and we all feel the convenience it brings to us, but it also has some problems. When I first came to Baidu and checked the encoding specifications, I saw a suggestion that I should not use STL, but use Baidu's BSL, because the memory of STL is uncontrollable, it is not suitable for Baidu's online services. I didn't understand the true meaning of this sentence at the time. I just remembered it. Even later I used it, I found that BSL actually changed STL and didn't think it was any better, it is not convenient to use STL. I just tried to use BSL instead of STL when I was doing new questions.

Currently, a project needs to load a one-to-many relationship. I didn't think about it at the time, so I wanted to open a map. The key was a unit64_t, the value was a set, and the uint was stored in the set. However, it is found that the MAP value in BSL cannot be compiled if the set type is used. In the end, I am still careless and use the map in STL and the set in STL. However, this ing will be updated every hour and needs to be reloaded. I used a dual buffer to solve this problem.ProgramAt the beginning, load the ing to the 0 position, and then find the new one. After loading it to the 1 position, release the memory at the 0 position after a period of time, the next time you reload the data, place it in the position of 1. After the program is written, it runs for a while, and there is no problem. But later I found the memory alarm. The program was very fond of memory. It could have been done without the ing of 5 Gb. Now I add this ing, and the peak will reach 20 GB. That exactly applies to a 16 GB memory machine, so there is no way. I finally changed a 48 gb memory machine, and there was no problem at last.

Later, I observed that this program did not occupy 20 GB of memory at the beginning, but encountered such a problem after running for a period of time. Later I thought about how to find out the memory allocation problem of STL. I checked on the company's wiki and found that something called pool_alloctor can solve the memory allocation problem. In fact, this pool_alloctor is a memory distributor of a memory pool. After I replace the original memory distributor with pool_alloctor, the problem still cannot be solved, and the memory alarm still occurs.

Later, I thought about it and found that my STD: Map <uint64_t, STD: Set <uint32_t> can be replaced by STD: multimap <uint64_t, uint32_t>. There was an intent that was not effective after replacement. Previously, high CPU usage was reduced, but the problem of memory allocation was still not solved.

Finally, I continued searching on the Wiki and found that the pool_alloctor can be used with the memory pool. I thought about my program. In fact, I had to apply for and release the memory frequently, and this operation was performed on multiple multimaps. Intuition tells me that if the memory allocation of these multimaps is completed by a memory pool, we should be able to solve this problem,CodeAfter the modification, I found that the memory problem that plagued me was solved.