引言
深入理解計算機系統，對我來說是部大塊頭。說實話，我沒有從頭到尾完完整整的全部看完，而是選擇性的看了一些我自認為重要的或感興趣的章節，也從中獲益良多，看清楚了計算機系統的一些本質東西或原理性的內容，這對每個想要深入學習編程的程序員來說都是至關重要的。只有很好的理解了系統到底是如何運行我們代碼的，我們才能針對系統的特點寫出高質量、高效率的代碼來。這本書我以后還需要多研究幾遍，今天就先總結下書中我已學到的幾點知識。

重點筆記
編寫高效的程序需要下面幾類活動：

選擇一組合適的算法和數據結構。這是很重要的，好的數據結構有時能幫助更快的實現某些算法，這也要求編程人員能夠熟知各種常用的數據結構和算法。
編寫出使編譯器能夠有效優化以轉換成高效可執行的源代碼。因此，理解編譯器優化的能力和局限性是很重要的。編寫程序方式中看上去只是一點小小的變動，都會引起編譯器優化方式很大的變化。有些編程語言比其他語言容易優化得多。C語言的某些特性，例如執行指針運算和強制類型轉換的能力，使得編譯器很難對其進行優化。
并行技術，針對處理運算量特別大的計算，將一個任務分成多個部分，這些部分可以在多核和多處理器的某種組合上并行地計算。
讓編譯器展開循環
說到程序優化，很多人都會提到循環展開技術。現在編譯器可以很容易地執行循環展開，只要優化級別設置的足夠高，許多編譯器都能例行公事的做到這一點。用命令行選項“-funroll-loops”調用gcc，會執行循環展開。

性能提高技術：

高級設計，為手邊的問題選擇適當的算法和數據結構，要特別警覺，避免使用會漸進地產生糟糕性能的算法或編碼技術。
基本編碼原則。避免限制優化的因素，這樣編譯器就能產生高效代碼。
消除連續的函數調用。在可能時將計算移到循環外，考慮有選擇的妥協程序的模塊性以獲得更大效率。
消除不必要的存儲器引用。引入臨時變量來保存中間結果，只有在最后的值計算出來時，才能將結果放到數組或全局變量中。
低級優化。
嘗試各種與數組代碼相對的指針形式。
通過開展通過展開循環降低循環開銷。
通過諸如迭代分割之類的技術，找到使用流水線化的功能單元的方法。
說到性能提高，可能有人會有一些說法：

（1）不要過早優化，優化是萬惡之源；
（2）花費很多時間所作的優化可能效果不明顯，不值得；
（3）現在內存、CPU價格都這么低了，性能的優化已經不是那么重要了。
　……

其實我的看法是：我們也許不必特地把以前寫過的程序拿出來優化下，花費N多時間只為提升那么幾秒或幾分鐘的時間。但是，我們在重構別人的代碼或自己最初開始構思代碼時，就需要知道這些性能提高技術，一開始就遵守這些基本原則來寫代碼，寫出的代碼也就不需要讓別人來重構以提高性能了。另外，有的很簡單的技術，比如說將與循環無關的復雜計算或大內存操作的代碼放到循環外，對于整個性能的提高真的是較明顯的。

如何使用代碼剖析程序（code profiler，即性能分析工具）來調優代碼？
程序剖析（profiling）其實就是在運行程序的一個版本中插入了工具代碼，以確定程序的各個部分需要多少時間。
Unix系統提供了一個profiling叫GPROF，這個程序產生兩類信息：

首先，它確定程序中每個函數花費了多少CPU時間。
其次，它計算每個函數被調用的次數，以執行調用的函數來分類。還有每個函數被哪些函數調用，自身又調用了哪些函數。

使用GPROF進行剖析需要3個步驟，比如源程序為prog.c。
1）編譯：?gcc -O1 -pg prog.c -o prog（只要加上-pg參數即可）
2）運行：./prog
　會生成一個gmon.out文件供 gprof分析程序時候使用（運行比平時慢些）。
3）剖析：gprof prog
　分析gmon.out中的數據，并顯示出來。
剖析報告的第一部分列出了執行各個函數花費的時間，按照降序排列。
剖析報告的第二部分是函數的調用歷史。具體例子可參考網上資料。

GPROF有些屬性值得注意：

計時不是很準確。它的計時基于一個簡單的間隔計數機制，編譯過的程序為每個函數維護一個計數器，記錄花費在執行該函數上的時間。對于運行時間較長的程序，相對準確。
調用信息相當可靠。
默認情況下，不顯示庫函數的調用。相反地，庫函數的時間會被計算到調用它們的函數的時間中。
靜態鏈接和動態鏈接一個很重要的區別是：動態鏈接時沒有任何動態鏈接庫的代碼和數據節真正的被拷貝到可執行文件中，反之，鏈接器只需拷貝一些重定位和符號表信息，即可使得運行時可以解析對動態鏈接庫中代碼和數據的引用。

存儲器映射
指的是將磁盤上的空間映射為虛擬存儲器區域。Unix進程可以使用mmap函數來創建新的虛擬存儲器區域，并將對象映射到這些區域中，這屬于低級的分配方式。
一般C程序會使用malloc和free來動態分配存儲器區域，這是利用堆的方式。

