1. 程式人生 > >資料結構-從巨集觀上理解資料結構

資料結構-從巨集觀上理解資料結構

注:本博文是本人對資料結構的理解,很多地方理解可能並不恰當,還請讀者辯證的來學習

從巨集觀上理解資料結構

很多時候我們一直在埋頭苦幹,卻不知道為什麼這樣......

             工作一年之後,重新回想一下大學裡學的資料結構,發現所剩的寥寥無幾,當提起某一種資料結構腦海中大體也只剩下了簡單的定義,如跳錶,也只是模糊記得是在一個有序連結串列上新增額外的指標來加快搜索速度,其他的似乎什麼都不記得了,記得當時在學習資料結構時對跳錶的理解還是蠻深刻的,然而時間一長卻忘掉了關於跳錶的大部分內容。之所以忘得這麼快,一方面是由於沒有時常複習外,還有另外一個重要原因就是當時沒有從巨集觀上去理解資料結構,沒有將跳錶的知識與其他相關的知識聯絡起來,以至於讓這麼一個孤零零的知識很快就遺忘了。其實學習就是這麼一個過程,在學習某個知識時,如果搞不懂它的原理或者不能將它與自己熟悉的知識聯絡起來,這個知識可能很快就會遺忘,如果能夠聯絡起來,那麼在平常生活中,你通過對自己熟悉的知識的運用可能自然而然的就聯絡到這個知識點,也就起到鞏固這個知識的作用。知識就是這樣一個不斷積累的過程,千變萬化的思維終歸還是對資訊的一種儲存和處理,不選擇一種合適的儲存方式去儲存資訊,儲存的資訊量就少或處理就變得很低效。資訊的處理效率低除了你的生理機能影響外你的思維方式也有很大的影響。類比計算機的處理資訊能力,影響因素除了本身的硬體效能外,軟體如何實現也有很大的關係。資料結構就是教授我們在除硬體影響外,我們該如何提高我們的程式效能的這樣一門課程。

              閒話扯了不少,但那終究還是硬道理。下面我就根據自己的經驗來為大家闡述一下如何從巨集觀上來理解資料結構,以便讓大家能夠將自己所學的資料結構知識有個巨集觀的認識,進而方便以後對資料結構知識的拓展。

1.資料結構對程式設計為什麼如此重要?

     現在就根據我自己的體會來為大家闡述一下資料結構對我們程式設計為什麼如此重要。記得在開始學習程式設計的時候,對資料結構沒什麼概念,感覺程式設計就是那麼回事,不用資料結構也能編出一大堆程式,然而我只能說那都是些小孩子過家家玩的小程式而已,程式中幾乎沒有用到多少資料,無論你怎麼儲存,程式執行起來都是很快的。然而當你為工程應用去編寫程式的時候,那都是處理大批的資料,那時候就不能隨便亂儲存資料了,必須根據實際情況選擇一種合適的資料結構來儲存資料,從而能夠大大提高資料的處理效率。舉個例子,我們平時經常用到的排序也算是對資料的處理,我們選擇不同的排序演算法效率是不同的,當資料量很小時,我們感覺不出它們的差異,然而當我們對大量資料進行排序時就能感覺出它們的效率來。當然在排序時排序策略是很重要的,然而這些策略有時是依賴於必要的資料結構的。如插入排序、選擇排序、快速排序等可能依賴的只是線性表,而堆排序就依賴於堆了。因此選擇一種好的資料結構可能會大大提高程式的執行效率,而且解決問題時的某中策略可能也要依賴於具體的資料結構。

2.什麼是資料結構?

     我們知道了資料結構對程式設計的重要性,那究竟什麼是資料結構呢?首先來看一下資料結構誕生的目的。在現實世界中存在著大量的資料,而這些資料不管以何種方式儲存,都需要使用一種結構來表示,而這種結構不僅能夠表示資料元素本身,還能夠表示資料元素之間的關係,最好這種結構還能佔據較少的儲存空間。然而這裡所說的資料結構也只能說是資料的邏輯結構,即它只是抽象的存在於我們的腦海中,而在具體的儲存中還需要將這種邏輯結構用現實事物表示出來。由於我們的計算機大部分功能都跟儲存資料和處理資料有關,因此計算機作為資料的載體與資料結構的關係也就相當大了,計算機就可以根據我們要求的資料結構來儲存資料了。至此,我們可以給資料結構下一個比較學術的定義:資料結構是用來描述資料元素集合及各個資料元素之間關係的邏輯結構。當然在很多資料結構的書籍中對資料結構的定義是不同的,有的書籍將對資料結構處理的簡單運算也歸為資料結構的內容,當然這看你如何理解了,畢竟資料結構和演算法是不分家的。

