随笔-67  评论-522  文章-0  trackbacks-0
    Java并发编程方面,计算密集型与IO密集型是两个非常典型的例子,这次大象就来讲讲自己在这方面的内容,本篇比较基础,只适合刚入门的童鞋,请各种牛人不喜勿喷。
    计算密集型
    计算密集型,顾名思义就是应用需要非常多的CPU计算资源,在多核CPU时代,我们要让每一个CPU核心都参与计算,将CPU的性能充分利用起来,这样才算是没有浪费服务器配置,如果在非常好的服务器配置上还运行着单线程程序那将是多么重大的浪费。对于计算密集型的应用,完全是靠CPU的核数来工作,所以为了让它的优势完全发挥出来,避免过多的线程上下文切换,比较理想方案是:
    线程数 = CPU核数+1
    也可以设置成CPU核数*2,这还是要看JDK的使用版本,以及CPU配置(服务器的CPU有超线程)。对于JDK1.8来说,里面增加了一个并行计算,计算密集型的较理想线程数 = CPU内核线程数*2
计算文件夹大小算是一个比较典型的例子,代码很简单,我就不多解释了。
import java.io.File;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;

/**
 * 计算文件夹大小
 * 
@author 菠萝大象
 
*/
public class FileSizeCalc {

    static class SubDirsAndSize {
        public final long size;
        public final List<File> subDirs;

        public SubDirsAndSize(long size, List<File> subDirs) {
            this.size = size;
            this.subDirs = Collections.unmodifiableList(subDirs);
        }
    }
    
    private SubDirsAndSize getSubDirsAndSize(File file) {
        long total = 0;
        List<File> subDirs = new ArrayList<File>();
        if (file.isDirectory()) {
            File[] children = file.listFiles();
            if (children != null) {
                for (File child : children) {
                    if (child.isFile())
                        total += child.length();
                    else
                        subDirs.add(child);
                }
            }
        }
        return new SubDirsAndSize(total, subDirs);
    }
    
    private long getFileSize(File file) throws Exception{
        final int cpuCore = Runtime.getRuntime().availableProcessors();
        final int poolSize = cpuCore+1;
        ExecutorService service = Executors.newFixedThreadPool(poolSize);
        long total = 0;
        List<File> directories = new ArrayList<File>();
        directories.add(file);
        SubDirsAndSize subDirsAndSize = null;
        try{
            while(!directories.isEmpty()){
                List<Future<SubDirsAndSize>> partialResults= new ArrayList<Future<SubDirsAndSize>>();
                for(final File directory : directories){
                    partialResults.add(service.submit(new Callable<SubDirsAndSize>(){
                        @Override
                        public SubDirsAndSize call() throws Exception {
                            return getSubDirsAndSize(directory);
                        }
                    }));
                }
                directories.clear();
                for(Future<SubDirsAndSize> partialResultFuture : partialResults){
                    subDirsAndSize = partialResultFuture.get(100,TimeUnit.SECONDS);
                    total += subDirsAndSize.size;
                    directories.addAll(subDirsAndSize.subDirs);
                }
            }
            return total;
        } finally {
            service.shutdown();
        }
    }
    
