單例緩存池
❶ ThreadPoolExecutor線程池
當我們需要實現並發、非同步等操作時，可以使用ThreadPoolExecutor。
ThreadPoolExecutor
線程池：
系統中，我們創建（extend Thread/implement Runnable）、銷毀（正常run方法完成後線程終止）線程的代價是比較高昂的。
如果頻繁地創建和銷毀進程，會大大降低系統運行效率和吞吐量。
線程池使得線程可以被復用，避免了線程頻繁創建和銷毀的開銷，提高系統的運行效率和吞吐量。
希望對您有所幫助！~
❷ hashTable 和 hashMap 作緩存，實現的兩種單例的區別
Hashtable和HashMap的區別：1.Hashtable是Dictionary的子類，HashMap是Map介面的一個實現類；2.Hashtable中的方法是同步的，而HashMap中的方法在預設情況下是非同步的。即是說，在多線程應用程序中，不用專門的操作就安全地可以使用Hashtable了；而對於HashMap，則需要額外的同步機制。但HashMap的同步問題可通過Collections的一個靜態方法得到解決：MapCollections.synchronizedMap(Mapm)這個方法返回一個同步的Map，這個Map封裝了底層的HashMap的所有方法，使得底層的HashMap即使是在多線程的環境中也是安全的。3.在HashMap中，null可以作為鍵，這樣的鍵只有一個；可以有一個或多個鍵所對應的值為null。當get()方法返回null值時，即可以表示HashMap中沒有該鍵，也可以表示該鍵所對應的值為null。因此，在HashMap中不能由get()方法來判斷HashMap中是否存在某個鍵，而應該用containsKey()方法來判斷。Map├Hashtable├HashMap└WeakHashMapMap介面請注意，Map沒有繼承Collection介面，Map提供key到value的映射。一個Map中不能包含相同的key，每個key只能映射一個value。Map介面提供3種集合的視圖，Map的內容可以被當作一組key集合，一組value集合，或者一組key-value映射。Hashtable類Hashtable繼承Map介面，實現一個key-value映射的哈希表。任何非空（non-null）的對象都可作為key或者value。添加數據使用put(key,value)，取出數據使用get(key)，這兩個基本操作的時間開銷為常數。Hashtable通過initialcapacity和loadfactor兩個參數調整性能。通常預設的loadfactor0.75較好地實現了時間和空間的均衡。增大loadfactor可以節省空間但相應的查找時間將增大，這會影響像get和put這樣的操作。使用Hashtable的簡單示例如下，將1，2，3放到Hashtable中，他們的key分別是」one」，」two」，」three」：Hashtablenumbers=newHashtable();numbers.put(「one」,newInteger(1));numbers.put(「two」,newInteger(2));numbers.put(「three」,newInteger(3));要取出一個數，比如2，用相應的key：Integern=(Integer)numbers.get(「two」);System.out.println(「two=」+n);由於作為key的對象將通過計算其散列函數來確定與之對應的value的位置，因此任何作為key的對象都必須實現hashCode和equals方法。hashCode和equals方法繼承自根類Object，如果你用自定義的類當作key的話，要相當小心，按照散列函數的定義，如果兩個對象相同，即obj1.equals(obj2)=true，則它們的hashCode必須相同，但如果兩個對象不同，則它們的hashCode不一定不同，如果兩個不同對象的hashCode相同，這種現象稱為沖突，沖突會導致操作哈希表的時間開銷增大，所以盡量定義好的hashCode()方法，能加快哈希表的操作。如果相同的對象有不同的hashCode，對哈希表的操作會出現意想不到的結果（期待的get方法返回null），要避免這種問題，只需要牢記一條：要同時復寫equals方法和hashCode方法，而不要只寫其中一個。Hashtable是同步的。HashMap類HashMap和Hashtable類似，不同之處在於HashMap是非同步的，並且允許null，即nullvalue和nullkey。，但是將HashMap視為Collection時（values()方法可返回Collection），其迭代子操作時間開銷和HashMap的容量成比例。因此，如果迭代操作的性能相當重要的話，不要將HashMap的初始化容量設得過高，或者loadfactor過低。WeakHashMap類WeakHashMap是一種改進的HashMap，它對key實行「弱引用」，如果一個key不再被外部所引用，那麼該key可以被GC回收。
❸ 如何寫一個簡單的單例模式
一、基本的實現思路:
單例的實現主要是通過以下兩個步驟：
1、將該類的構造方法定義為私有方法，這樣其他處的代碼就無法通過調用該類的構造方法來實例化該類的對象，只有通過該類提供的靜態方法來得到該類的唯一實例；
2、在該類內提供一個靜態方法，當我們調用這個方法時，如果類持有的引用不為空就返回這個引用，如果類保持的引用為空就創建該類的實例並將實例的引用賦予該類保持的引用。
二、示範如下：
1、枚舉實現單例：
(3)單例緩存池擴展閱讀:
一、單列模式簡介：
單例模式是設計模式中最簡單的形式之一。這一模式的目的是使得類的一個對象成為系統中的唯一實例。要實現這一點，可以從客戶端對其進行實例化開始。因此需要用一種只允許生成對象類的唯一實例的機制，「阻止」所有想要生成對象的訪問。使用工廠方法來限制實例化過程。這個方法應該是靜態方法（類方法），因為讓類的實例去生成另一個唯一實例毫無意義。
二、懶漢與餓漢：
1、懶漢方式：指全局的單例實例在第一次被使用時構建。
2、餓漢方式：指全局的單例實例在類裝載時構建。
三、單例模式的三要點：
1、某個類只能有一個實例。
2、它必須自行創建這個實例。
3、它必須自行向整個系統提供這個實例。
四、優缺點：
1、優點：
①實例控制：單例模式會阻止其他對象實例化其自己的單例對象的副本，從而確保所有對象都訪問唯一實例。
②靈活性：因為類控制了實例化過程，所以類可以靈活更改實例化過程。
2、缺點：
①開銷：雖然數量很少，但如果每次對象請求引用時都要檢查是否存在類的實例，將仍然需要一些開銷。可以通過使用靜態初始化解決此問題。
②可能的開發混淆：使用單例對象（尤其在類庫中定義的對象）時，開發人員必須記住自己不能使用new關鍵字實例化對象。因為可能無法訪問庫源代碼，因此應用程序開發人員可能會意外發現自己無法直接實例化此類。
③對象生存期：不能解決刪除單個對象的問題。在提供內存管理的語言中（例如基於.NET Framework的語言），只有單例類能夠導致實例被取消分配，因為它包含對該實例的私有引用。在某些語言中（如 C++），其他類可以刪除對象實例，但這樣會導致單例類中出現懸浮引用。
❹ 有人用memcached出過這種問題么
1、key-value的限制
緩存的key有長度限制，key的組成有特定字元的限制。
緩存的value必須可以序列化，且緩存的單一value容量有大小限制，對於可序列化的value，應該想方設法盡量規避某些特定數據結構，比如Hashtable，DataTable這些內部其實非常非常之復雜的數據結構。對於讀頻繁的操作來說，每次序列化和反序列化復雜數據結構的開銷可想而知。
如果連分布式緩存的key和value（尤其是value）的一般限制都搞錯了，那麼使用緩存的後果很可能只是白白增加了網路IO及序列化、反序列化的開銷，對系統性能提升當然是巨大的反作用。
2、小心Memcached的.net客戶端的誤用
這一點隱藏的也比較深，下面以應用廣泛的EnyimMemcached為例來簡單說明。
通常我們使用的客戶端每次實例化MemcachedClient對象內部都會初始化一個客戶端對象池（TCP連接池，客戶端命名為ServerPool）。所謂TCP連接池就是將創建好的TCP連接（連接數通常按照配置來，生產環境的配置不會小於兩位數）初始化放在容器內，客戶端調用的時候可以直接拿出已經存在的TCP連接來用，這樣可以省去實時打開TCP連接的開銷。
因為有人喜歡using一下（當然包括樓主自己了），一看到MemcachedClient是繼承自IDisposable的，必須用using啊，然後就要new一個MemcachedClient對象，這樣客戶端內部也就不得不再初始化一個TCP連接池。如果某個使用緩存的服務方法調用頻繁，很快你就會發現系統CPU飆升，頁面打開速度奇慢，直至不能正常訪問。
我們知道，分布式緩存系統都有一個TCP連接上限的設置，無論如何，超過這個上限都有可能引發連環反應，這種反應毫無疑問是不良副作用。
所以如果我們誤用MemcachedClient，每次都new一個對象，那麼高並發情況下效果就非常慘了，一方面web伺服器因為TCP連接過多無法正常訪問，另一方面Memcached伺服器也因為連接太多負載過重而性能變得極差，依賴Memcached的服務很可能短時間內只接收到超時響應。
解決方案無比簡單，配置合適的TCP連接數，MemcachedClient對象單例即可。
最後還要重申選擇使用緩存的業務場景的重要性。這一點真的無法說透，但是根據一些已有經驗，可以提煉出兩條比較通用的緩存准則：
1、寫頻繁的數據不適合緩存；
2、讀頻繁而寫不頻繁的數據適合緩存。
果然正確的話都是廢話，上面兩條等於沒說。
怕你們說無聊，還是要奉獻兩條自己使用緩存的主要准則，當然只是自己一家之言經驗之談，不可全信，切記，否則被總監勸退老子概不負責：
1、適合緩存的數據通常應該對外公開供（所有）人調用，私有的數據緩存多數情況下是沒有意義的；
2、對准確性、實時性、安全性等要求極高的業務數據，你的數據可能不適合緩存。
順帶再提一下web開發中的性能問題。據說如果一個網站有性能問題，那麼它一定會出現性能問題。資料庫、緩存、消息隊列、各種框架、com組件等等等等，這些web開發中的標配，有哪個使用不當不會引發系統的性能問題呢？甚至大家習以為常的拼接字元串在特定條件下都會造成系統崩潰。我們也知道生產環境就像國際政治一樣錯綜復雜波譎雲詭，測試環境、UAT環境通過並不能保證系統諸事無虞，應該時刻認識到coding無小事，否則一個疏忽就有可能造成生產環境發生悲劇乃至慘劇。
❺ recycleview一行多個時，會全部緩存嗎
會。
首先說下RecycleView的緩存結構，Recycleview有四級緩存，分別是mAttachedscrap(屏幕內)，mCacheviews(屏幕外)，mViewcacheextension(自定義緩存)，mRecyclerpool(緩存池)mAttachedscrap(屏幕內)用於屏幕內itemview快速重用，不需要重新createview和bindview，mCacheviews(屏幕外)保存最近移出屏幕的Viewholder，包含數據和position信息，復用時必須是相同位置的Viewholder才能復用，應用場景在那些需要來回滑動的列表中，當往回滑動時，能直接復用Viewholder數據，不需要重新bindview。mViewcacheextension(自定義緩存)，不直接使用，需要用戶自定義實現，默認不實現。mRecyclerpool(緩存池)，當cacheview滿了後或者adapter被更換，將cacheview中移出的Viewholder放到Pool中，放之前會把Viewholder數據清除掉，所以復用時需要重新bindview。當recycleview一行多個時，recycleview的四級緩存機制支持全部緩存。
Recyclerview的緩存機制還是非常值得到家參考的，先來說一下Recyclerview關於緩存的方法，關於Recyclerview的緩存數據有兩個級別，一個是detach，另一個就是remove，關於detach就是在Recyclerview滑動或者layout時為了記錄屏幕內條目信息而設定的，他主要的緩存的數據就是getchildcount列表所持有的數據，至於remove就是為了緩存我們從數據列表所刪除的數據，根據這個信息我們可從代碼來分析。
❻ java如行創建一個可緩存線程池
packagetest;
importjava.util.concurrent.ExecutorService;
importjava.util.concurrent.Executors;
{
publicstaticvoidmain(String[]args){
=Executors.newCachedThreadPool();
for(inti=0;i<10;i++){
finalintindex=i;
try{
Thread.sleep(index*1000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
cachedThreadPool.execute(newRunnable(){
publicvoidrun(){
System.out.println(index);
}
});
}
}
}
線程池為無限大，當執行第二個任務時第一個任務已經完成，會復用執行第一個任務的線程，而不用每次新建線程。
❼ Java單例模式是什麼意思
Java單例模式是確保某個類只有一個實例，而且自行實例化並向整個系統提供這個實例，在計算機系統中，線程池、緩存、日誌對象、對話框、列印機、顯卡的驅動程序對象常被設計成單例的模式；
Java單例模式分三種：懶漢式單例、餓漢式單例、登記式單例。
❽ RecyclerView緩存原理及優化方向
Android新增的Recyclerview主要用於代替ListView。Recyclerview可擴展性強。
RecyclerView做性能優化要說復雜也復雜，比如說布局優化，緩存，預載入等等。
其優化的點很多，在這些看似獨立的點之間，其實存在一個樞紐：Adapter。
因為所有的ViewHolder的創建和內容的綁定都需要經過Adaper的兩個函數 onCreateViewHolder和onBindViewHolder 。
因此我們性能優化的本質就是要 **減少這兩個函數的調用時間和調用的次數** 。
如果我們想對RecyclerView做性能優化，必須清楚的了解到我們的每一步操作背後，onCreateViewHolder和onBindViewHolder調用了多少次。
因此，了解RecyclerView的緩存機制是RecyclerView性能優化的基礎。
為了簡化問題，繪制原理介紹提供以下假設：
（1）類的職責介紹
LayoutManager：接管RecyclerView的Measure，Layout，Draw的過程
Recycler：緩存池
Adapter：ViewHolder的生成器和內容綁定器。
（2）繪制過程簡介
RecyclerView緩存基本上是通過三個內部類管理的， Recycler 、 RecycledViewPool 和 ViewCacheExtension 。
Recycler
用於管理已經廢棄或者與RecyclerView分離的ViewHolder，為了方便理解這個類，整理了下面的資料，內部類的成員變數和他們的含義：
RecycledViewPool
RecycledViewPool類是用來緩存Item用，是一個ViewHolder的緩存池，如果多個RecyclerView之間用 setRecycledViewPool(RecycledViewPool) 設置同一個RecycledViewPool，他們就可以共享Item。
其實RecycledViewPool的內部維護了一個Map，裡面以不同的viewType為Key存儲了各自對應的ViewHolder集合。可以通過提供的方法來修改內部緩存的Viewholder。
ViewCacheExtension
開發者可自定義的一層緩存，是虛擬類ViewCacheExtension的一個實例，開發者可實現方法getViewForPositionAndType(Recycler recycler, int position, int type)來實現自己的緩存。
屏幕內緩存指在屏幕中顯示的ViewHolder，這些ViewHolder會緩存在mAttachedScrap、mChangedScrap中 ：
當列表滑動出了屏幕時，ViewHolder會被緩存在 mCachedViews ，其大小由mViewCacheMax決定，默認DEFAULT_CACHE_SIZE為2，可通過Recyclerview.setItemViewCacheSize()動態設置。
可以自己實現ViewCacheExtension類實現自定義緩存，可通過Recyclerview.setViewCacheExtension()設置。
ViewHolder在首先會緩存在 mCachedViews 中，當超過了個數（比如默認為2）， 就會添加到 RecycledViewPool 中。
在有限的mCachedViews中如果存不下ViewHolder時，就會把ViewHolder存入RecyclerViewPool中。
* 按照Type來查找ViewHolder
* 每個Type默認最多緩存5個
RecycledViewPool 會根據每個ViewType把ViewHolder分別存儲在不同的列表中，每個ViewType最多緩存DEFAULT_MAX_SCRAP = 5 個ViewHolder，如果RecycledViewPool沒有被多個RecycledView共享，對於線性布局，每個ViewType最多隻有一個緩存，如果是網格有多少行就緩存多少個。
Recyclerview在獲取ViewHolder時按四級緩存的順序查找，如果沒找到就創建。其中只有RecycledViewPool找到時才會調用 bindViewHolder，其它緩存不會重新bindViewHolder 。
通過了解RecyclerView的四級緩存，我們可以知道，RecyclerView最多可以緩存 N（屏幕最多可顯示的item數） + 2 (屏幕外的緩存) + 5*M (M代表M個ViewType，緩存池的緩存)，只有RecycledViewPool找到時才會重新調用 bindViewHolder。
RecyclerView在Recyler裡面實現ViewHolder的緩存，Recycler裡面的實現緩存的主要包含以下5個對象：
RecyclerView在設計的時候講上述5個緩存對象分為了3級。
每次創建ViewHolder的時候，會按照優先順序依次查詢緩存創建ViewHolder 。
三級緩存分別是：
RecyclerView緩存原理，有圖有真相
關於Recyclerview的緩存機制的理解
❾ mysql緩存機制怎麼查看有沒有啟動
MySQL緩存機制簡單的說就是緩存sql文本及查詢結果，如果運行相同的sql，伺服器直接從緩存中取到結果，而不需要再去解析和執行sql。如果表更改 了，那麼使用這個表的所有緩沖查詢將不再有效，查詢緩存值的相關條目被清空。更改指的是表中任何數據或是結構的改變，包括INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改變了的表的使用MERGE表的查詢。顯然，這對於頻繁更新的表，查詢緩存是不適合的，而對於一些不常改變數據且有 大量相同sql查詢的表，查詢緩存會節約很大的性能。
命中條件
緩存存在一個hash表中,通過查詢SQL,查詢資料庫,客戶端協議等作為key.在判斷是否命中前,MySQL不會解析SQL,而是直接使用SQL去查詢緩存,SQL任何字元上的不同,如空格,注釋,都會導致緩存不命中.
如果查詢中有不確定數據,例如CURRENT_DATE()和NOW()函數,那麼查詢完畢後則不會被緩存.所以,包含不確定數據的查詢是肯定不會找到可用緩存的
工作流程
1. 伺服器接收SQL,以SQL和一些其他條件為key查找緩存表(額外性能消耗)
2. 如果找到了緩存,則直接返回緩存(性能提升)
3. 如果沒有找到緩存,則執行SQL查詢,包括原來的SQL解析,優化等.
4. 執行完SQL查詢結果以後,將SQL查詢結果存入緩存表(額外性能消耗)
緩存失效
當某個表正在寫入數據,則這個表的緩存(命中檢查,緩存寫入等)將會處於失效狀態.在Innodb中,如果某個事務修改了表,則這個表的緩存在事務提交前都會處於失效狀態,在這個事務提交前,這個表的相關查詢都無法被緩存.
緩存的內存管理
緩存會在內存中開辟一塊內存(query_cache_size)來維護緩存數據,其中有大概40K的空間是用來維護緩存的元數據的,例如空間內存,數據表和查詢結果的映射,SQL和查詢結果的映射等.
MySQL將這個大內存塊分為小的內存塊(query_cache_min_res_unit),每個小塊中存儲自身的類型,大小和查詢結果數據,還有指向前後內存塊的指針.
MySQL需要設置單個小存儲塊的大小,在SQL查詢開始(還未得到結果)時就去申請一塊空間,所以即使你的緩存數據沒有達到這個大小,也需要用這個大小的數據塊去存(這點跟Linux文件系統的Block一樣).如果結果超出這個內存塊的大小,則需要再去申請一個內存塊.當查詢完成發現申請的內存塊有富餘,則會將富餘的空間釋放掉,這就會造成內存碎片問題,見下圖
此處查詢1和查詢2之間的空白部分就是內存碎片,這部分空閑內存是有查詢1查詢完以後釋放的,假設這個空間大小小於MySQL設定的內存塊大小,則無法再被使用,造成碎片問題
在查詢開始時申請分配內存Block需要鎖住整個空閑內存區,所以分配內存塊是非常消耗資源的.注意這里所說的分配內存是在MySQL初始化時就開辟的那塊內存上分配的.
緩存的使用時機
衡量打開緩存是否對系統有性能提升是一個很難的話題
1. 通過緩存命中率判斷, 緩存命中率 = 緩存命中次數 (Qcache_hits) / 查詢次數 (Com_select)
2. 通過緩存寫入率, 寫入率 = 緩存寫入次數 (Qcache_inserts) / 查詢次數 (Qcache_inserts)
3. 通過 命中-寫入率 判斷, 比率 = 命中次數 (Qcache_hits) / 寫入次數 (Qcache_inserts), 高性能MySQL中稱之為比較能反映性能提升的指數,一般來說達到3:1則算是查詢緩存有效,而最好能夠達到10:1
緩存配置參數
1. query_cache_type: 是否打開緩存
可選項
1) OFF: 關閉
2) ON: 總是打開
3) DEMAND: 只有明確寫了SQL_CACHE的查詢才會吸入緩存
2. query_cache_size: 緩存使用的總內存空間大小,單位是位元組,這個值必須是1024的整數倍,否則MySQL實際分配可能跟這個數值不同(感覺這個應該跟文件系統的blcok大小有關)
3. query_cache_min_res_unit: 分配內存塊時的最小單位大小
4. query_cache_limit: MySQL能夠緩存的最大結果,如果超出,則增加 Qcache_not_cached的值,並刪除查詢結果
5. query_cache_wlock_invalidate: 如果某個數據表被鎖住,是否仍然從緩存中返回數據,默認是OFF,表示仍然可以返回
GLOBAL STAUS 中 關於 緩存的參數解釋:
Qcache_free_blocks: 緩存池中空閑塊的個數
Qcache_free_memory: 緩存中空閑內存量
Qcache_hits: 緩存命中次數
Qcache_inserts: 緩存寫入次數
Qcache_lowmen_prunes: 因內存不足刪除緩存次數
Qcache_not_cached: 查詢未被緩存次數,例如查詢結果超出緩存塊大小,查詢中包含可變函數等
Qcache_queries_in_cache: 當前緩存中緩存的SQL數量
Qcache_total_blocks: 緩存總block數
減少碎片策略
1. 選擇合適的block大小
2. 使用 FLUSH QUERY CACHE 命令整理碎片.這個命令在整理緩存期間,會導致其他連接無法使用查詢緩存
PS: 清空緩存的命令式 RESET QUERY CACHE