【Java并发】JAVA并发编程实战-读书笔记9

并发并用程序是围绕任务进行管理的。所以设计时要指明一个清晰的任务边界。理想情况下，任务时独立的。

在正常负载下，服务器应用程序应该兼具良好的吞吐量和快速的响应性。应用程序在负荷过载时平缓地劣化，而不能负载一高就简单地以失败告终。所以要清晰任务边界并配合一个明确的任务执行策略。

大多数服务器选择了下面这个自然的任务边界：单独的用户请求。

class SingleThreadWebServer{  public static void main(String[] args)throws IOException{    ServerSocket socket=new ServerSocket(80);    while(true){      Socket connection=socket.accept();      handleRequest(connection);    }  }}

上面的例子是顺序化的WebServer，理论上是正确的，一次只能处理一个请求，因此在生产上的执行效率很低。（在某些情况下，顺序化处理在简单性或安全性上具有优势，比如大多数的GUI框架使用单一线程顺序的处理任务。）

class ThreadPerTaskServer{  public static void main(String[] args)throws IOException{    ServerSocket socket=new ServerSocket(80);    while(true){      final Socket connection=socket.accept();      Runnable task=new Runnable(){        public void run(){          handleRequest(connection);        }      }      new Thread(task).start();    }  }}

上面的例子有了良好的改进，但是存在一些实际的缺陷，尤其在需要创建大量的线程时会更加突出。

1，线程生命周期的开销。包括线程的创建和关闭。

2，资源消耗量。活动线程会消耗系统资源，尤其是内存，如果可运行的线程数多于可用的处理器数，线程将会空闲。会给垃圾回收器带来压力，而且大量线程竞争CPU资源时也会产生其他的性能开销。如果你有足够的线程保持所有的CPU忙碌，那么创建再多的线程百害而无一利。

3，稳定性。应该限制可以创建线程的数目，限制的数目依不同的平台而定，也收到JVM的启动参数、Thread的构造函数中请求的栈大小等因素的影响，以及底层OS线程的限制。如果打破这些限制，可能会收到一个OutOfMemorryError。企图从这种错误中恢复是非常危险的，简单的方法是避免超出这些限制。应该设置一个范围来限制你的应用程序可以创建的线程数，然后彻底地测试你的应用程序，确保即使到达了这个范围的极限，程序也不至于耗尽所有的资源。

在32位的机器上，主要的限制因素是线程栈的地址空间。每个线程都维护着两个执行栈，一个用于java代码，一个用于原生代码。典型的jvm默认会产生一个组合的栈，大小在半兆字节左右。如果你为每个线程分配了大小为232字节的栈，那么你的线程数量将被限制在几千到几万间不等。其他方面，比如OS的限制，可能产生更加严格的约束。

public static void main(String[] args) {  for (int i = 0; i < 10000; i++) {    new Thread(new Runnable() {      @Override      public void run() {        try {          TimeUnit.MINUTES.sleep(5);        } catch (InterruptedException e) {          e.printStackTrace();        }      }    }).start();    System.out.println(i);  }}

下面是我的测试结果，数目在2705前后。

2705

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(Thread.java:640)

at Test11.main(Test11.java:23)

线程池为线程管理提供了帮助。作为Executor框架的一部分，juc提供了一个灵活的线程池实现。

在Java类库中，任务执行的首要抽象不是Thread，而是Executor。

public interface Executor{

  void execute(Runable command);

}

使用线程池的WebServer

class TaskExecutionWebServer{  private static final int NTHREADS=100;  private static final Executor exec    =Executors.newFixedThreadPool(NTHREADS);  public static void main(Stirng[] args)throws IOException{    ServerSocket socket=new ServerSocket(80);    while(true){      final Socket connection=socket.accept();      Runnable task=new Runnable(){        public void run(){          handleRequest(connection);        }      };      exec.execute(task);    }  }}

为每个任务启动一个新线程的Executor

public class ThreadPerTaskExecutor implements Executor{  public void execute(Runnable r){    new Thread(r).start();  }}

将任务的提交与任务的执行体进行解耦，价值在于可以简单地为一个类给定的任务制定执行策略，并且保证后续的修改不会太困难。一个执行策略指明了如下几个因素：

1，任务在什么线程中执行。

2，任务以什么顺序执行（FIFO、LIFO、优先级）

3，可以有多少个任务并发执行。

4，可以有多少个任务进入等待执行队列。

5，如果系统过载，需要放弃一个任务，应该挑选哪一个任务。另外如何通知应用程序知道这一切。

6，在一个任务的执行前与结束后，应该做什么处理。

为了解决执行服务的生命周期问题，ExecutorService接口扩展了Executor，添加了一些用于生命周期管理的方法。

