從內核的觀點看,進程的目的就是擔當分配系統資源(CPU時間、內存等)的基本單位。
進程之間是隔離的。有虛擬內存隔離數據訪問。對共享資源的併發訪問引發內核同步方法。
管道、信號、消息隊列、共享內存、socket、信號量
進程間通信的難題在於既要保證程序隔離又要保持通信。而共享內存雖然快,可是麻煩,須要各類鎖的配合。麻煩並且容易出錯。其餘方式提供了一些便利的操做,但也犧牲了部分性能。
安卓使用Binder來提供進程間通信html
linux進程地址空間
在32位模式下它是一個4GB的內存地址塊。在Linux系統中, 內核進程和用戶進程所佔的虛擬內存比例是1:3。經過頁表的將進程地址映射到物理內存或緩存(磁盤)上。進程並不能直接操做內存,於是稱做虛擬內存。node
棧 (Stack):存儲局部、臨時變量,函數調用時,存儲函數的返回指針,用於控制函數的調用和返回。在程序塊開始時自動分配內存,結束時自動釋放內存,其操做方式相似於數據結構中的棧。 向下生長(地址減小)
堆 (Heap):存儲動態內存分配,須要程序員手工分配,手工釋放.注意它與數據結構中的堆是兩回事,分配方式相似於鏈表。 向上生長(地址增長)
未初始化過的數據(BSS):在程序運行初未對變量進行初始化的數據。linux
初始化過的數據(Data):在程序運行初已經對變量進行初始化的數據。
程序段(Text):程序代碼在內存中的映射,存放函數體的二進制代碼。程序員
64位進程的地址空間redis
CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本單位。或者說是分配CPU的基本單位。
實現線程其實就是實現程序在多個任務之間來回切換,並且要保證每一個任務的上下文。所以若是具備中斷功能那麼就能夠實現多線程,並不須要CPU的支持。但通常來講中斷程序須要操做系統的 支持。若是不是那麼嚴格的話,利用一些代碼技巧使得不一樣任務來回切換利用了特殊的宏也能夠實現多線程。算法
併發調度淺析
異步IO能夠下降延遲但並不能增長吞吐量,頻繁地切換反而可能下降性能。
異步io數據庫
基於存儲設備的文件系統類型:jffs2, yaffs, cramfs, romfs, ramdisk, ramfs/tmpfs等。
文件存儲結構:1. 超級塊(superblock) 2. inode 3. 數據區
軟連接與硬連接
Linux文件系統詳解
高速讀寫,使用共享內存與文件映射segmentfault
不知道爲何人家老喜歡問,這個東西不是一查就知道麼。都記得也不能反映出水平啊。緩存
2xx 成功
200 正常;請求已完成。
201 正常;緊接 POST 命令。
202 正常;已接受用於處理,但處理還沒有完成。
203 正常;部分信息 — 返回的信息只是一部分。
204 正常;無響應 — 已接收請求,但不存在要回送的信息。
3xx 重定向
301 已移動 — 請求的數據具備新的位置且更改是永久的。
302 已找到 — 請求的數據臨時具備不一樣 URI。
303 請參閱其它 — 可在另外一 URI 下找到對請求的響應,且應使用 GET 方法檢索此響應。
304 未修改 — 未按預期修改文檔。 305 使用代理 — 必須經過位置字段中提供的代理來訪問請求的資源。
306 未使用 — 再也不使用;保留此代碼以便未來使用。
4xx 客戶機中出現的錯誤
400 錯誤請求 — 請求中有語法問題,或不能知足請求。
401 未受權 — 未受權客戶機訪問數據。
402 須要付款 — 表示計費系統已有效。
403 禁止 — 即便有受權也不須要訪問。
404 找不到 — 服務器找不到給定的資源;文檔不存在。
407 代理認證請求 — 客戶機首先必須使用代理認證自身。
415 介質類型不受支持 — 服務器拒絕服務請求,由於不支持請求實體的格式。
5xx 服務器中出現的錯誤
500 內部錯誤 — 由於意外狀況,服務器不能完成請求。
501 未執行 — 服務器不支持請求的工具。
502 錯誤網關 — 服務器接收到來自上游服務器的無效響應。
503 沒法得到服務 — 因爲臨時過載或維護,服務器沒法處理請求。服務器
三次握手創建鏈接、四次握手
首先,兩次握手就能夠確保要發送的數據已經送達遠端。
三次握手能夠防止重複的創建鏈接的請求。也就是遠端在創建鏈接的時候再問一次:你真的要鏈接麼?因此須要三次。
而關閉鏈接的時候,須要發出請求確認對方能不能關閉。說關就關有以下問題1.對方還有數據沒發就會丟失。2. 萬一關閉鏈接的請求丟了,對方就傻了。 所以須要一個2次握手來發送關閉鏈接的請求。然後遠端再執行兩次握手來告知近端真的能夠關閉了。因此四次握手拆解開來就是1.近端:我能關了麼? 2. 遠端:能夠關了。每一步都須要二次握手來保證數據送達。值得注意的是,近端在第三次握手的時候就能夠關閉了,但還要進入TIME_WAIT。這是由於這個時候還不知道遠端收到沒,若是再收到FIN再重發。
這裏好像有個問題,若是TIME_WAIT跳過了,那遠端不是傻傻等待?現實中好像沒有出現這個問題,因此現狀的實現是否是準守這個協議呢?(也有可能會等到鏈接超時)
- 髒讀 :髒讀就是指當一個事務正在訪問數據,而且對數據進行了修改,而這種修改尚未提交到數據庫中,這時,另一個事務也訪問這個數據,而後使用了這個數據。
- 不可重複讀 :是指在一個事務內,屢次讀同一數據。在這個事務尚未結束時,另一個事務也訪問該同一數據。那麼,在第一個事務中的兩 次讀數據之間,因爲第二個事務的修改,那麼第一個事務兩次讀到的的數據多是不同的。這樣就發生了在一個事務內兩次讀到的數據是不同的,所以稱爲是不 可重複讀。例如,一個編輯人員兩次讀取同一文檔,但在兩次讀取之間,做者重寫了該文檔。當編輯人員第二次讀取文檔時,文檔已更改。原始讀取不可重複。若是 只有在做者所有完成編寫後編輯人員才能夠讀取文檔,則能夠避免該問題。
- 幻讀 : 是指當事務不是獨立執行時發生的一種現象,例如第一個事務對一個表中的數據進行了修改,這種修改涉及到表中的所有數據行。 同時,第二個事務也修改這個表中的數據,這種修改是向表中插入一行新數據。那麼,之後就會發生操做第一個事務的用戶發現表中還有沒有修改的數據行,就好象 發生了幻覺同樣。例如,一個編輯人員更改做者提交的文檔,但當生產部門將其更改內容合併到該文檔的主複本時,發現做者已將未編輯的新材料添加到該文檔中。 若是在編輯人員和生產部門完成對原始文檔的處理以前,任何人都不能將新材料添加到文檔中,則能夠避免該問題。
當須要跨語言跨平臺,或者壓縮數據時須要這些技術。表明protobuf