3.計算機描述資料的方式

      前邊描述了什麼是資料結構,那計算機都可以通過哪些基本的手段來描述我們的資料呢?首先我們知道在計算機中大部分資料都存在於磁碟上和記憶體裡,而CPU處理資料又必須將資料從磁碟讀取到記憶體中,由於記憶體資源比較珍貴,我們採取合適的資料結構在記憶體中儲存資料以節省記憶體空間是必要的。談到記憶體對資料的儲存,我們程式設計師都應該知道,我們的程式在計算機上執行需要一定的記憶體空間,該空間可以簡單分為程式碼區和資料區。程式碼區是存放我們程式程式碼的地方,那部分空間我們無法管理。但是資料區是存放我們程式需要處理的資料的地方,而我們就是採取合理的方式將資料儲存到那個地方。

        我們都知道計算機管理記憶體的方式為每個位元組的空間賦予一個地址,這樣我們就可以通過地址來訪問記憶體的資料了。當我們存放資料時,我們可以通過將資料存放到指定地址的空間中去,當我們取資料時,可以根據地址找到相應的資料,這種方式稱為直接定址方式;另外還有間接定址方式,這種方式我們通過地址找到的資料不是資料本身,而是資料存放的位置,通過它再去找才能找到真正的資料,當然,間接定址可以間接很多次,這就是多維指標的由來。說了大半天的直接定址和間接定址,那跟資料結構有什麼關係呢?當然有關係了,因為這是計算機組織資料的兩種最基本的方式,正是通過這兩種基本方式,我們的資料才被存放到記憶體中,而存放的時候可能是連續的地址空間,也可能是離散的地址空間。正因為這樣,才出現了計算機對資料的不同描述形式。常見的描述形式有:公式化描述、連結串列描述、間接描述和模擬指標。

        公式化描述是通過公式計算出元素的位置,從而能夠直接訪問到這個元素。但這種描述方式必須保證所使用的空間是連續的,因為只有連續的地址空間,才能通過一個固定的偏移量一次找到資料的地址。就拿各種程式語言實現的陣列來說,每個陣列都有一個連續的空間,而陣列名又標誌著這個連續空間的首地址,因此若想訪問這個陣列的某個元素直接通過首地址加偏移量就找到了。因此陣列就是一種公式化描述的資料結構,描述公式為f(i)=location(i-1),其中i是表示陣列中的第幾個元素。對於多維陣列,記憶體中實際也是一個連續的空間,只不過編譯器也是以公式化的方式來描述這個資料結構的,如在C++中是採用行主對映方式來對映的,二維陣列的公式為f(i,j)=i*n+j;其中i表示行號,j表示列號,n表示列數。當然採用公式化描述的資料結構有很多,如散列表、完全二叉樹等,這種描述方式優點就是很多情況能夠節省空間,並且提高訪問資料的速度。但這種描述方式也有缺點就是經常受限,畢竟很多問題是用公式沒法描述的;還有通過公式化描述需要連續的空間有時也顯得不夠靈活。例如對資料的插入刪除操作需要移動資料。

        連結串列描述方式是將資料儲存在離散的空間上,既然空間是離散的,那通過固定的偏移量就沒法訪問元素了。因此可將每個元素的地址儲存到上一個元素中,這樣就形成了連結串列。連結串列由於採用了離散儲存,因此在有些資料操作上就顯得比較靈活。但這也導致了它的不足,比如說不能隨機訪問某個節點,另外還佔用了額外的指標空間等。

         間接描述方式是將資料的地址儲存到一張表中,實際的資料離散的儲存在記憶體中,當需要訪問資料時,首先查詢表找到資料的地址然後再去訪問實際資料。這種描述方式很多時候是公式化描述和連結串列描述方式的結合。當實際的資料元素比較大時是適合用這種方式來描述的。

          模擬指標這種方式是通過用整數來模擬指標訪問資料,也算是離散儲存在記憶體中,但這種離散是限定在一定範圍內的,因為我們在實現模擬指標時需要申請一塊連續的空間模擬堆區,並根據實際需要將這塊連續的空間重新編號,以便使用整數表示它的地址。與此同時還要維護兩個連結串列,空閒連結串列和有資料的連結串列。這相當於我們替作業系統為程式分配記憶體的工作。

