在我們?nèi)粘I(yè)務(wù)開(kāi)發(fā)過(guò)程中，或多或少都會(huì)用到并發(fā)的功能。那么在用到并發(fā)功能的過(guò)程中，就肯定會(huì)碰到下面這個(gè)問(wèn)題

并發(fā)線程池到底設(shè)置多大呢？

通常有點(diǎn)年紀(jì)的程序員或許都聽(tīng)說(shuō)這樣一個(gè)說(shuō)法 （其中 N 代表 CPU 的個(gè)數(shù)）

1. CPU 密集型應(yīng)用，線程池大小設(shè)置為 N + 1
2. IO 密集型應(yīng)用，線程池大小設(shè)置為 2N

這個(gè)說(shuō)法到底是不是正確的呢？

其實(shí)這是極不正確的。那為什么呢？

首先我們從反面來(lái)看，假設(shè)這個(gè)說(shuō)法是成立的，那我們?cè)谝慌_(tái)服務(wù)器上部署多少個(gè)服務(wù)都無(wú)所謂了。因?yàn)榫€程池的大小只能服務(wù)器的核數(shù)有關(guān)，所以這個(gè)說(shuō)法是不正確的。那具體應(yīng)該怎么設(shè)置大小呢？

假設(shè)這個(gè)應(yīng)用是兩者混合型的，其中任務(wù)即有 CPU 密集，也有 IO 密集型的，那么我們改怎么設(shè)置呢？是不是只能拋硬盤來(lái)決定呢？

那么我們到底該怎么設(shè)置線程池大小呢？有沒(méi)有一些具體實(shí)踐方法來(lái)指導(dǎo)大家落地呢？讓我們來(lái)深入地了解一下。

Little's Law（利特爾法則）

一個(gè)系統(tǒng)請(qǐng)求數(shù)等于請(qǐng)求的到達(dá)率與平均每個(gè)單獨(dú)請(qǐng)求花費(fèi)的時(shí)間之乘積

假設(shè)服務(wù)器單核的，對(duì)應(yīng)業(yè)務(wù)需要保證請(qǐng)求量（QPS）：10 ，真正處理一個(gè)請(qǐng)求需要 1 秒，那么服務(wù)器每個(gè)時(shí)刻都有 10 個(gè)請(qǐng)求在處理，即需要 10 個(gè)線程

同樣，我們可以使用利特爾法則（Little's law）來(lái)判定線程池大小。我們只需計(jì)算請(qǐng)求到達(dá)率和請(qǐng)求處理的平均時(shí)間。然后，將上述值放到利特爾法則（Little's law）就可以算出系統(tǒng)平均請(qǐng)求數(shù)。估算公式如下

*線程池大小 = （（線程 IO time + 線程 CPU time ）/線程 CPU time ） CPU數(shù)目**

具體實(shí)踐

通過(guò)公式，我們了解到需要 3 個(gè)具體數(shù)值

1. 一個(gè)請(qǐng)求所消耗的時(shí)間 (線程 IO time + 線程 CPU time)
2. 該請(qǐng)求計(jì)算時(shí)間 （線程 CPU time）
3. CPU 數(shù)目

請(qǐng)求消耗時(shí)間

Web 服務(wù)容器中，可以通過(guò) Filter 來(lái)攔截獲取該請(qǐng)求前后消耗的時(shí)間

public class MoniterFilter implements Filter { 
  private static final Logger logger = LoggerFactory.getLogger(MoniterFilter.class); 
  @Override 
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, 
      ServletException { 
    long start = System.currentTimeMillis(); 
    HttpServletRequest httpRequest = (HttpServletRequest) request; 
    HttpServletResponse httpResponse = (HttpServletResponse) response; 
    String uri = httpRequest.getRequestURI(); 
    String params = getQueryString(httpRequest); 
    try { 
      chain.doFilter(httpRequest, httpResponse); 
    } finally { 
      long cost = System.currentTimeMillis() - start; 
      logger.info("access url [{}{}], cost time [{}] ms )", uri, params, cost); 
    } 
  private String getQueryString(HttpServletRequest req) { 
    StringBuilder buffer = new StringBuilder("?"); 
    Enumeration<String> emParams = req.getParameterNames(); 
    try { 
      while (emParams.hasMoreElements()) { 
        String sParam = emParams.nextElement(); 
        String sValues = req.getParameter(sParam); 
        buffer.append(sParam).append("=").append(sValues).append("&"); 
      } 
      return buffer.substring(0, buffer.length() - 1); 
    } catch (Exception e) { 
      logger.error("get post arguments error", buffer.toString()); 
    } 
    return ""; 
  } 
} 

CPU 計(jì)算時(shí)間

CPU 計(jì)算時(shí)間 = 請(qǐng)求總耗時(shí) - CPU IO time

假設(shè)該請(qǐng)求有一個(gè)查詢 DB 的操作，只要知道這個(gè)查詢 DB 的耗時(shí)（CPU IO time），計(jì)算的時(shí)間不就出來(lái)了嘛，我們看一下怎么才能簡(jiǎn)潔，明了的記錄 DB 查詢的耗時(shí)。

通過(guò)（JDK 動(dòng)態(tài)代理/ CGLIB）的方式添加 AOP 切面，來(lái)獲取線程 IO 耗時(shí)。代碼如下，請(qǐng)參考：

public class DaoInterceptor implements MethodInterceptor { 
  private static final Logger logger = LoggerFactory.getLogger(DaoInterceptor.class); 
  @Override 
  public Object invoke(MethodInvocation invocation) throws Throwable { 
    StopWatch watch = new StopWatch(); 
    watch.start(); 
    Object result = null; 
    Throwable t = null; 
    try { 
      result = invocation.proceed(); 
    } catch (Throwable e) { 
      t = e == null ? null : e.getCause(); 
      throw e; 
    } finally { 
      watch.stop(); 
      logger.info("({}ms)", watch.getTotalTimeMillis()); 
    } 
    return result; 
  } 
} 

CPU 數(shù)目

邏輯 CPU 個(gè)數(shù) ，設(shè)置線程池大小的時(shí)候參考的 CPU 個(gè)數(shù)

cat /proc/cpuinfo| grep "processor"| wc -l 

總結(jié)

合適的配置線程池大小其實(shí)很不容易，但是通過(guò)上述的公式和具體代碼，我們就能快速、落地的算出這個(gè)線程池該設(shè)置的多大。

不過(guò)最后的最后，我們還是需要通過(guò)壓力測(cè)試來(lái)進(jìn)行微調(diào)，只有經(jīng)過(guò)壓測(cè)測(cè)試的檢驗(yàn)，我們才能最終保證的配置大小是準(zhǔn)確的。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論