public interface ExecutorService extends Executor{  void shutdown();//平缓的关闭过程  List<Runnable> shutdownNow();//强制关闭的过程  boolean isShutdown();  boolean isTerminated();  boolean awaitTermination(long timeout,TimeUnit unit)throws InterruptException}

其暗示了生命周期有3中状态：运行、关闭和终止。

class LifecycleWebServer{  private final ExecutorService exec=...;  public void start()throws IOException{    ServerSocket socket=new ServerSocket(80);    while(!exec.isShutdown()){      try{        final Socket conn=socket.accept();        exec.execute(          new Runnable(){            public void run(){              handleRequest(conn);            }          }        );      }catch(RejectedExecutionException e){        if(!exec.isShutdown()){          log(“task submission rejected”,e);        }      }    }  }  public void stop(){    exec.shutdown();  }  void handleRequest(Socket connection){    Request req=readRequest(connection);    if(isShutdownRequest(req)){      stop();    }else{      dispatchRequest(req);    }  }}

上面的例子是支持关闭的Web Server。

Timer工具管理任务的延迟执行，但是存在一些缺陷，你应该考虑使用ScheduledThreadPoolExecutor作为替代品。因为Timer用的是绝对时间而后者用的是相对时间。

Timer只创建唯一的线程来执行所有的Timer任务，如果一个Timer任务很耗时，会导致其他TimerTask的时效准确性出现问题。

Timer的另一个问题在于如果抛出未检查的异常，Timer将会产生无法预料的行为。Timer线程并不捕获异常，所以TimerTask抛出异常会终止timer线程。此时Timer也不会再回复线程的执行，会错误的认为整个Timer都被取消了，已经被安排但尚未执行的TimerTask永远不会再执行了，新的认为也不能被调度了，这个问题叫做线程泄漏。

public class OutOfTime{  public static void main(String[] args)throws Exception{    Timer timer=new Timer();    timer.schedule(new ThrowTask(),1);    TimeUnit.SECONDS.sleep(1);    timer.schedule(new ThrowTask(),1);    TimeUnit.SECONDS.sleep(5);  }  static class ThrowTask extends TimerTask{    public void run(){      throw new RuntimeException();    }  }}

上面的例子中，程序1秒后终止了，还伴随着一个异常。

Exception in thread "Timer-0" java.lang.RuntimeException

at Test12$ThrowTask.run(Test12.java:16)

at java.util.TimerThread.mainLoop(Timer.java:512)

at java.util.TimerThread.run(Timer.java:462)

Exception in thread "main" java.lang.IllegalStateException: Timer already cancelled.

at java.util.Timer.sched(Timer.java:354)

at java.util.Timer.schedule(Timer.java:170)

at Test12.main(Test12.java:10)

顺序地渲染页面元素

public class SingleThreadRenderer{  void renderPage(CharSequence source){    renderText(source);    List<ImageData> imageData=new ArrayList<ImageData>();    for(ImageInfo imageInfo:scanForImageInfo(source)){      imageData.add(imageInfo.downloadImage());    }    for(ImageData data:imageData){      renderImage(data);    }  }}

Future描述了任务的生命周期，任务的状态决定了get方法的行为。如果完成会立即返回或者抛出Exception，如果没有完成会阻塞直到完成。抛出的异常会被封装为ExecutionException然后重新抛出，如果认为被取消会抛出CancellationException。当抛出异常时可以使用getCause重新获得被封装的原始异常。

创建Future的方法有很多，ExecutorService中所有的submit都会返回一个Future，因此可以将一个Runnable或一个Callable提交给executor后得到一个Future。也可以为给定的Runnable或Callable实例化一个FutureTask。

为了加快渲染，我们将渲染过程分为两个部分，一个是渲染文本，一个是下载图像。

public class FutureRenderer{  private final ExecutorService executor=...;  void renderPage(CharSequence source){    final List<ImageInfo> imageInfos=scanForImageInfo(source);    Callable<List<ImageData>> task = new Callable<List<ImageData>>(){      public List<ImageData> call(){        List<ImageData> result=new ArrayList<ImageData>();        for(ImageInfo imageInfo:imageInfos){          result.add(imageInfo.downloadImage());        }        return result;      }    };    Future<List<ImageData>> future=executor.submint(task);    renderText(source);    try{      List<ImageData> imageData=future.get();      for(ImageData data:imageData){        renderImage(data);      }    }catch(InterruptedException e){      Thread.currentThread().interrupt();      future.cancel(true);    }catch(ExecutionException e){      throw launderThrowable(e.getCause());    }  }}

上面的例子中，如果渲染文本的速度远远大于下载图像的速度，那么最终的性能与顺序执行版本的性能不会有很大的不同，反倒是代码的复杂度大大的提高了。

大量相互独立且同类的任务进行并发处理，会将程序的任务量分派到不同的任务中，这样才能真正获得性能的提升。