4.各種資料結構的巨集觀理解

           為了便於將各種資料結構聯絡起來,本人對常見的資料結構分為了三大類:線性表,樹,圖。萬變不離其宗,其他的資料結構都是在這三種上根據實際需要進行的擴充套件。當然,如果三大類還覺得有點多,那就再來個萬劍歸綜到圖,任何資料結構都可以說成是圖,不過各有各的特點罷了。下面就針對常見的資料結構在三大類上進行分析,由於本文只是從巨集觀上理解資料結構,因此對各種資料結構所實現的細節不會做太多的說明,想要了解可參看資料結構的相關書籍。

4.1線性表

            線性表的資料結構有很多,如陣列、矩陣、連結串列、堆疊、佇列、跳錶、散列表等。一維陣列是典型的線性表,多維陣列可以看成是多個線性表的組合,陣列的描述方式一般採用公式化描述方式。對於矩陣可以看成是二維陣列,但是由於矩陣有很多種,比如三角矩陣,稀疏矩陣,像對這樣矩陣的描述為了節省空間,可採用合理的描述方式,如採用連結串列的方式,只將非零元素儲存到節點上。堆疊和佇列實際上是對線性表新增某種限制而形成的, 堆疊是後進先出,佇列是先進先出,實際上它們是一種特殊的優先佇列,只不過對優先權的規定是不一樣的。可以使用公式化描述它們也可以使用連結串列描述它們,但是效率是不同的。對於堆疊採取公式化描述是比較好的,進出效率都為O(1),若用連結串列描述就顯得有點浪費空間了,不過如果是多個堆疊的話,用連結串列描述是比較好的。對於佇列適合用連結串列來描述,因為對於連結串列無論是從頭部新增元素還是從尾部刪除元素效率都是O(1),然而如果採用公式化描述的話,每次刪除需要移動元素,無疑增加了開銷。                 

             跳錶和散列表是經常用來描述字典的兩種資料結構。字典常見的操作有查詢、插入、刪除、按序輸出等。雖然字典也能用普通的陣列連結串列實現,但效率不高。跳錶是對連結串列的一種改進。連結串列本身優點就是插入、刪除效率比陣列高,然而查詢效率低,因此可以通過新增額外的指標來提高查詢效率。跳錶的原理是根據二分查詢的思想,我們知道在一個有序陣列上二分查詢的時間複雜度為O(logn),因此可以通過在有序連結串列上新增額外的指標來實現這樣的搜尋方法。然而仔細分析,我們會發現,要想實現真正的二分查詢並非易事,因為跳錶中的元素並非是一成不變的,因此該在哪個元素上新增額外的指標並且把該元素應該視為幾級連結串列上的元素,都是不可預測的,因此這就增加了實現跳錶的複雜度,在實際中可採用隨機的方式將某一個元素定為幾級鏈上的元素,具體的實現細節可參看資料結構的相關書籍。

           散列表是通過雜湊函式根據關鍵字來確定元素的位置,也算是公式化的描述方式。在理想情況下,散列表在查詢、插入、刪除的時間複雜度都能達到O(1),然而在現實中由於關鍵字的變化範圍實在太大,理想散列表實現需要大量的空間,造成嚴重浪費,因此出現了可以將不同的關鍵字對映到同一位置的雜湊函式,那麼問題就又來了,既然將不同的關鍵字對映到了同一位置,那麼該如何處理這種衝突呢?處理這種衝突的兩種常見方式是線性開型定址雜湊和連結串列雜湊,線性開型定址雜湊是將相同關鍵字的元素儘可能的放到函式對映的位置上,如果該位置已存在,則向後查詢最近的空桶;而連結串列雜湊是將衝突的元素放到一個連結串列上,這兩種方式各有自己的優缺點。

            對於描述字典的這兩種資料結構進行效能分析,跳錶在最好狀態下查詢、插入、刪除的時間複雜度都為O(k+logn)其中k為鏈的級數,最差則為O(k+n),而對於採取了將多個關鍵字對映到同一位置的散列表來說,最好狀態下查詢、插入、刪除的時間複雜度都為O(1),然而最差狀態卻達到O(n),這麼來說散列表是否都一直優於跳錶呢,當然還得依賴於實際的問題,例如在按序輸出時,跳錶明顯優於散列表。

             線上性表這幾種資料結構中會發現,他們都是對普通的線性表改造而成,有的是新增規則上的限制,有的是新增額外的輔助資訊,還有的是對多個線性表的組合。但無論怎樣變化,終究還是線性表。因此我們在實際開發中,可以根據不同資料結構的特點來選擇他們。

4.2樹

             樹可以用來描述具有層次結構的事物,樹這種結構真是太神奇了,通過對樹新增不同的限制就形成了不同的資料結構。如對只有左右孩子的樹我們稱之為二叉樹,在二叉樹下通過新增各種限制又產生了很多資料結構,如完全二叉樹、堆、左高樹、AVL樹、紅黑樹、二叉搜尋樹等。下面就來詳細描述一下這些關於樹的資料結構。

             首先考慮一個問題在計算機記憶體中為什麼多采用二叉樹來儲存資料,而不採用多叉樹呢?當然也是為了提高速度處理效率,在搜尋二叉樹的一個節點時當然是比較的次數越少越好。試考慮在一個有序陣列中進行二分查詢要比三分查詢、四分查詢乃至更多分的查詢效率更高呢?這個問題自然也就明白了。

             完全二叉樹是對二叉樹結構層次限制比較大的資料結構,那這種資料結構有什麼好處呢,其中一個好處是這種資料結構採用公式化描述是非常方便的,而且大大的節省空間。

             將完全二叉樹限制為最大樹就形成了堆,而堆這種資料結構對於描述優先佇列是非常高效的,使用堆來描述優先佇列插入、刪除的效率都為O(logn),而且採用公式化描述的話非常節省空間。當然優先佇列還可以用線性表來描述,然而那畢竟是低效的。然而如果想將兩個優先佇列合併,用堆來描述就非常低效了,就需要選擇另外一種資料結構。左高樹是對左右子樹進行優先權限制的二叉樹,至於選擇什麼作為優先權的評價因素,可以把高度作為評價因素,也可以把節點數量作為評價因素,那就分別形成了高度優先左高樹和重量優先左高樹。之所以對左右的子樹進行優先權限制,那是因為進行了這樣的限制後,將兩棵左高樹合併為一棵左高樹就很容易了。將左高樹再次新增最大樹的限制條件就形成了最大左高樹,最大(小)左高樹同樣可以描述優先佇列,而且適合兩棵樹的合併,不過在儲存效率方面不如堆節省空間了。

             接下來討論一下搜尋樹,搜尋樹是另一種可以描述字典的高效的資料結構。先來分析一下二叉搜尋樹,二叉搜尋樹是對二叉樹節點上的值進行限制,要求每個節點的值比左子樹的值大並且比右子樹的小,加上這一限制,對某一元素的搜尋效率就比較高了,在最好情況下查詢,插入,刪除操作的時間複雜度都能夠達到O(logn),然而最壞情況下達到了O(n),導致最壞情況是由於二叉樹的極度不平衡造成的,為了解決這個問題,平衡樹又摻和進來了,平衡二叉搜尋樹不就很好的解決了這個問題嗎?然而在每次插入刪除操作後AVL樹為了維持平衡的特性需要進行多次旋轉,因而這又降低了效率。紅黑樹的出現就很好的解決了這個問題,紅黑樹雖然不是完全平衡的二叉樹但也算的上是基本平衡,然而紅黑樹對於插入刪除操作後維持紅黑樹的特性花費的代價並不高。在現實應用中,很多字典都是用紅黑樹來進行描述的。除了二叉搜尋樹,多叉搜尋樹在很多地方也有應用,例如在讀取磁碟資料時,可以採用B-樹來建立索引,由於每次讀取磁碟花費的代價比較大,因此讀取的磁碟次數越少越好,從理論上也就是說樹的高度越矮越好。又如為了提高索引速度,很多資料庫採用B+樹建立索引。另外,由於英語單詞一般是用字母拼湊而成,因此將英語單詞存放在多叉樹中可以大大提高搜尋單詞的效率,這就是著名的Trie樹。

             通過以上對各種由樹產生的資料結構來看,通過對樹新增各種限制來維持一種固定的資料結構對解決某些特定的問題是非常高效的,因此在現實應用中,我們應該根據實際的需要選擇合適的資料結構或對某些資料結構進行改造,變成真正適合自己的資料結構。

4.3圖

              用圖來描述萬千事物極其聯絡是最方便不過的了,然而根據具體的問題所產生的圖也是不一樣的,如有的事物用有向圖描述比較合適,有的用無向圖描述比較合適,有的用完全圖描述比較合適,有的用連通圖描述比較合適,有的用二分圖描述比較合適,不管怎樣要根據實際的問題使用不同的方式,當然在解決實際問題時,往往需要結合必要的演算法。

              對於圖的描述經常採用的是鄰接矩陣和鄰接連結串列來描述。

