核心是可以分別獨立執行程式指令的計算單元。
執行緒是作業系統能夠進行運算排程的最小單位。

有一個原則是：活躍執行緒數為 CPU(核)數時最佳。過少的活躍執行緒導致 CPU 無法被充分利用，過多的活躍執行緒導致過大的執行緒上下文切換開銷。

執行緒應該是活躍的，處於 IO 的執行緒，休眠的執行緒等均不消耗 CPU。

在Java併發程式設計方面，計算密集型與IO密集型是兩個非常典型的例子，這次大象就來講講自己在這方面的內容，本篇比較基礎，只適合剛入門的童鞋，請各種牛人不喜勿噴。

    計算密集型
    計算密集型，顧名思義就是應用需要非常多的CPU計算資源，在多核CPU時代，我們要讓每一個CPU核心都參與計算，將CPU的效能充分利用起來，這樣才算是沒有浪費伺服器配置，如果在非常好的伺服器配置上還執行著單執行緒程式那將是多麼重大的浪費。對於計算密集型的應用，完全是靠CPU的核數來工作，所以為了讓它的優勢完全發揮出來，避免過多的執行緒上下文切換，比較理想方案是：
    執行緒數 = CPU核數+1
    也可以設定成CPU核數*2，這還是要看JDK的使用版本，以及CPU配置(伺服器的CPU有超執行緒)。對於JDK1.8來說，裡面增加了一個平行計算，計算密集型的較理想執行緒數 = CPU核心執行緒數*2

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))

根據任務所需要的cpu和io資源的量可以分為

• CPU密集型任務:  主要是執行計算任務，響應時間很快，cpu一直在執行，這種任務cpu的利用率很高
• IO密集型任務：主要是進行IO操作，執行IO操作的時間較長，這是cpu出於空閒狀態，導致cpu的利用率不高

為了合理最大限度的使用系統資源同時也要保證的程式的高效能，可以給CPU密集型任務和IO密集型任務配置一些執行緒數。

CPU密集型：執行緒個數為CPU核數。這幾個執行緒可以並行執行，不存線上程切換到開銷，提高了cpu的利用率的同時也減少了切換執行緒導致的效能損耗

IO密集型：執行緒個數為CPU核數的兩倍。到其中的執行緒在IO操作的時候，其他執行緒可以繼續用cpu，提高了cpu的利用率 。

有一個原則是：活躍執行緒數為 CPU(核)數時最佳。過少的活躍執行緒導致 CPU 無法被充分利用，過多的活躍執行緒導致過大的執行緒上下文切換開銷。

常見的服務執行緒模型

1、IO執行緒與工作現場通過任務佇列解耦 

   X:執行計算，佔用CPU時間

  Y：執行IO等待不佔用CPU時間 

  工作執行緒池的個數：N*(1+y/x)

2、純非同步

併發使用者數：是指現實系統中操作業務的使用者，在效能測試工具中，一般稱為虛擬使用者數(Virutal User)。

併發使用者數和註冊使用者數、線上使用者數的概念不同，

1、併發使用者數一定會對伺服器產生壓力的，

2、而線上使用者數只是 ”掛” 在系統上，對伺服器不產生壓力，

3、註冊使用者數一般指的是資料庫中存在的使用者數。

TPS：Transaction Per Second, 每秒事務數, 是衡量系統性能的一個非常重要的指標。

TPS就是每秒事務數，但是事務是基於虛擬使用者數的，假如1個虛擬使用者在1秒內完成1筆事務，那麼TPS明顯就是1；如果 某筆業務響應時間是1ms,那麼1個使用者在1秒內能完成1000筆事務，TPS就是1000了；如果某筆業務響應時間是1s,那麼1個使用者在1秒內只能完 成1筆事務，要想達到1000TPS，至少需要1000個使用者；因此可以說1個使用者可以產生1000TPS，1000個使用者也可以產生1000TPS，無非是看響應時間快慢。