    public static void main(String[] args) throws Exception {
        for(int i=0;i<10;i++){
            final long start = System.currentTimeMillis();
            long total = new FileSizeCalc().getFileSize(new File("e:/m2"));
            final long end = System.currentTimeMillis();
            System.out.format("文件夹大小: %dMB%n" , total/(1024*1024));
            System.out.format("所用时间: %.3fs%n" , (end - start)/1.0e3);
        }
    }
}

    执行10次后结果如下:
    
    在上面的例子中,线程池设置为CPU核心数+1个,这个运行结果是大象在工作电脑(CPUG630 内存:4G JDK1.7.0_51)上跑出来的。如果在这里把线程池加大,比如调到100,你会发现所用时间变多了,大象这里最多的消耗时间是0.297秒,与之前最少的一次0.218之间相差0.079秒,也即79毫秒。当然这多出来的时间在我们看来好像不算什么,只有零点零几秒,但是对于CPU来说可是相当长的,因为CPU里面是以纳秒为计算单位,1毫秒=1000000纳秒。所以加大线程池会增加CPU上下文的切换成本,有时程序的优化就是从这些微小的地方积累起来的。
    IO密集型
    对于IO密集型的应用,就很好理解了,我们现在做的开发大部分都是WEB应用,涉及到大量的网络传输,不仅如此,与数据库,与缓存间的交互也涉及到IO,一旦发生IO,线程就会处于等待状态,当IO结束,数据准备好后,线程才会继续执行。因此从这里可以发现,对于IO密集型的应用,我们可以多设置一些线程池中线程的数量,这样就能让在等待IO的这段时间内,线程可以去做其它事,提高并发处理效率。
    那么这个线程池的数据量是不是可以随便设置呢?当然不是的,请一定要记得,线程上下文切换是有代价的。目前总结了一套公式,对于IO密集型应用:
    线程数 = CPU核心数/(1-阻塞系数)
    这个阻塞系数一般为0.8~0.9之间,也可以取0.8或者0.9。套用公式,对于双核CPU来说,它比较理想的线程数就是20,当然这都不是绝对的,需要根据实际情况以及实际业务来调整。
    final int poolSize = (int)(cpuCore/(1-0.9))
    本篇大象简单谈了下并发类型,旨在抛砖引玉,让初学并发编程的朋友能够有一些了解,说的不对的地方,还请各位指出来。
    唠叨完上面这些,再唠叨下JDK的版本,每次Java的版本升级,就意味着虚拟机以及GC的性能都有一定程度的提升,所以JDK1.7JDK1.6在并发处理速度上要更快一些,注意对多线程程度请加上-server参数,并发效果更好一些。现在JDK1.8都出来这么久了,你的JDK是不是应该升级下了呢?
    本文为菠萝大象原创,如要转载请注明出处。http://www.blogjava.net/bolo
posted on 2015-01-20 15:08 菠萝大象 阅读(19445) 评论(6)  编辑  收藏 所属分类: Concurrency

评论:
# re: 浅谈Java两种并发类型——计算密集型与IO密集型[未登录] 2015-01-21 16:26 | Max
阻塞系数,这个概念是怎么来的。文章如果把这个交代清楚就完整了。  回复  更多评论
  
# re: 浅谈Java两种并发类型——计算密集型与IO密集型 2015-01-22 08:49 | 菠萝大象
@Max
这个阻塞系数我还真解释不了,我也是看《Java虚拟机并发编程》这本书里学习到的,估计这是一个经验值。如果你有更好的答案欢迎指点。  回复  更多评论
  
# re: 浅谈Java两种并发类型——计算密集型与IO密集型 2015-01-22 17:58 | 京山游侠
记住了,以后用得到。  回复  更多评论
  
# re: 浅谈Java两种并发类型——计算密集型与IO密集型 2015-01-27 17:07 | changedi
赞,但是我觉得一定要强调的是线程池根本上解决不了io密集的问题,io密集带来的等待是需要异步非阻塞来解决的,也就是在io时要让线程让出CPU,不要空等,避免同步嘛~~  回复  更多评论
  
# re: 浅谈Java两种并发类型——计算密集型与IO密集型 2015-01-28 08:38 | 菠萝大象
@changedi
Netty就是一个对IO密集型问题的一个很好的解决方案,它的线程模型说到底还是采用的线程池,只是它用到了一些技巧,在很大的程度上提高了并发性能。不管怎么说,还要是看系统内核,JDK1.7的AIO不就是因为内核没有发挥出来么?Netty也有AIO的方式,但性能上与NIO还是差不多。  回复  更多评论
  
# re: 浅谈Java两种并发类型——计算密集型与IO密集型 2016-01-29 11:29 | he037
@changedi
对的,跟你想法一致  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: