編程中所謂的Buffer(暫存)可以說是一種資料操作的概念，大凡就字面上大家都懂 但若非有實作經驗過，否則對它的運作方式及差別，則會模糊而似懂非懂，我就是 這樣一個過來人....然而，經過網路Socketing剖析及queue狀循環使用資料的實務 經驗後(使用C++)，我慢慢得到一個清晰的感受。 Buffer的需求 ------------- 當我們要對一堆資料作操作，必須建立所謂的位元陣列來擺放實際資料，然而當資 料量太大時，我們必須分批次地用此陣列來處理，如: int totalDataSize = 99999; while (totalDataSize > 0) { int arraySize = processArray(100); // 複製至陣列且作運算。 totalDataSize = totalDataSize - arraySize; } 但totalDataSize值非常大時，整個while都在運作中，cpu時間都被它佔走了，而實 務上還有其他事情等待cpu處理，因此用while()來處理大資料，是不切實際的單純 想法。況且每一次的while()執行後，陣列的值都被洗掉了... 既然記憶體有限，我們只要找延伸性的替代，就是File(檔案)。為了避免檔案寫入 一直無限擴大，我們會在超過某大小後回到Position=0重新寫檔，形成一個環狀資 料帶。嗯，問題解決了，然而檔案讀寫操作不夠快且單一磁頭競爭下，效率很差。 因此最好是能在記憶體配置某大小的暫存區，而最終會寫入檔案，這塊擔任中間媒 介的洗錢記憶體的就叫做Buffer，它是用來增加讀寫效率的。其實，硬碟本身有它 的Buffer記憶體，而OS寫檔操作也是有內建Buffer空間，但這些我們無法控制大小 及寫入時間，因此必須實作自己的Buffer機制。 Stream概念的產生 ----------------- 「配置一塊記憶體當Buffer，等滿了再寫入檔案」就是這架構。紙上當兵大家都會 ，但怎麼實作呢？如何撰寫一個機制，讓Buffer寫入檔案的動作是自動化而不用讓 使用者擔心寫讀的時間點呢？於是這種自動化延伸Buffer的機制被實作，就稱為「 Stream(串流)」的概念。使用者只要設定好Stream最終寫入的裝置，且設定好這個 Stream的內建Buffer大小，其實就只要Read()/Write()即可。 Stream就像是一個連接帶，一個河川，一直延伸寫入著，當你要讀取資料時，只要 設定它的Position，即可讀取出來。然而一個Stream的寫入點及讀寫點只提供一個 因此要同時讀寫，就必須透過兩個執行緒(Read/Write)來控制這個Stream的Position。 雖然同屬一個Stream結構，在寫入點附近的位置，其實際讀寫裝置是Buffer記憶體， 讀寫最快但也是容易Write/Read相衝突的地方，這需要靠邏輯去避免讀寫正在寫入的 區塊。而這部分，就是實務上，我們必須自己去依案例實作的地方。 結論 ----- Buffer只是一種概念，由上文得知，稱呼的地方卻完全不同。它可以是一個記憶體內 某固定長度陣列(1)，也可以指檔案(2)，更可以指整個Stream機制(3)，或是單指某 Stream中的Buffer記憶體(4)…等四種。我在網路Socket程式的實作中，為了接收資料 來作剖析，遇到第1種(陣列)的瓶頸而創作了第3種(stream)的Queue循環使用，最後 面臨記憶體有限的現實，把Buffer實作在第2種(檔案)方式上，再增加讀寫效率而內建 第4種的機制。 這樣土法煉鋼後，再去使用.Net中的IO物件，完全清楚它的設計理念及使用時機了! 這些MemoryStream/FileStream/BufferedStream/NetworkStream/CryptStream及 各式SteamReader/Writer，都是我實作經驗中的某些角色，因此當我呼叫他們時， 是真正清楚它們所擔任的崗位呀。這些.Net物件我之前已研究了三次，是會用但不知 其背後的原理及差別，如此透過C++來實作它們，再回歸C#來使用它們，別有一番不同 的感受。 -- 貫徹分享精神 我為人人，人人為我 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 211.78.132.15