Introduction to multithreading (4) some ideas on the problem of cachedthreadpool outofmemoryerror

Navigation of this series of articles

Java multithreading (1)-method join

Java multithreading (2)-EDT in Swing (event distribution thread)

In-depth introduction to multithreading (3)-Future asynchronous mode and its implementation in the JDK1.5Concurrent package

Introduction to multithreading (4) some ideas on the problem of CachedThreadPool OutOfMemoryError

Deep introduction to multithreading (5) use the parallel package thread pool as an example to describe the design requirements and usage of the thread pool

Deep introduction to multithreading (6) Design and implementation of parallel package Thread Pool

 

In Series 3, we will discuss CachedThreadPool together.

The thread pool is an important gift provided to us by the Conncurrent package. This makes it unnecessary for us to maintain a thread pool with no bottom in our own implementations. But how can we make full use of these thread pools to accelerate our development and testing efficiency? Of course, it is "Know Yourself" and "Know yourself. This series will talk about the use of CachedThreadPool.

The following is a test of CachedThreadPool. Is there a problem with the program?

package concurrentstudy;</p><p>import java.util.concurrent.ExecutorService;<br />import java.util.concurrent.Executors;</p><p>public class CachedThreadPoolIssue {<br />public static void main(String[] args) {<br />ExecutorService es = Executors.newCachedThreadPool();<br />for (int i = 1; i < 8000; i++)<br />es.submit(new MyTask());<br />}<br />}</p><p>class MyTask implements Runnable {<br />public void run() {<br />try {<br />Thread.sleep(4000);<br />} catch (InterruptedException e) {<br />e.printStackTrace();<br />}</p><p>}</p><p>}<br />

If there are no special JVM settings and the settings are on the Window platform, an exception occurs:

 

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
　 at java.lang.Thread.start0(Native Method)
　 at java.lang.Thread.start(Unknown Source)
　 at java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(Unknown Source)
　 at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
　 at java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
　 at net.blogjava.vincent.CachedThreadPoolIssue.main(CachedThreadPoolIssue.java:19)

Take a look at the Doc introduction to this thread pool:

Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available. these pools will typically improve the performance of programs that execute implements short-lived asynchronous tasks. callto execute will reuse previusly constructed threads if available. if no existing thread is available, a new thread will be created and added to the pool. threads that have not been used for sixty seconds are terminated and removed from the cache. thus, a pool that remains idle for long enough will not consume any resources. note that pools with similar properties but different details (for example, timeout parameters) may be created using ThreadPoolExecutor constructors.

Note the following:

1. It indicates that the previous thread will be reused, which is good.

2. Improve the throughput of short tasks.

 

3. If the thread is not used for 60 s, the Cache will be removed.

It seems that it has nothing to do with the previous error. In fact, the first sentence is the problem. It creates a new thread as needed. In the above example, we will submit 8000 tasks, this means that the thread pool will create 8000 threads. Of course, this is much higher than the JVM limit.

Note: In jdk1.5, each thread uses 1 MB of memory by default, 8000 MB !!! Possible !!

Therefore, I think this should be the first concurrent deficiency I encountered. In this case, I should point out in the doc that a large number of tasks should be used to avoid being submitted to the cachedthreadpool.

The following example shows the thread he created.

In the API provided by threadpoolexecutor, we can see that it provides beforeexecute and afterexecute methods that can be reloaded in the subclass. This method is called before and after the thread pool thread executes the task. So we can check the current thread number in beforeexexute to determine the current number of threads.

package concurrentstudy;</p><p>import java.util.concurrent.BlockingQueue;<br />import java.util.concurrent.ExecutorService;<br />import java.util.concurrent.SynchronousQueue;<br />import java.util.concurrent.ThreadPoolExecutor;<br />import java.util.concurrent.TimeUnit;</p><p>public class CachedThreadPoolIssue {<br />public static void main(String[] args) {<br />ExecutorService es = new LogThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());<br />for (int i = 1; i < 8000; i++)<br />es.submit(new task());<br />}<br />}</p><p>class task implements Runnable {<br />public void run() {<br />try {<br />Thread.sleep(600000);<br />} catch (InterruptedException e) {<br />e.printStackTrace();<br />}<br />}<br />}</p><p>class LogThreadPoolExecutor extends ThreadPoolExecutor {<br />public LogThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {<br />super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);<br />}</p><p>protected void beforeExecute(Thread t, Runnable r) {<br />System.out.println(t.getName());<br />}</p><p>protected void afterExecute(Runnable r, Throwable t) {<br />}</p><p>}

 

Test Results

{
Function onclick ()
{
Function onclick ()
{
Function onclick ()
{
Get_larger (this)
}
}
}
} "Src =" http://p.blog.csdn.net/images/p_blog_csdn_net/hemingwang0902/EntryImages/20090916/6.jpg "alt =" Deep introduction to multithreading (4) some ideas on the problem of cachedthreadpool outofmemoryerror ">

If the number of threads reaches 5592, Kill the process only in the task manager.

How can we solve this problem? In fact, we can see it just now when instantiating it.

new LogThreadPoolExecutor(0, Integer.MAX_VALUE,
　　　　　　　　60L, TimeUnit.SECONDS,
　　　　　　　　new SynchronousQueue<Runnable>());

Set Integer. MAX_VALUE to an appropriate size. The meaning of this parameter involves the implementation of the thread pool, which will be pointed out in the next series.

Of course, other solutions are to control the Task submission rate and avoid exceeding the maximum limit.

 

Blog Source:Http://www.cqzol.com/programming/580435.html