Detailed explanation of pooling technology - object pool, connection pool, thread pool

In the process of application system development, pooling technologies are often used, such as object pools, connection pools, thread pools, etc., to reduce some consumption and improve performance through reuse technology.
1. The object pool reduces the overhead of creating objects and garbage collection by reusing objects;
Note, the pool should not be too large, too large will affect the scanning time during GC
2. Connection pools, such as database connection pool/Redis connection pool/HTTP connection pool,
Improve performance by reducing the time to create and release connections by multiplexing TCP

connections Commons-pool2 technical implementation, commons-pool1 is not recommended.

****************************Database Connection Pool******************** ************

There are many implementations of database connection pools, such as C3P0, DBCP, Druid, etc. KT uses Durid and DBCP the most.
Example: commons-dbcp2 2.1.1
1.DBCP connection pool configuration
    <!-- dbcp2 configuration file--> 
    <bean id="propertyConfigurer" 
        class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
        <property name ="location" value="classpath:jdbc.properties" /> 

 
    <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource" 
        destroy-method="close">
       
        <property name="driverClassName" value="${driver}" /> 
       
        <!-- database Connection related configuration (URL username and password test Query default timeout) -->
        <property name="url" value="${url}" /> 
        <property name="username" value="${username}" / > 
        <property name="password" value="${password}" /> 
       
        <!-- Statement default timeout, in seconds-->
        <property name="defaultQueryTimeout" value="3"/>
        <!- - Whether to automatically commit transactions by default -->
        <property name="defaultAutoCommit" value="false"/>
       
        <!-- Database connection properties: different database configurations are different -->
        <property name="connectionProperties" value="connectionTimeout=2000;socketTimeout=2000"/>
       
        <!-- The default connection pool queue type is LIFO, false means FIFO -->
        <property name="lifo" value="false"/ >
       
        <!-- It is recommended that the following values ​​be the same as possible, and there is no need to frequently expire idle connections (unless there is a shortage of connection pool resources, etc.) -->
        <property name="initialSize" value="${initialSize}"/ > <!-- Initialize connection size-->
        <property name="minIdle" value="${minIdle}"/> <!-- Minimum idle connection pool-->
        <property name="maxIdle" value="$ {maxIdle}"/> <!-- Maximum idle connection pool-->
        <property name="maxTotal" value="${maxTotal}"/> <!-- Maximum number of connection pools--> 
         
        <!-- Waiting Get the connection maximum wait time,  It doesn't need to be too big, such as setting it at 500 milliseconds-->
        <property name="maxWaitMillis" value="${maxWaitMillis}"/> 
       
        <!-- Verify that the database connection is valid/available-->
        <property name="testOnBorrow" value="true"/><!-- ValidateConnection when getting a connection from the pool, the default is true -->
        <property name="testOnCreate" value="false"/><!- - ValidateConnection when creating a new connection, the default is false -->
        <property name="testOnReturn" value="false"/><!-- ValidateConnection when releasing the connection back to the pool, the default is false -->
        <property name= "validationQuery" value=""/><!-- If not set, call Connection#isValid(int timeout) to verify whether the database is valid -->
        <property name="maxConnLifetimeMillis" value="0"/><!-- The longest time the connection survives, <=0 means disable -->
       
        <property name="timeBetweenEvictionRunsMillis" value="0"/><!-- expel the timer execution cycle, <=0 means disable -->
        <property name="softMinEvictableIdleTimeMillis" value="0"/><!-- How long is the connection idle to be removed from the pool, <=0 means no judgment, when mindle<current number of idle connections, start this judgment-->
        <property name="minEvictableIdleTimeMillis" value="0"/> <!-- How long the connection is idle to be expelled from the pool, and the relationship with softMinEvictableIdleTimeMillis-->
        <property name="numTestsPerEvictionRun" value="0"/>< !-- How many idle objects are tested each time, <=0 is equivalent to disable-->
        <property name="testWhileIdle" value="false"/> <!-- Whether to test when the connection is idle, that is, keep the connection in stock, Use with the driver timer -->
        <property name="evictionPolicyClassName" value="org.apache.commons.pool2.impl.DefaultEvictionPolicy"/> <!-- The policy to determine whether the connection needs to be expelled, the default is DefaultEvictionPolicy -->
       
        <!-- Remove unreferenced connections (those that are not close, set to false here, you need to ensure that the connection must be released) -->
        <property name="removeAbandonedOnBorrow" value="false"/>
        <property name= "removeAbandonedOnMaintenance" value="false"/>
       
        <!-- No reference connection will be closed after timeout, unit: seconds-->
        <property name="removeAbandonedTimeout" value="10"/>
    </bean> 

