《java多线程的几种风格》.pptVIP

3.Executor Framework 3.Executor Framework-合理的配置线程池 任务的性质：CPU密集型任务，IO密集型任务和混合型任务。 CPU密集型任务配置尽可能小的线程，如配置Ncpu+1个线程的线程池 IO密集型任务则，则配置尽可能多的线程，如2*Ncpu 混合型的任务，如果可以拆分，则将其拆分成一个CPU密集型任务和一个IO密集型任务，只要这两个任务执行的时间相差不是太大，那么分解后执行的吞吐率要高于串行执行的吞吐率，如果这两个任务执行时间相差太大，则没必要进行分解。 任务的优先级：高，中和低 优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理，如果一直有优先级高的任务提交到队列里，那么优先级低的任务可能永远不能执行。 任务的执行时间：长，中和短 执行时间不同的任务可以交给不同规模的线程池来处理，或者也可以使用优先级队列，让执行时间短的任务先执行。 任务的依赖性：是否依赖其他系统资源，如数据库连接。 依赖数据库连接池的任务，因为线程提交SQL后需要等待数据库返回结果，如果等待的时间越长CPU空闲时间就越长，那么线程数应该设置越大，这样才能更好的利用CPU。 4.Fork join 线程池技术适用粗粒度的任务，适用于互相独立的任务。 当跨入多内核时代时，需要更细粒度的并行性，否则处理器可能处于空闲 fork/join基于divide-and-conquer算法，适合将一个大任务划分为多个小任务，让多个CPU执行，然后再合并结果 4.ForkJoin与MapReduce的区别 MapReduce是把大数据集切分成小数据集，并行分布计算后再合并。 ForkJoin是将一个问题递归分解成子问题，再将子问题并行运算后合并结果。 共同点：都是用于执行并行任务的。基本思想都是把问题分解为一个个子问题分别计算，再合并结果。 区别： 1）环境差异：分布式?vs?单机多核。ForkJoin设计初衷针对单机多核（处理器数量很多的情况）。MapReduce一开始就明确是针对很多机器组成的集群环境的。也就是说一个是想充分利用多处理器，而另一个是想充分利用很多机器做分布式计算。这是两种不同的的应用场景，有很多差异，因此在细的编程模式方面有很多不同。 2）编程差异：MapReduce一般是做较大粒度的切分，一开始就先切分好任务然后再执行，并且彼此间在最后合并之前不需要通信。这样可伸缩性更好，适合解决巨大的问题，但限制也更多。ForkJoin可以是较小粒度的切分，任务自己知道该如何切分自己，递归地切分到一组合适大小的子任务来执行，因为是一个JVM内，所以彼此间通信是很容易的，更像是传统编程方式。 4.ForkJoin-Work Stealing Work Stealing 4.ForkJoin-实例代码 4.ForkJoin-框架结构 ForkJoinPool本身实现了ExecutorService接口， 负责调度执行ForkJoinTask 。 ForkJoinTask是提交给ForkJoinPool?执行的任务，本身也实现了Future?接口。 ForkJoinTask有两个子类RecursiveAction和RecursiveTask。 RecursiveAction?没有返回值（只需fork）； RecursiveTask有返回值（需要合并）。类似于Runnable和?Callable一样 而我们要做的是实现自己要完成的任务，只需要继承其一，并覆盖抽象方法compute()。在这个方法中实现自己的任务，递归分解任务 4.影响ForkJoin加速效果的因素 理想效果是核越多加速效果越好。但是并行不一定更快，参数不对还可能更慢： 1）??并发数，即线程数。一般是可用的cpu数，默认就是这个，一般表现很好。 2）??任务切分的粒度。 如果切分粒度等于总任务量，一个任务执行，就相当于单线程顺序执行。 每个任务执行的计算量，太大的话加速效果有限，不能发挥到最好。 相反，太小的话，消耗在任务管理的成本占了主要部分，导致还不如顺序执行的快。? 需要适当平衡二者。因为还和任务本身的特定有关，所以可以做个基准测试比较一下。 而总的执行时间还与任务的规模有关。 感觉多核cpu只适用于解决计算密集型应用，因为实际问题可能IO等其他方面的瓶颈，多核也还是无法充分利用的 4.Actor模型 许多开发者在创建和维护多线程应用程序时经历过各种各样的问题，他们希望能在一个更高层次的抽象上进行工作，以避免直接和线程与锁打交道 Actor模型是一种基于协程的消息传递模型，在并行计算和并发的消息传递中有很好的性能表现。一般的actor模块