前言
前段時間無意間從一個朋友那得到了一個微信公衆號——“開發者頭條”
因爲並不是我的本意想要的，但是因爲我實在夠懶也沒有取消關注就這麼一直放着了。
但是現在看了看，還是挺好的，所以在這推薦給大家這個公衆號
然後今天正巧看到了一篇文章—— 一道面試題：說說進程和線程的區別
我就試着自己總結一下這個知識點
正文
對於進程與線程，網絡上也是百家爭鳴，各有各的觀點。
我也只是將我比較能理解和接受的加以調整分享給大家
還沒有比較深入的自己的理解。
百科釋義
進程（Process）是計算機中的程序關於數據集合上的一次運動活動，是系統進行資源分配和調度的基本單位，是操作系統結構的基礎。
在早期面向進程設計的計算機接口中，進程是程序的基本執行實體；在當代面向線程設計的計算機結構中，進程是線程的容器。
程序是指令、數據及其組織形式的描述，進程是程序的實體。
線程（Thread）是“進程”中某個單一順序的控制流。也稱爲輕量級進程。
線程是操作系統能夠進行運算調度的最小單位。它被包含在進程之中，是進程的實際運行單位。
一條線程指的是進程中一個單一順序的控制流，一個進程中可以併發多個線程，每個線程並行執行不同的任務。
知乎討論
首先聽到這個名詞，下意識的就會去想在一個程序中如何體現、如何運用的。
而且又重新溫習了一遍那個多線程的小demo。
先說一句總的概括：進程和線程都是一個時間段的描述，是對CPU工作時間的描述
下面細說背景：
CPU+RAM+各種資源（比如顯卡、光驅、鍵盤、GPS等外設）構成了我們的電腦，但是電腦的運行，實際就是CPU和相關寄存器以及RAM之間的事情
一個最最基礎的事實：CPU太快，太快，太快了，寄存器僅僅能夠追的上他的腳步，RAM和別的掛在各總線上的設備完全是望其項背。那當多個任務要執行的時候怎麼辦呢？輪流着來？或者誰優先級高誰來？不管怎麼樣的策略，一句話就是在CPU看來都是輪流着來。
一個必須知道的事實：執行一段程序代碼，實現一個功能的過程介紹，當得到CPU的時候，相關的資源必須也已經到位，就是顯卡啊，GPS啊什麼的必須就位，然後CPU開始執行。這裏除了CPU以外所有的 就構成了這個程序的執行環境，也就是我們所定義的程序上下文。當這個程序執行完了，或者分配給他的CPU執行時間用完了，那他就要被切換出去，等待下一次CPU的臨幸。在被切換出去的最後一步工作就是保存程序上下文，因爲這個是下次他被CPU臨幸的運行環境，必須保存。
串聯起來的事實：前面講過在CPU看起來所有的任務都是一個一個輪流執行的，具體的輪流方法就是：先加載程序A的上下文，然後在開始執行A，保存程序A的上下文，調入下一個要執行的程序B的程序上下文，然後開始執行B，保存程序B的上下文.....
======重要的東西出現了======
進程和線程就是這樣的背景出來的，兩個名詞不過是對應的CPU時間段的描述，名詞就是這樣的功能。
進程就是包括上下文切換的程序執行時間總和 = CPU加載上下文+CPU執行+CPU保存上下文
線程是什麼呢？
進程的粒度太大了，每次都要有上下的調入，保存，調出。如果我們把進程比喻爲一個運行在電腦上的軟件，那麼一個軟件的執行不可能是一條邏輯執行的，必定有多個分支和多個程序段，就好比要實現程序A，實際分成a,b,c等多個塊組合而成。那麼這裏具體的執行就可能變成：
程序A得到CPU -> CPU加載上下文，開始執行程序A的a小段，然後執行A的b小段，然後再執行程序A的c小段，最後CPU保存A的上下文。
這裏a，b，c的執行共享了A的上下文，CPU在執行的時候沒有進行上下文切換的。這裏的a，b，c就是線程，也就是說線程是共享進程的上下文環境的更爲細小的CPU時間段。
到此全文結束，在一個總結：
進程和線程都是一個時間段的描述，是CPU工作時間段的描述，不過是粒度大小不同
溫故課本
然後再次翻看了《操作系統》的自考書，整本書對於線程沒有過多的描述。
但是其中的描述還是挺好的。
線程是進程中可以獨立執行的子任務。
一個進程中可以有一個或多個線程。每個線程都有一個唯一的標識符
舉例：
假設一個用戶要求執行一個數據庫應用程序 ，從數據庫產生一份工資單報表，並把報表傳送到一個文件中，在等待生成工資單報表時又向系統提出一個數據庫查詢請求。
對比，操作系統首先爲該用戶創建一個數據庫進程，接着按用戶要求生成工資單報表。在生成該報表的過程中，又根據用戶的查詢請求進行查詢。這時系統中有兩個請求（工資單報表和數據庫查詢），操作系統就把這兩個請求表示爲數據庫進程中的兩個獨立的線程。
有時在一個進程中同時有多個請求。操作系統就把每個請求表示爲該進程中的一個獨立的線程，即一個進程中可同時又多個獨立的線程。
結語
需要一個觸發點和出發點
