不說其他了，最近為了實現(xiàn)這么一個場景了而提取的一種結(jié)構(gòu)。我們把一種數(shù)據(jù)緩存，比如開辟的存儲Buffer,或者連接池。放置在一個結(jié)構(gòu)中。很多時候這有一個共同的特點，我們的業(yè)務(wù)在一段時間會急劇增長，我們開辟的緩存也需要增長，或者說有一個峰值，但是過了一段時間后就不需要了。我假設(shè)峰值100個buffer,但是大部分80.這樣一直保持的沒有任何意義，浪費資源，尤其是我們的buffer存儲的類似數(shù)據(jù)庫連接（數(shù)據(jù)庫連接池），需要動態(tài)判斷和移除釋放。

? ? ?這里首先考慮的是stack,為什么呢？我們把stack看做一個桶，總是在頂上操作。如果有多余沒有使用的，你們它一直在桶底保留著，很久都不會使用，所以stack是很方便做這類事情的，一般情況可以直接使用stack來操作，然后每隔一段時間去檢查stack內(nèi)部數(shù)據(jù)（尤其是底部的數(shù)據(jù)），看看是否是很久都沒有使用了，可以釋放。但是stack沒有提供直接對底部數(shù)據(jù)的操作訪問，不是很方便，所以最好的辦法是桶結(jié)構(gòu)的頂部經(jīng)常操作數(shù)據(jù)（先進后出），在必要的時候（很少很少）也可以操作底部數(shù)據(jù)，只是用于檢測是否有多余的數(shù)據(jù)放置在桶底，很久沒有使用，需要釋放（很多時候我們實行的就是一個時間）；

? 最后我根據(jù)自己的需要，采用linkedlist和monitor同步，來存儲數(shù)據(jù)，將尾部看做桶頂。也提供對頭的操作，這樣來實現(xiàn)這個結(jié)構(gòu)。基本符合我的需要。另外我把存儲的使用也提取出來了。在里面存儲的結(jié)構(gòu)的必須是接口實現(xiàn)。每個元素只提供一個狀態(tài)，刪除數(shù)據(jù)時，只是修改這個元素的狀態(tài)，并不是真正的移除，只有在取出數(shù)據(jù)時，才驗證這個數(shù)據(jù)元素是否已經(jīng)被移除，這樣來提高效率，減少線程競爭，同時把移除的數(shù)據(jù)放在結(jié)構(gòu)的一個集合中，成批量的由事件推送，這樣提高移除數(shù)據(jù)的操作，而移除數(shù)據(jù)是否需要就看業(yè)務(wù)需要了，比如我存儲的數(shù)據(jù)庫連接池，那么就需要，移除的連接并沒有真實釋放，業(yè)務(wù)需要真實的釋放就需要處理這些移除。

我把實現(xiàn)的結(jié)構(gòu)，以及提取的存儲帶狀態(tài)的模型都抽離出來，做了一個demo，供有相關(guān)需要的參考，項目已經(jīng)上傳GIT.

項目地址：

https://github.com/jinyuttt/ConcurrentBucket.git

?

轉(zhuǎn)載于:https://www.cnblogs.com/jinyu20180311/p/10312353.html

總結(jié)

以上是生活随笔為你收集整理的c#一种存储结构解决动态平衡问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。