Description:

[Database connection configuration]
Note that these properties can also be configured in the JDBC URL ?proName=prop Value

[Pool Configuration]

[Verify that the database connection is valid Performance ]
Three methods: active test, timed test, close orphan connection

[close orphan connection]



2. DBCP configuration recommendation
2.1 In the case of large concurrency:
(1) Set several pool sizes to the same
(2) Disable orphan closing The connection
(3) disables the timer
as follows:
    <!-- dbcp2 configuration file--> 
    <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource" 
        destroy-method="close">     
        <!- - Omit url username password -->
        <!-- Statement default timeout, unit: seconds -->
        <property name="defaultQueryTimeout" value="3"/>
        <!-- Whether to automatically commit transactions by default -->
        <property name="defaultAutoCommit" value="false"/>
        <!-- Database connection properties: different database configurations are different-->
        <property name="connectionProperties" value="connectionTimeout=2000;socketTimeout=2000"/>
        <property name="testOnBorrow" value="true"/><!-- ValidateConnection when getting a connection from the pool, the default is true -->       
        <!-- The connection pool queue type defaults to LIFO, false means FIFO -->
        <property name="lifo" value="false"/>
        <!--Omit the pool configuration (the pool size is set to the same)-->
        <!-- Wait for the maximum waiting time for a connection, it does not need to be too large, for example, set it in 500 milliseconds --> 
        <property name="maxWaitMillis" value="500"/> 
        <property name="timeBetweenEvictionRunsMillis"value="0"/><!-- Expel the timer execution cycle, <=0 means disable-->
        <property name="numTestsPerEvictionRun" value="80"/><!-- How many idle objects are tested each time, <=0 is equivalent to disable -->
        <property name="testWhileIdle" value="true"/> <!-- Whether to test when the connection is idle, that is, keep the connection in stock, and use it with the driver timer -->
    </bean> 

2.2 Recommended when the amount of concurrency is not large :
(1) Set the pool size as needed
(2) Disable closing orphan connections
(3) Enable timer (note that MYSQL is automatically disconnected after 8 hours of idle time)
as follows:
    <!-- dbcp2 configuration file --> 
    <bean id="dataSource " class="org.apache.commons.dbcp2.BasicDataSource" 
        destroy-method="close">     
        <!-- Omit url username password -->
        <!-- Statement default timeout, unit: seconds -->
        <property name="defaultQueryTimeout" value="3"/>
        <!-- Whether to automatically commit transactions by default -->
        <property name="defaultAutoCommit" value="false"/>
        <!-- Database connection properties: different database configurations are different -->
        <property name="connectionProperties" value="connectionTimeout=2000;socketTimeout=2000"/>
        <property name="testOnBorrow" value="false"/><!-- ValidateConnection when getting a connection from the pool, the default is true -->       
        <!-- The default connection pool queue type is LIFO, false means FIFO -->
        <property name="lifo" value="false"/>
        <!--Omit the pool configuration (the pool size is set to the same)-- >
        <!-- Wait for the maximum waiting time to obtain the connection, it does not need to be too large, for example, set it at 500 milliseconds--> 
        <property name="maxWaitMillis" value="500"/> 
        <property name="timeBetweenEvictionRunsMillis" value="3600000 "/><!-- Expel the timer execution cycle, <=0 means disable -->
    </bean>

Summary:
(1) Either way, the timeout must be set
(2) The connection pool must be destroyed when the JVM is shut down/restarted (bean is set to destroy-method="close")
   

3. Implementation of database-driven timeout

4. Some suggestions for connection pool usage
(1) Pay attention to the cascading effect that occurs when the network is blocked/unstable, and there are too many people currently waiting for the connection pool, such as 1000, then the next wait is meaningless, and it will also cause a rolling demand effect.
Recommendation:
Use fuse and fast failure mechanism, that is, according to the current network status (such as too many timeouts), all requests within a certain period of time (such as 100ms) should be timed out in the connection pool, and no await(maxAwait) should be performed at all

(2) The problem that DBCP is more likely to occur is: setting the timeout time is too long, causing a large number of TIMED_WAIT and thread blocking, and like a snowball, once a problem occurs, it is difficult to understand and recover, and it can be solved through the context solution.
The waiting timeout time should be as small as possible. Even if an error page is returned, it is better than waiting and blocking.

