157 recommendations for writing high-quality code to improve C # programs-Recommendation 78: Avoid too many threads

Recommendation 78: Excessive number of threads should be avoided

In most cases, creating too many threads means that there may be flaws in the architecture design of the application. Often people ask how many threads in an application are reasonable. Now let's find a PC, open the Windows Task Manager and see how many threads are running in the operating system.

On the author's current PC, one of the most threads of the application is an antivirus software, it has 116 threads, followed by the Windows own system process, there are currently a total of 104 threads The third-most process is Sqlservr.exe, which has dropped to 35 threads, and there are 63 processes remaining, estimated to have an average of about 10 threads. So, most applications don't have too many threads.

A typical example of incorrectly creating too many threads is to create a thread to manage each socket connection. Each connection to a thread means that the server on a 32-bit system cannot manage more than about 1000 clients at the same time. The CLR allocates more than 1MB of memory per thread. About 1000 threads, plus. NET process start up itself consumes some memory, immediately exhausted the system can be assigned to the process of the maximum available address space 2GB. Even though the application was described in the design requirements design book, the number of clients in the production environment would not exceed 500, and the thread context switch when managing the 500 clients would also deplete considerable CPU time. This type of I/O intensive scenario should be done asynchronously (refer to the related elaboration of recommendation 71).

Too many threads also bring another problem: the new thread may have to wait for a long time before it really runs. It was a rather helpless result, and in most cases we couldn't stand waiting so long. The following test code, in a dual-core system, takes about 5 minutes to run to thread T201:

Static voidMain (string[] args) {       for(inti =0; I < $; i++) {Thread T=NewThread (() =            {                  intj =1;  while(true) {J++;          }              }); T.isbackground=true;      T.start (); } thread.sleep ( the); Thread t201=NewThread (() =        {               while(true) {Console.WriteLine ("T201 is executing");      }          }); t201.      Start ();  Console.readkey (); } 

In addition to the startup problem, there is the same problem with switching between threads, and the next execution of the T201 will wait for a considerable amount of time.

Therefore, do not abuse threads, especially excessive threads. When you start a new thread, you need to think carefully whether the job really needs a new thread to complete. Even if you really need threads, you should consider using thread pooling technology. For example, I/o-intensive scenarios such as socket connections mentioned in this recommendation should always be considered for asynchronous use. Async is managed in the background using a thread pool. 1000 clients after using asynchronous technology, virtually all administrative work is done with just a few threads (depending on the "heartbeat Frequency").

Turn from: 157 recommendations for writing high-quality code to improve C # programs Minjia

157 recommendations for writing high-quality code to improve C # programs-Recommendation 78: Avoid too many threads