本文結束!

下面為大家分享一個小的學習經驗,記得剛學資料結構時被我們資料結構教材著實折磨的不輕,它是由英文翻譯而來,裡面的很多段落我讀好幾遍都沒明白過來,最後一氣之下找到英文原版,沒想到看一遍就明白了,哎真是國人看不懂中文了,我也是醉了,所以建議大家還是儘量讀英文原著,因為那些翻譯的未必就是很專業的人翻譯的,往往都是一些導師帶的學生翻譯的。可以看出我們這個專業對英語要求還是比較高的,建議大家平時多背背專業單詞,學學英語,推薦個比較好的背單詞軟體,他特別適合平時瑣碎的時間來背單詞,另外裡邊的拍照翻譯也很實用,你在讀英文原著的時候遇到不會的句子用手機拍一下就給你翻譯了,而且還可以把你不認識的單詞新增到單詞本來記憶,微信小程式搜“詞詞通”,有個詞詞通幫你背單詞的小程式,點選進入就可以使用了。

相關推薦

資料結構-巨集觀理解資料結構

注:本博文是本人對資料結構的理解,很多地方理解可能並不恰當,還請讀者辯證的來學習 從巨集觀上理解資料結構 很多時候我們一直在埋頭苦幹,卻不知道為什麼這樣......              工作一年之後,重新回想一下大學裡學的資料結構,發現所剩的寥寥無幾,當提起某一種

深入理解 Tomcat (二) 巨集觀理解 Tomcat 元件及架構

轉載自:https://blog.csdn.net/qq_38182963/article/details/78660773 這是我們自編譯原始碼以來第一次總結 tomcat, 雖然不知從何說起, 但這筆不能停下來, 看了很多的文章和原始碼, 腦子裡從最初

資料結構---在記憶體理解連結串列