1. The problem that the database server disconnects the timeout
connection in the database connection pool application. Instances, and these connection instances do not regularly detect whether the connection to the database server is normal; at the
same time, the database server has a timeout time for the database connection instance, after which it will automatically disconnect.
That is, the disconnected connection is still stored in the application's database connection pool at this time, and the next time it is used, the database connection will be disconnected, resulting in an access failure.

Recommended solutions:
1) If such a detection mechanism can be provided to periodically detect the validity of the connections in the connection pool in the connection pool management of the application, the problems described above can be completely avoided.
2) The reprocessing of the business is realized through the exception handling mechanism in the application code, which can also be well avoided.
3) Reference for disconnection and automatic reconnection of connection pools such as C3P0, Proxool, BoneCP, and Druid
: https://www.oschina.net/question/59889_44927
Reference: http://blog.csdn.net/shirdrn/article/details/8248814

<property name="driverClass" value="${jdbc.driver}" /> com.mysql.jdbc.Driver
<property name=" driverClass" value="oracle.jdbc.driver.OracleDriver" />
http://blog.sina.com.cn/s/blog_85d71fb70101ab99.html

Spring with C3P0
http://blog.csdn.net/vebasan/article/details /5059000

Initializing c3p0 pool... com.mchange.v2.c3p0.ComboPooledDataSource stuck
Solution: It must be the network, the wrong username and password cause



******************** ************HttpClient Connection Pool**********************************
See " HttpClient Detailed Explanation"



****************************Java Thread Pool************** ****************************
Overall: thread pool, improve performance by reusing threads;

background:
Threads are an operating system concept. The operating system is responsible for creating, suspending, running, blocking, and terminating the thread. The operating system needs to perform CPU scheduling to create threads, switch thread states, and terminate threads, which is a time-consuming and system resource-consuming thing.

In the following scenarios:
the time to process a request is very short, but the number of requests is huge. If a separate thread is created for each request, then all the resources of the physical machine are basically occupied by the operating system creating threads, switching thread states, and destroying threads, and the resources used for business request processing are reduced instead.
In addition, some operating systems have a maximum number of threads. When the number of running threads approaches this value, the operating system becomes unstable. This is why we want to limit the number of threads. Each thread needs a memory stack for storing local variables, operation stacks and other information. The size of each thread stack is adjusted by the -Xss parameter (64-bit system defaults to 1024kb, which can be reduced according to actual needs, such as 256KB)
by adjusting This parameter can create more threads, but the JVM cannot create unlimited threads.

The most ideal processing method is to control the number of threads processing requests within a range, which not only ensures that subsequent requests will not wait for too long, but also ensures that the physical machine Use sufficient resources for the request processing itself.
Use thread pool: The thread pool will limit the number of threads created to protect the system; the thread pool will work with the queue to limit the number of concurrently processed tasks. When the task exceeds the limit, it can be processed through a certain strategy to avoid the system
caused by large traffic. Crash - just a partial denial of service, or a part of normal service.
 
The thread pool is divided into: the core thread pool and the maximum number of thread pools. Threads in the thread pool will be recycled when idle for a period of time, but core threads will not be recycled.

Appropriate number of threads:
(1) It is recommended to measure and decide according to the actual business situation
(2) Little’s Law: In a stable system, the average number of users observed for a long time L = the effective reach rate observed for a long time* Average time spent on the system by each user.
For (2) the actual situation is more complicated, such as: in processing timeout, network jitter will cause threads to spend different time.

In view of the fact that in processing timeout, network jitter will cause threads to spend different time, and the number of threads may be unreasonable. It is necessary to consider: timeout mechanism, thread isolation mechanism, fast failure mechanism, etc. to protect the system

Java language provides us with two basic threads Choice of pool: ScheduledThreadPoolExecutor and ThreadPoolExecutor. They all implement the ExecutorService interface
(note that the ExecutorService interface itself is not directly related to "thread pool", its definition is closer to "executor", and "implementation using thread management" is just one of the implementation methods) .
In this article, we mainly explain the ThreadPoolExecutor class.


Java provides three implementations of ExecutorService
(1) ThreadPoolExecutor: standard thread pool
(2) ScheduledThreadPoolExecutor: thread pool that supports delayed tasks
(3) ForkJoinPool:
similar to ThreadPoolExecutor, but using the work-stealing mode, it will be used for each thread pool in the thread pool. Each thread creates a queue, so that the work-stealing algorithm allows threads
to steal tasks from other thread queues to execute. That is, if your own task processing is completed, you can go to the busy worker thread to steal the task execution.


****************************Tomcat Thread Pool******************** ********************
See <<Tomcat Practice>> [2.1.5 Connection Pool Configuration]