造成堆利用率很低的主要原因是碎片，當雖然有未使用的存儲器但不能用來滿足分配請求時，就會發生這種現象。
有兩種形式的碎片：內部碎片和外部碎片。兩者的區別如下：

內部碎片是在一個已分配的塊比有效載荷大時發生的。例如，有些分配器為了滿足對其約束添加額外的1字的存儲空間，這個1字的空間就是內部碎片。它就是已分配塊大小和它們的有效載荷大小之差的和。
外部碎片是當空閑存儲器合計起來足夠滿足一個分配請求，但是沒有一個單獨的空閑塊足夠大可以來處理這個請求時發生的。
現代OS提供了三種方法實現并發編程：

進程。用這種方法，每個邏輯控制流都是一個進程，由內核來調度和維護。因為進程有獨立的虛擬地址空間，想要和其他流通信，控制流必須使用進程間通信（IPC）。
I/O多路復用。這種形式的并發，應用程序在一個進程的上下文中顯示地調度它們自己的邏輯流。邏輯流被模擬為“狀態機”，數據到達文件描述符后，主程序顯示地從一個狀態轉換到另一個狀態。因為程序是一個單獨的進程，所以所有的流都共享一個地址空間。
線程。線程是運行在一個單一進程上下文中的邏輯流，由內核進行調度。線程可以看做是進程和I/O多路復用的合體，像進程一樣由內核調度，像I/O多路復用一樣共享一個虛擬地址空間。
（1）基于進程的并發服務器
構造并發最簡單的就是使用進程，像fork函數。例如，一個并發服務器，在父進程中接受客戶端連接請求，然后創建一個新的子進程來為每個新客戶端提供服務。為了了解這是如何工作的，假設我們有兩個客戶端和一個服務器，服務器正在監聽一個監聽描述符（比如描述符3）上的連接請求。下面顯示了服務器是如何接受這兩個客戶端的請求的。

進程并發示例
關于進程的優劣，對于在父、子進程間共享狀態信息，進程有一個非常清晰的模型：共享文件表，但是不共享用戶地址空間。進程有獨立的地址控件愛你既是優點又是缺點。由于獨立的地址空間，所以進程不會覆蓋另一個進程的虛擬存儲器。但是另一方面進程間通信就比較麻煩，至少開銷很高。

（2）基于I/O多路復用的并發編程
比如一個服務器，它有兩個I/O事件：1）網絡客戶端發起連接請求，2）用戶在鍵盤上鍵入命令行。我們先等待那個事件呢？沒有那個選擇是理想的。如果accept中等待連接，那么無法響應輸入命令。如果在read中等待一個輸入命令，我們就不能響應任何連接請求（這個前提是一個進程）。
針對這種困境的一個解決辦法就是I/O多路復用技術。基本思想是：使用select函數，要求內核掛起進程，只有在一個或者多個I/O事件發生后，才將控制返給應用程序。
I/O多路復用的優劣：由于I/O多路復用是在單一進程的上下文中的，因此每個邏輯流程都能訪問該進程的全部地址空間，所以開銷比多進程低得多；缺點是編程復雜度高。

（3）基于線程的并發編程
每個線程都有自己的線程上下文，包括一個線程ID、棧、棧指針、程序計數器、通用目的寄存器和條件碼。所有的運行在一個進程里的線程共享該進程的整個虛擬地址空間。由于線程運行在單一進程中，因此共享這個進程虛擬地址空間的整個內容，包括它的代碼、數據、堆、共享庫和打開的文件。所以我認為不存在線程間通信，線程間只有鎖的概念。

線程執行的模型。線程和進程的執行模型有些相似。每個進程的生明周期都是一個線程，我們稱之為主線程。但是大家要有意識：線程是對等的，主線程跟其他線程的區別就是它先執行。
一般來說，線程的代碼和本地數據被封裝在一個線程例程中（就是一個函數）。該函數通常只有一個指針參數和一個指針返回值。
在Unix中線程可以是joinable（可結合）或者detached（分離）的。joinable可以被其他線程殺死，detached線程不能被殺死，它的存儲器資源有系統自動釋放。

線程存儲器模型，每個線程都有它自己的獨立的線程上下文，包括線程ID、棧、棧指針、程序計數器、條件碼和通用目的寄存器。每個線程和其他線程共享剩下的部分，包括整個用戶虛擬地址空間，它是由代碼段、數據段、堆以及所有的共享庫代碼和數據區域組成。不同線程的棧是對其他線程不設防的，也就是說：如果一個線程以某種方式得到一個指向其他線程的指針，那么它可以讀取這個線程棧的任何部分。

什么樣的變量多線程可以共享，什么樣的不可以共享？
有三種變量：全局變量、本地自動變量（局部變量）和本地靜態變量，其中本地自動變量每個線程的本地棧中都存有一份，不共享。而全局變量和靜態變量可以共享。
————————————————
版權聲明：本文為CSDN博主「小敏紙」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lanxuezaipiao/article/details/41704011

總結

以上是生活随笔為你收集整理的深入理解计算机系统9个重点笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。