Shulou(Shulou.com)06/01 Report--

"do not use a global resource pool. Unless you really know its reasonable configuration-such as size, timeout, etc."

I've stepped on this pit twice.

The first time is Http's connection pool. I used a default PoolingHttpClientConnectionManager to make the REST service call. Unexpectedly, only two links can be created for the same domain name in the http connection pool under the default configuration. As a result, the pressure went up a little bit and it was a tragedy in an instant.

The second time is the thread pool. Spring's task:annotation-driven configuration places global @ Async annotation classes / methods and scheduled tasks in the same thread / task pool for asynchronous calls. As a result, a large number of multithreaded operations in the system timed out when some of these tasks blocked the worker thread.

In addition to these two pits, I managed to dodge one.

When you use Java 8's parallel stream to run multithreaded tasks, all threads are scheduled and run by ForkJoinPool.commonPool () by default. Similar to the problem I had the second time I stepped on the pit: if some tasks blocked the worker thread, other multithreaded tasks would pay extra wait time or even time out.

This time I used a custom ForkJoinPool to avoid this hole. And I remind myself: be careful when using global resource pools. For example, global thread pool, http/db connection pool, cache pool, and so on. Because the coverage and influence of the "overall situation" are too wide, an inadvertent mistake in one place may lead to thousands of problems. The risk is too big and too uncontrollable.

However, database connection pooling is a special case. In fact, database connection pooling also has the above risks, but in most cases, our research on database connection pooling mechanism and the configuration of size, timeout and other aspects have been relatively perfect, so there are few problems that affect application services. In addition, because database operations are so frequent, database connection pooling is a rigid requirement and cannot be done without it.

Distinguishing the use of resource pools can play the role of problem isolation. However, too many resource pools can sometimes lead to a waste of resources. Although this situation will be less likely, but once there is a problem, then it is not so easy to locate and solve.

My experience is to distinguish the types of operations (CPU intensive operations, database read and write operations, network IO, hard disk IO, etc.), and use different resource pools (such as different thread pools) for different types of operations; for the same type of operations, you can subdivide them (such as intranet IO, extranet IO, etc.), and use different resource pools on this basis.

But in the end, don't simply and rudely use a globally unified resource pool.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.