第一次寫部落格,有寫的不好的地方請多指教。首先,在學習資料結構中,對連結串列在記憶體上的理解非常重要,上程式碼public class LinkNode<M> {    public  M data;    public  LinkNode nextNode;  

怎麼理解Get是用來伺服器獲得資料

說實話第一次看見你這個問題,我也蒙了,這麼坑爹的話,你從哪裡看到的?不會是哪本坑爹的書吧。我百度了下,百度文庫裡面有一個文件,還是第一頁= =,害人子弟。對於第一句“Get是用來從伺服器上獲得資料”你可以忽略了,不管別人怎麼認為,反正我認為這是坑爹的,更是坑害新手的。 jsp中get和

Centos6安裝圖形介面(hdp不需要,hdp直接github下載資料即可)

CentOS 6.5 安裝圖形介面 安裝的時候沒有安裝影象介面。安裝步驟如下: 1.yum -y groupinstall Desktop 2.yum -y groupinstall "X Window System" 3.init 5 由字元介面切換到圖形介面可用兩種簡單方法實現: 1、在字元介面

網站讀取資料失敗

有個自用的工具,從網站上讀取資料。 後來發現讀取的資料不完全。 除錯程式,發現都正常。粗略看了看源程式,也都是對的。又插入許多語句把中間變數寫到檔案中。發現也沒什麼大問題。折騰了很久,無果,就先不管了。 大半年過去了,斷斷續續地偶爾看看程式,也沒找到哪裡出錯了。 前兩天,又著手看看這個程式。

Java視角理解系統結構(一)CPU上下文切換

作者:Minzhou  本文是從Java視角理解系統結構連載文章 在高效能程式設計時,經常接觸到多執行緒. 起初我們的理解是, 多個執行緒並行地執行總比單個執行緒要快, 就像多個人一起幹活總比一個人幹要快. 然而實際情況是, 多執行緒之間需要競爭IO裝置, 或者競爭鎖資源,導致往往執行速度還不

Java視角理解系統結構(三)偽共享

從Java視角理解系統結構連載, 關注我的微博(連結)瞭解最新動態 從我的前一篇博文中, 我們知道了CPU快取及快取行的概念, 同時用一個例子說明了編寫單執行緒Java程式碼時應該注意的問題. 下面我們討論更為複雜, 而且更符合現實情況的多核程式設計時將會碰到的問題. 這些問題更容易犯, 連j

Java視角理解系統結構(二)CPU快取

從Java視角理解系統結構連載, 關注我的微博(連結)瞭解最新動態 眾所周知, CPU是計算機的大腦, 它負責執行程式的指令; 記憶體負責存資料, 包括程式自身資料. 同樣大家都知道, 記憶體比CPU慢很多. 其實在30年前, CPU的頻率和記憶體匯流排的頻率在同一個級別, 訪問記憶體只比訪問

TcpSocket讀取資料的三種方式

我在一個專案中碰到了一個TcpSocket的應用。在java程式中使用TcpSocket同本機的一個服務進行程序間的通訊。由於通訊路徑只是單機並沒有經過網路,因此兩個程序之間的互通相對與網路傳輸是比較快速的。因此,程序間的互動使用瞭如下方式:(見上傳圖片)讓我們看一下程式碼實

Android:解決客戶端伺服器獲取資料亂碼的方法

向伺服器傳送HTTP請求,接收到的JSON包為response,用String content = EntityUtils.toString(response.getEntity(),"utf-8");解碼還是出現了中文亂碼,在後面加了 String name

原理理解Base64編碼

width sci 傳統 wid 文字 com base64編碼 限制 位數 開發者對Base64編碼肯定很熟悉,是否對它有很清晰的認識就不一定了。實際 上Base64已經簡單到不能再簡單了,如果對它的理解還是模棱兩可實在不應該。大概介紹一下Base64的相關內容,花幾分鐘

原理理解如何由震源機制一個節面的解:strike,dip,rake可以求出另一個節面的解

方向 矢量 不難 角度 image 技術 log 表達 分享 首先,需要回到最原始的地震矩的表達式: 已知strike,dip,rake 根據strike和dip可以求出v,根據strike,dip,rake,可以求出u。 把求出來的v和u互換,相當於原來的位錯矢量變成法

深入淺出“跨檢視資料粒度計算”--1、理解資料的粒度

此文已由作者王文開授權網易雲社群釋出。 歡迎訪問網易雲社群,瞭解更多網易技術產品運營經驗。 跨檢視資料粒度計算(Cross-Granularity Calculation)是網易有數推出的新功能,CGC的優點是您可以獨立於當前檢視用的維度來執行此計算。CGC計算表示式一共有三種,分別是:FIXED,INCL

海量資料去重(資料去重)

   在資料開發中,我們不難遇到重複資料的問題,搞過這類資料開發的同志肯定覺得,重複資料是真的煩人,特別是當資料量十分大的時候,如果我們用空間複雜度去換時間複雜度,會十分耗內容,稍不注意,就會記憶體溢位,那麼針對如此龐大的資料量我們一般能怎麼解決呢?下面分享幾個方案: 方案一

C語言的int, float,double相互轉化 (本質理解可能的問題)

從學了C語言之後,一直習慣於C/C++任意的強制轉化,但是C語言的強制轉化卻總是帶來意想不到的後果,在這裡,我將從int,float,double的本質上講解這些可能出現的問題以及解決辦法,在下面你將看到: OK,現在好戲開始。

C語言的int, float,double相互轉化(本質理解可能的問題)

從學了C語言之後,一直習慣於C/C++任意的強制轉化,但是C語言的強制轉化卻總是帶來意想不到的後果,在這裡,我將從int,float,double的本質上講解這些可能出現的問題以及解決辦法,在下面你將看到: OK,現在好戲開始。 int un

整理理解進程創建、可執行文件的加載和進程執行進程切換,重點理解分析fork、execve和進程切換

files 修改 eve rdquo ces 堆棧分配 初始 data led 一.進程的創建   Linux創建進程是通過子進程復制父進程所擁有的資源來實現的。現代Linux通過寫時復制、共享數據等方法優化這一過程,提高創建子進程的效率。   在Linux中,進程創建

原始碼理解Netty併發工具-Promise

前提 最近一直在看Netty相關的內容,也在編寫一個輕量級的RPC框架來練手,途中發現了Netty的原始碼有很多亮點,某些實現甚至可以用苛刻來形容。另外,Netty提供的工具類也是相當優秀,可以開箱即用。這裡分析一下個人比較喜歡的領域,併發方面的一個Netty工具模組 - Promise。 環境版本:

硬核資料結構,讓你B樹理解到B+樹

本文始發於個人公眾號:**TechFlow**,原創不易,求個關注 今天是週五分散式系統的第八篇文章,核心內容是B+樹的原理。 今天的文章是上週B樹的延伸,所以新關注的或者是有所遺忘的同學建議先從下方連結回顧之前的內容。 硬核挑戰——從零開始動手圖解B樹 B+樹的特性 B+樹和B樹一樣都是多路平衡樹,也叫多叉