Configuration instructions:
Starting Spring 3.0, and has a configuration XML TaskScheduler TaskExecutor namespace for instance. It also provides a convenient way to configure a task to use the trigger arrangement.
The task scheduler configuration detailed parameter descriptions:
Task: Scheduler / @ the pool-size: the size of the thread pool scheduling, dispatching thread will not be idle before the scheduled completion of the task
task: scheduled / @ cron: cron expression, note that if the unfinished missions, even to the next scheduled time, the task will not be repeated scheduling
<task:scheduled-tasks scheduler="scheduler"> <task:scheduled ref="beanID" method="methodName" cron="CronExp" /> </task:scheduled-tasks> <task:scheduler id="scheduler" pool-size="10" />
Task executor configuration details Parameters:
Task: Executor / @ the pool-size: may be designated to perform the initial size of the thread pool, the maximum size of the
task: executor / @ queue-capacity : waiting capacity execution task queue
task: executor / @ rejection -policy: when the policy burst queue waiting time is divided into discarded, run directly by the task executor, etc.
<task:executor id="executor" keep-alive="3600" pool-size="100-200" queue-capacity="500" rejection-policy="CALLER_RUNS" />
As can be seen from that configuration, but also provides a "queue size" value. The queue capacity should be considered in executing a program configured thread pool. A complete description of the relationship between cell size and queue capacity, see ThreadPoolExecutor documentation. The main idea is that when you submit the task, if the number of active threads is smaller than the current size of the core, the implementation of the program will first attempt to use idle threads. If you've reached the core size, as long as it has not yet reached capacity, the task will be added to the queue. Only in this way, if the queue has reached capacity, the implementation of the program whether to create a new thread beyond the core size. If you have reached the maximum size, the program will refuse to execute the task.
By default, the queue is unlimited, but this is rarely the desired configuration, because if enough task is added to the queue at the pool all threads busy situations, it may lead to OutOfMemoryErrors. In addition, if the queue is unbounded, then the maximum size of no effect. Since the actuator will always try to queue before creating a new thread beyond the core size, so the queue must have a limited capacity to make the thread pool growth beyond the core size (which is why fixed-size pool is the only reasonable in the circumstances when the use of an infinite the queue).
Later, we will review the effect of keeping active set, which adds another factor in providing the pool size configuration to be considered. First, as noted above, let us consider the case of a rejected task. By default, when a task is rejected, the thread pool executor will throw TaskRejectedException. But, in fact, reject the policy is configurable. Use the default reject will throw an exception when a policy (AbortPolicy achieve). For certain tasks may be skipped at high load applications, or may be configured DiscardPolicy DiscardOldestPolicy. Another option for applications that require restrictions task submitted under high load applications is CallerRunsPolicy. This policy does not throw an exception or discard task, but rather to force the calling thread submit their own method of running the task. The idea is that this will be very busy when the caller is running the task, while other tasks can not be submitted immediately. As such, it provides an easy way to restrict incoming load, while maintaining restrictions thread pool and queues. Typically, this allows the execution of the program to "catch up" the task it is processing, thereby releasing the queue, or both, some of the pool capacity. Any of these options may be selected from the 'executor' value enumerate available elements 'rejection-policy' attribute.
Finally, keep-alive thread is provided before the termination determination may remain idle time limit (in seconds). If the pool currently has more than one thread core number, then after a waiting period without processing task, excess threads will be terminated. Time value of zero will cause excess threads to terminate immediately after the mission, but not retained in the follow-up to the task queue.
<task:annotation-driven executor="taskExecutor" scheduler="taskScheduler"/>
There are other one configuration:
< Bean the above mentioned id = "taskExecutor" class = "org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor" > <-! Minimum number of threads in the thread pool maintenance -> < Property name = "corePoolSize" value = "$ {taskExecutor.corePoolSize } " /> <! - allowed idle time -> < Property name =" keepAliveSeconds " value =" $ {taskExecutor.keepAliveSeconds} " /> <! - the maximum number of threads in the thread pool maintenance -> < Property name = "maxPoolSize" value="${taskExecutor.maxPoolSize}" /> <! - buffer queue -> < Property name = "queueCapacity" value = "$ {taskExecutor.queueCapacity}" /> <! - the processing task of the rejection strategy -> < Property name = "RejectedExecutionHandler" > < bean class = "java.util.concurrent.ThreadPoolExecutor $ CallerRunsPolicy" /> <-! AbortPolicy: direct throw an exception java.util.concurrent.RejectedExecutionException -> ! <- CallerRunsPolicy: direct the main thread to perform the task, execution try to add a task to the next thread pool, you can add tasks effectively reduce the speed to the thread pool after completing -> <-! DiscardOldestPolicy:Discard the old mission, it will not support; will lead the task can not be dropped again be executed -> <-!DiscardPolicy: abandon the current task, not supported; may lead to discarded task can not be performed again -> </ Property > </ bean > < Task: Annotation-Driven Executor = "taskExecutor" Scheduler = "TaskScheduler" /> < Task: Scheduler ID = "TaskScheduler" the pool-size = ". 5" />
Properties Field Description
corePoolSize: thread pool to maintain the minimum number of threads
keepAliveSeconds: allowed free time
maxPoolSize: thread pool to maintain the maximum number of threads
queueCapacity: buffer queue
rejectedExecutionHandler: treatment strategy of denial task
execute (Runable) execution method
If at this time the number of threads in the pool is less than corePoolSize, even if the threads in the pool are idle, but also to create a new thread to handle the tasks are added.
At this time, if the number of threads in the pool is equal corePoolSize, but workQueue buffer queue is not full, the task is placed in the buffer queue.
At this time, if the number of threads in the pool is greater than corePoolSize, workQueue buffer queue is full, and the number of threads in the pool is less than the maxPoolSize, build a new thread to process the task is added.
At this time, if the number of threads in the pool is greater than corePoolSize, workQueue buffer queue is full, and the number of threads in the pool is equal to the maxPoolSize, then processed by the task handler specified policy. That is: the priority processing tasks are: core thread corePoolSize, task queue workQueue, maximum thread maximumPoolSize, if all three are full, use handler processing task rejected.
When the number of threads in the pool is greater than when corePoolSize, if the idle time exceeds a thread keepAliveTime, the thread is terminated. In this way, the thread pool can dynamically adjust the number of threads in the pool.