也就是說，在評定伺服器的效能時，應該結合TPS和併發使用者數，以TPS為主，併發使用者數為輔來衡量系統的效能。如果必須要用併發使用者數來衡量的 話，需要一個前提，那就是交易在多長時間內完成，因為在系統負載不高的情況下，將思考時間(思考時間的值等於交易響應時間)加到指令碼中，併發使用者數基本可 以增加一倍，因此用併發使用者數來衡量系統的效能沒太大的意義。

在效能測試時並不需要用上萬的使用者併發去進行測試，如果只需要保證系統處理業務時間足夠快，幾百個使用者甚至幾十個使用者就可 以達到目的。據他了解，很多專家做過的效能測試專案基本都沒有超過5000使用者併發。因此對於大型系統、業務量非常高、硬體配置足夠多的情況下，5000 使用者併發就足夠了；對於中小型系統，1000使用者併發就足夠了。

系統吞吐量幾個重要引數：TPS、併發數、響應時間

     TPS：每秒鐘事務數量

     併發數： 系統同時處理的事務數

     響應時間：一般取平均響應時間

                TPS=併發使用者數 / (響應時間+Thinktime)

併發使用者如何計算

一、經典公式1：

   一般來說，利用以下經驗公式進行估算系統的平均併發使用者數和峰值資料

  1）平均併發使用者數為 C = nL/T

  2）併發使用者數峰值 C‘ = C + 3*根號C

    C是平均併發使用者數，n是login session的數量，L是login session的平均長度，T是值考察的時間長度

    C’是併發使用者數峰值

  舉例1，假設系統A，該系統有3000個使用者，平均每天大概有400個使用者要訪問該系統（可以從系統日誌從獲得），對於一個典型使用者來說，一天之內使用者從登陸到退出的平均時間為4小時，而在一天之內，使用者只有在8小時之內會使用該系統。

  那麼，

  平均併發使用者數為：C = 400*4/8 = 200

  併發使用者數峰值為：C‘ = 200 + 3*根號200 = 243

  舉例2， 某公司為其170000名員工設計了一個薪酬系統，員工可進入該系統查詢自己的薪酬資訊，但並不是每個人都會用這個系統，假設只有50%的人會定期用改系統，這些人裡面有70%是在每個月的最後一週使用一次該系統，且平均使用系統時間為5分鐘。

  則一個月最後一週的平均併發使用者數為（朝九晚五）：

  n = 170000*0.5*0.7/5 = 11900

  C= 11900*5/60/8 = 124

  吞吐量計算為：F = Vu * R / T 單位為個/s

    F為事務吞吐量，Vu為虛擬使用者數個數，R為每個虛擬使用者發出的請求數，T為處理這些請求所花費的時間

二、通用公式2：

  對絕大多數場景，我們用（使用者總量/統計時間）*影響因子（一般為3）來進行估算併發量。

  比如，以乘坐地鐵為例子，每天乘坐人數為5萬人次，每天早高峰是7到9點，晚高峰是6到7點，根據8/2原則，80%的乘客會在高峰期間乘坐地鐵，則每秒到達地鐵檢票口的人數為50000*80%/（3*60*60）=3.7，約4人/S，考慮到安檢，入口關閉等因素，實際堆積在檢票口的人數肯定比這個要大，假定每個人需要3秒才能進站，那實際併發應為4人/s*3s=12，當然影響因子可以根據實際情況增大！

三、根據PV計算公式：

  比如一個網站，每天的PV大概1000w，根據2/8原則，我們可以認為這1000w pv的80%是在一天的9個小時內完成的（人的精力有限），那麼TPS為：

  1000w*80%/(9*3600)=246.92個/s,取經驗因子3，則併發量應為：

  246.92*3=740

四、根據TPS估計：

   公式為 C = (Think time + 1)*TPS

五、根據系統使用者數計算：

   併發使用者數 = 系統最大線上使用者數的8%到12%