Java 并发编程之线程池的使用

最新推荐文章于 2023-08-20 22:03:04 发布

Winney_x

最新推荐文章于 2023-08-20 22:03:04 发布

阅读量1.1k

点赞数

分类专栏： java 并发编程 java Java并发编程文章标签： java 多线程并发

本文链接：https://blog.csdn.net/lingchixin/article/details/39085865

版权

java 同时被 3 个专栏收录

48 篇文章 0 订阅

订阅专栏

java 并发编程

31 篇文章 0 订阅

订阅专栏

Java并发编程

26 篇文章 2 订阅

订阅专栏

在任务与执行策略之间的隐性耦合

Executor框架可以将任务的提交与任务的执行策略解耦开来（就是独立化）。虽然Executor框架为制定和修改执行策略都提供了相当大的灵活性，但并非所有的任务都能适用所有的执行策略

比如：

依赖性任务

比如依赖于执行时序，执行结果或者其他效果，那么任务就带有隐含的依赖性。此时必须小心地维持这些执行策略以避免产生活跃性问题（死锁等造成执行困难的问题）

使用线程封闭机制的任务

与线程池相比，单线程的Executor能够对并发性做出更强的承诺，它们能确保任务不会并发地执行。

对响应时间敏感的任务

比如GUI任务。如果将一个运行时间较长的任务提交到单线程的Executor中。或者将多个运行时间较长的任务提交到一个只包含少量线程的线程池中，那么会降低该 Executor的响应性。

使用ThreadLocal的任务

ThreadLocal使每个线程都可以拥有某个变量的私有版本，然而。只要条件允许Executor可以自由地重用这些线程。在标准的Executor中，当执行需求较低时将回收空间线程，而当需求增加时将添加新的线程，并且如果从任务中招聘了一个未检查异常，那么将用一个新的线程去替代这个发生问题的线程。只有当线程本地值的生命周期受限于任务的生命周期时，在线程池的线程中使用ThreadLocal才有意义，而在线程池的线程中不应该使用Threadlocal在任务之间传递值。

最后，只有当任务都是同类型并且相互独立时，线程池的性能才能达到最佳。如果将运行时间相差较大的任务放在同一个线程池中，那么除非线程池足够大，否则就会造成阻塞。。一般的基于网络的典型服务器应用程序中，如网页服务器，邮件服务器和文件服务器它们的请求都是同类型并且相互独立的。

记得讲你的执行策略写入文档，那么将来的维护人员就不会由于使用了错误的执行策略而破坏了安全性和活跃性。

线程饥饿死锁

如果是单线程的Executor。如果提交了两个任务，两个任务相互依赖对方的执行结果，那么就会造成死锁。

举个栗子：

import java.lang.ProcessBuilder.Redirect;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class ThreadDeadlock {
	ExecutorService exec = Executors.newSingleThreadExecutor();

	public static void main(String[] args) {
		try {
			ThreadDeadlock tdl = new ThreadDeadlock();

			System.out.println(tdl.new ReaderPageTask().call());
		} catch (Exception e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}

	public class ReaderPageTask implements Callable<String> {

		@Override
		public String call() throws Exception {
			// TODO Auto-generated method stub
			Future<String> header, footer;
			header = exec.submit(new LoadFileTask("header.html"));
			footer = exec.submit(new LoadFileTask("footer.html"));
			String page = "bodyyyyyyyyyyyyyyy";
			//将发生死锁，由于任务在等待子任务的结果
			return header.get() + page + footer.get();
		}
	}

	public class LoadFileTask implements Callable<String> {

		public LoadFileTask(String filepath) {
			super();
			// TODO Auto-generated constructor stub
		}

		@Override
		public String call() throws Exception {
			// TODO Auto-generated method stub
			return "sdf";
		}
	}
}

上面这个栗子是可以运算出结果的。可是相对来说慢了很多.属于线程饥饿死锁。
死锁并不是一定要“死”，看一下死锁的定义。

死锁的规范定义：集合中的每一个进程都在等待只能由本集合中的其他进程才能引发的事件，那么该组进程是死锁的。

除了线程池大小的显式限制外，还有很多由于外部资源限制而导致的死锁，比如jdbc限制有10个连接，那么每个线程都需要一个连接，已经有十个线程在线程池内运行，那么接下来的线程虽然已经在线程池内了，可是因为无法取得与数据库的连接而阻塞。

运行时间较长的任务

如果任务阻塞时间过长，那么即使不出现死锁，线程池的响应性也会变得糟糕。Java早就准备好了解决问题的方法。大多数可阻塞的方法中java的库内都有限时版本和不限时版本，比如Thread.join.Blockingqueue.put.CountDownLatch.await以及Select.select等。如果等待超时，可以把任务标识为失败，然后中止任务或者将任务重新放回队列，甚至可以加上计数器。如果几次失败仍如此那么再中止它。如果线程池内总是充满了被阻塞的任务，那么也可能说明是线程池的规模过小。

下面举个栗子，我也是弄了半天才明白Thread.join（timeout）的意思

public class ThreadDeadlock {
	public Boolean flag = false;

	public static void main(String[] args) {
		testThread tt = new ThreadDeadlock().new testThread();
		testThread1 tt1 = new ThreadDeadlock().new testThread1();
		tt1.start();

		try {
			tt1.join(200);
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		tt.start();
	
	}

	class testThread extends Thread {

		@Override
		public void run() {
			int result = 0;
			// TODO Auto-generated method stub
			while (true)
				System.out.println(result);

		}

	}

	class testThread1 extends Thread {
		@Override
		public void run() {
			int result = 10;
			while (true)
				System.out.println(result);
		}

	}

}

结果是。先是输出了200毫秒的10.然后开始输出0.也就是说join的超时机制是先执行Join的那个线程的任务，让它优先完成。但是如果设置了超时之后，如果在这个时间段内它仍不能完成任务，则放弃阻塞。并发地执行接下来的任务