隨筆-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參數,并發效果更好一些?,F在JDK1.8都出來這么久了,你的JDK是不是應該升級下了呢?
    本文為菠蘿大象原創,如要轉載請注明出處。http://www.268147.live/bolo
posted on 2015-01-20 15:08 菠蘿大象 閱讀(18420) 評論(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
對的,跟你想法一致  回復  更多評論
  

只有注冊用戶登錄后才能發表評論。


網站導航:
 
湖北快3号码表 湖北l1选5开奖结果 贵州十一选五一定牛推荐 推荐一只股票 证券交易市场的类型有哪些 上海11选5遗漏 体育彩票大乐透开奖结果 甘肃十一选五元月三号推荐数推 吉林十一选五开结果 湖南快乐十分总动员 极速时时彩是不是有鬼