guava緩存
A. 常用的緩存技術
第一章 常用的緩存技術
1、常見的兩種緩存
本地緩存：不需要序列化，速度快，緩存的數量與大小受限於本機內存
分布式緩存：需要序列化，速度相較於本地緩存較慢，但是理論上緩存的數量與大小無限（因為緩存機器可以不斷擴展）
2、本地緩存
Google guava cache：當下最好用的本地緩存
Ehcache：spring默認集成的一個緩存，以spring cache的底層緩存實現類形式去操作緩存的話，非常方便，但是欠缺靈活，如果想要靈活使用，還是要單獨使用Ehcache
Oscache：最經典簡單的頁面緩存
3、分布式緩存
memcached：分布式緩存的標配
Redis：新一代的分布式緩存，有替代memcached的趨勢
3.1、memcached
經典的一致性hash演算法
基於slab的內存模型有效防止內存碎片的產生（但同時也需要估計好啟動參數，否則會浪費很多的內存）
集群中機器之間互不通信（相較於Jboss cache等集群中機器之間的相互通信的緩存，速度更快<--因為少了同步更新緩存的開銷，且更適合於大型分布式系統中使用）
使用方便（這一點是相較於Redis在構建客戶端的時候而言的，盡管redis的使用也不困難）
很專一（專做緩存，這一點也是相較於Redis而言的）
3.2、Redis
可以存儲復雜的數據結構（5種）
strings-->即簡單的key-value，就是memcached可以存儲的唯一的一種形式，接下來的四種是memcached不能直接存儲的四種格式（當然理論上可以先將下面的一些數據結構中的東西封裝成對象，然後存入memcached，但是不推薦將大對象存入memcached，因為memcached的單一value的最大存儲為1M，可能即使採用了壓縮演算法也不夠，即使夠，可能存取的效率也不高，而redis的value最大為1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事實上底層是一個hashTable
sorted sets-->底層是一個skipList
有兩種方式可以對緩存數據進行持久化
RDB
AOF
事件調度
發布訂閱等
4、集成緩存
專指spring cache，spring cache自己繼承了ehcache作為了緩存的實現類，我們也可以使用guava cache、memcached、redis自己來實現spring cache的底層。當然，spring cache可以根據實現類來將緩存存在本地還是存在遠程機器上。
5、頁面緩存
在使用jsp的時候，我們會將一些復雜的頁面使用Oscache進行頁面緩存，使用非常簡單，就是幾個標簽的事兒；但是，現在一般的企業，前台都會使用velocity、freemaker這兩種模板引擎，本身速度就已經很快了，頁面緩存使用的也就很少了。
總結：
在實際生產中，我們通常會使用guava cache做本地緩存+redis做分布式緩存+spring cache就集成緩存（底層使用redis來實現）的形式
guava cache使用在更快的獲取緩存數據，同時緩存的數據量並不大的情況
spring cache集成緩存是為了簡單便捷的去使用緩存（以註解的方式即可），使用redis做其實現類是為了可以存更多的數據在機器上
redis緩存單獨使用是為了彌補spring cache集成緩存的不靈活
就我個人而言，如果需要使用分布式緩存，那麼首先redis是必選的，因為在實際開發中，我們會緩存各種各樣的數據類型，在使用了redis的同時，memcached就完全可以舍棄了，但是現在還有很多公司在同時使用memcached和redis兩種緩存。
B. guava的LoadingCache的默認大小和生命周期是多少
當Session對象為空，Session對象的生命周期還沒有開始，Session ID Manager會為每一個請求頁面賦予一個新的session ID，且每一次請求都不相同，直到有數據存儲在Session對象中時，就按照圖2所示的過程進行會話狀態維護。有兩個事件與Session對象的生命周期密切相關，分別是Session_OnStart（會話開始）和Session_OnEnd（會話結束）。如果為Session_OnStart事件定義了處理程序（event handler），那麼Session的生命周期從第一次請求該頁面就開始，該頁面的Session ID一被賦予就不再改變，Session即使為空也會被存儲，因此，從性能的角度考慮，只有在必要時才為Session_OnStart事件定義事件處理程序。Session_OnEnd事件只有在InProc模式下，且Session已經存在的前提下才能被觸發，這是因為該事件是由Cache對象在刪除失效的Session對象時觸發，可在該事件的處理程序中通過編碼終止Session對象。
最後，再補充一點。由上面的討論可知，Session 對象的實現與Cache對象有著密切聯系，尤其是再InProc模式下，但是Session不能提供和Cache那樣豐富的緩存過期和依賴機制。在InProc模式下，Session對象中的數據是否失效，只能通過設定sliding time來控制，即在指定的時間間隔內沒用使用Session中的數據，數據自動刪除。
C. java google 的內存緩存為什麼總調用cacheloader
首先，看一下使用範例：
Java代碼
LoadingCache<Key,Graph> graphs =CacheBuilder.newBuilder()
.maximumSize(1000)
.expireAfterWrite(10,TimeUnit.MINUTES)
.removalListener(MY_LISTENER)
.build(
newCacheLoader<Key,Graph>(){
publicGraph load(Key key)throwsAnyException{
return createExpensiveGraph(key);
}
});
適用性
緩存在很多情況下都是非常有用的。比如，我們需要多次根據給定的輸入獲取值，而且該值計算或者獲取的開銷是非常昂貴的。
緩存和ConcurrentMap是非常相像的，但是它們也不完全一樣。最根本的區別就是，ConcurrentMap會持有所有添加的對象，直到被顯示的移除。而緩存為了限制其內存的使用，通常都會配置成可以自動的將對象移除。在某些情況下即使不自動移除對象也是非常有用的，如LoadingCache它會自動載入緩存對象。
一般，Guava緩存適用於以下幾種情況：
你願意花費一些內存來換取性能提升；
你預測到某些鍵會多次進行查詢；
你的緩存數據不超過內存（Guava緩存是單個應用中的本地緩存。它不會將數據存儲到文件中，或者外部伺服器。如果不適合你，可以考慮一下 Memcached）。
如果你的需要符合上面所說的每一條，那麼選擇Guava緩存絕對沒錯。
使用CacheBuilder的構建模式可以獲取一個Cache，如上面的範例所示。但是如何進行定製才是比較有趣的。
注意：如果你不需要緩存的這些特性，那麼使用ConcurrentHashMap會有更好的內存效率，但是如果想基於舊有的ConcurrentMap復制實現Cache的一些特性，那麼可能是非常困難或者根本不可能。
載入
對於緩存首先需要明確的是：有沒有一個方法可以通過給定的鍵來計算/載入相應的值？如果有，那麼可以使用CacheLoader。如果沒有這樣的方法，或者你想復寫緩存的載入方式，但你仍想保留「get-if-absent-compute」語義，你可以在調用get方法時傳入一個Callable實例，來達到目的。緩存的對象可以通過Cache.put直接插入，但是自動載入是首選，因為自動載入可以更加容易的判斷所有緩存信息的一致性。
From a CacheLoader
LoadingCache 緩存是通過一個CacheLoader來構建緩存。創建一個CacheLoader僅需要實現V load(K key) throws Exception方法即可。下面的範例就是如何創建一個LoadingCache：
Java代碼
LoadingCache<Key,Graph> graphs =CacheBuilder.newBuilder()
.maximumSize(1000)
.build(
newCacheLoader<Key,Graph>(){
publicGraph load(Key key)throwsAnyException{
return createExpensiveGraph(key);
}
});
...
try{
return graphs.get(key);
}catch(ExecutionException e){
thrownewOtherException(e.getCause());
}
通過方法get(K)可以對LoadingCache進行查詢。該方法要不返回已緩存的值，要不通過CacheLoader來自動載入相應的值到緩存中。這里需要注意的是：CacheLoader可能會拋出Exception，LoaderCache.get(K)則可能會拋出ExecutionException。假如你定義的CacheLoader沒有聲明檢查型異常，那麼可以通過調用getUnchecked(K)來獲取緩存值；但是一旦當CacheLoader中聲明了檢查型異常，則不可以調用getUnchecked。
Java代碼
LoadingCache<Key,Graph> graphs =CacheBuilder.newBuilder()
.expireAfterAccess(10,TimeUnit.MINUTES)
.build(
newCacheLoader<Key,Graph>(){
publicGraph load(Key key){// no checked exception
return createExpensiveGraph(key);
}
});
...
return graphs.getUnchecked(key);
批量查詢可以使用getAll(Iterable<? extends K>)方法。預設，getAll方法將循環每一個鍵調用CacheLoader.load方法獲取緩存值。當緩存對象的批量獲取比單獨獲取更有效時，可以通過復寫CacheLoader.loadAll方法實現緩存對象的載入。此時當調用getAll(Iterable)方法時性能也會提升。
需要注意的是CacheLoader.loadAll的實現可以為沒有明確要求的鍵載入緩存值。比如，當為某組中的一些鍵進行計算時，loadAll方法則可能會同時載入組中其餘鍵的值。
From a Callable
所有Guava緩存，不論是否會自動載入，都支持get(K, Callable(V))方法。當給定鍵的緩存值已存在時則直接返回，否則通過指定的Callable方法進行計算並將值存放到緩存中。直到載入完成時，相應的緩存才會被更改。該方法簡單實現了"if cached, return; otherwise create, cache and return"語義。
Java代碼
Cache<Key,Value> cache =CacheBuilder.newBuilder()
.maximumSize(1000)
.build();// look Ma, no CacheLoader
...
try{
// If the key wasn't in the "easy to compute" group, we need to
// do things the hard way.
cache.get(key,newCallable<Value>(){
@Override
publicValue call()throwsAnyException{
return doThingsTheHardWay(key);
}
});
}catch(ExecutionException e){
thrownewOtherException(e.getCause());
}
直接插入
使用cache.put(key, value)方法可以將值直接插入到緩存中，但這將會覆蓋緩存中已存在的值。通過使用Cache.asMap()所導出的ConcurrentMap對象中的方法也可以對緩存進行修改。但是，請注意asMap中的任何方法都不能自動的將數據載入到緩存中。也就是說，asMap中的各方法是在緩存自動載入范圍之外來運作。所以，當你使用CacheLoader或Callable來載入緩存時，應該優先使用Cache.get(K, Callable<V>)，而不是Cache.asMap().putIfAbsent。
緩存回收
殘酷的現實是我們可以肯定的說我們沒有足夠的內存來緩存一切。你必須來決定：什麼時候緩存值不再值得保留？Guava提供了三種基本的緩存回收策略：基於容量回收策略，基於時間回收策略，基於引用回收策略。
基於容量回收策略
使用CacheBuilder.maximumSize(long)可以設置緩存的最大容量。緩存將會嘗試回收最近沒有使用，或者沒有經常使用的緩存項。警告：緩存可能會在容量達到限制之前執行回收，通常是在緩存大小逼近限制大小時。
另外，如果不同的緩存項有不同的「權重」， 如，緩存項有不同的內存佔用，此時你需要使用CacheBuilder.weigher(Weigher)指定一個權重計算函數，並使用CacheBuilder.maxmumWeight(long)設定總權重。和maximumSize同樣需要注意的是緩存也是在逼近總權重的時候進行回收處理。此外，緩存項的權重是在創建時進行計算，此後不再改變。
Java代碼
LoadingCache<Key,Graph> graphs =CacheBuilder.newBuilder()
.maximumWeight(100000)
.weigher(
newWeigher<Key,Graph>(){
publicint weigh(Key k,Graph g){
return g.vertices().size();
}
})
.build(
newCacheLoader<Key,Graph>(){
publicGraph load(Key key){// no checked exception
return createExpensiveGraph(key);
}
});
基於時間回收策略
CacheBuilder為基於時間的回收提供了兩種方式：
expireAfterAccess(long, TimeUnit) 當緩存項在指定的時間段內沒有被讀或寫就會被回收。這種回收策略類似於基於容量回收策略；
expireAfterWrite(long, TimeUnit) 當緩存項在指定的時間段內沒有更新就會被回收。如果我們認為緩存數據在一段時間後數據不再可用，那麼可以使用該種策略。
就如下面的討論，定時過期回收會在寫的過程中周期執行，偶爾也會讀的過程中執行。
測試定時回收
測試定時回收其實不需要那麼痛苦的，我們不必非得花費2秒來測試一個2秒的過期。在構建緩存時使用Ticker介面，並通過CacheBuilder.ticker(Ticker)方法指定時間源，這樣我們就不用傻乎乎等系統時鍾慢慢的走了。
基於引用回收策略
通過鍵或緩存值的弱引用(weak references)，或者緩存值的軟引用(soft references)，Guava可以將緩存設置為允許垃圾回收。
CacheBuilder.weakKeys() 使用弱引用存儲鍵。當沒有(強或軟)引用到該鍵時，相應的緩存項將可以被垃圾回收。由於垃圾回收是依賴==進行判斷，因此這樣會導致整個緩存也會使用==來比較鍵的相等性，而不是使用equals()；
CacheBuilder.weakValues() 使用弱引用存儲緩存值。當沒有(強或軟)引用到該緩存項時，將可以被垃圾回收。由於垃圾回收是依賴==進行判斷，因此這樣會導致整個緩存也會使用==來比較緩存值的相等性，而不是使用equals()；
CacheBuilder.softValues() 使用軟引用存儲緩存值。當響應需要時，軟引用才會被垃圾回收通過最少使用原則回收掉。由於使用軟引用造成性能上的影響，我們強烈建議使用可被預言的maximum cache size的策略來代替。同樣使用softValues()緩存值的比較也是使用==，而不是equals()。
顯示移除
在任何時候，你都可以可以通過下面的方法顯式將無效的緩存移除，而不是被動等待被回收：
使用Cache.invalidate(key)單個移除;
使用Cache.invalidteAll(keys)批量移除；
使用Cache.invalidateAll()移除全部。
D. guava cache中怎麼清除緩存
【手動清理】
1、進入手機設置選項，選擇 設置——應用 。
2、 按一下Menu鍵，選擇「按大小排序」。
3、在排序好的列表中點擊應用程序。
4、點擊"清除緩存"選項，即刻就會釋放緩存
E. Google guava和Apache commons哪個好
Guava 的 FAQ 部分有專門解答：
Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?
The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically.
An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen.
Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.
簡單地說：
Apache Commons Collections 3.x 不支持泛型，Guava 支持
Guava 實現了 JDK 的標准介面，而 Apache Commons Collections 3.x 有很多違反標準的地方
Apache Commons Collections 4.x 的發行注記如下：
Majorchangessince3.2.1
(varargs,Iterable)
Removeddeprecatedclasses/
.util.Queue
/Get(seealsopackagesplitmap)
從 4.x 開始，Apache Commons Collections 開始使用 JDK 5 的特性（包括泛型），此外也去除、添加了很多內容
各有千秋, 我主要使用Apache Commons ,輔助使用 Google guava
但是細節方法上還是有區別的, 比如
GoogleGuava Splitter 對比 Apache StringUtils
apache commons的StringUtils提供的常用功能介紹，但是google的guava也提供了一些字元串處理的常見功能，所以，將對兩者的字元串分割函數做一次比較詳細的對比（結果比較surprise）。
區別
首先看基本的使用方法：
//ApacheStringUtils...
String[]tokens1=StringUtils.split("one,two,three",',');
//GoogleGuavasplitter...
Iteratable<String>tokens2=Splitter.on(','),split("one,two,three");
google提供的方法更加的面向對象一點，因為它要先創建一個Splitter對象，然後使用它來分割字元串，而apache的方法則有點函數式編程的味道，它的方法都是靜態的。
這里我更加傾向於採用google的splitter，因為這個對象是可以重用的，且可以在其上附加更多的功能，比如trim，去掉空的元素等，一切都很簡單。
SplitterniceCommaSplitter=Splitter.on(',').omitEmptyString().trimResults();
niceCommaSplitter.split("one,,two,three");//"one","two","three"
niceCommaSplitter.split("four,five");//"four","five"
看起來有點用，還有其他區別么？
另外一個需要注意的地方就是Splitter返回的是Iteratable<String>，而StringUtils.split返回的是一個String數組。
大部分使用分隔符的情況是我們需要對字元串按照分隔符進行遍歷處理，僅此而已。
下面就是常用的代碼性能對比的例子：
finalStringnumberList="One,Two,Three,Four,Five,Six,Seven,Eight,Nine,Ten";
longstart=System.currentTimeMillis();
for(inti=0;i<1000000;i++){
StringUtils.split(numberList,',');
}
System.out.println(System.currentTimeMillis()-start);
start=System.currentTimeMillis();
for(inti=0;i<1000000;i++){
Splitter.on(',').split(numberList);
}
System.out.println(System.currentTimeMillis()-start);
代碼很簡單，就是都對同一個字元串進行100萬次的分隔操作，看看時間上的區別，結果如下：
983
165
很明顯，guava的速度快很多，這個程序如果運行在每天處理大量字元串的服務中，那麼性能差異更加明顯。我想其中的原因是Splitter返回的是Iterable<String>，而StringUtils.split返回的是一個String[]，需要創建新的String對象，導致耗時增加。
如果我們對Splitter對象緩存，那麼速度提高更多：
start=System.currentTimeMillis();
Splitters=Splitter.on(',');
for(inti=0;i<1000000;i++){
s.split(numberList);
}
System.out.println(System.currentTimeMillis()-start);
結果為12，神奇吧，呵呵
F. 關閉內存緩存對效能有影響嗎
沒有。
在系統中所有的進程之間是共享CPU和主存這些內存資源的。當進程數量變多時，所需要的內存資源就會相應的增加。可能會導致部分程序沒有主存空間可用。此外，由於資源是共享的，那麼就有可能導致某個進程不小心寫了另一個進程所使用的內存，進而導致程序運行不符合正常邏輯。
內存緩存注意事項
使用Java堆內存來存儲對象。使用堆緩存的好處是沒有序列化/反序列化，是最快的緩存。缺點也很明顯，當緩存的數據量很大時，GC（垃圾回收）暫停時間會變長，存儲容量受限於堆空間大小。一般通過軟引用/弱引用來存儲緩存對象。
即當堆內存不足時，可以強制回收這部分內存釋放堆內存空間。一般使用堆緩存存儲較熱的數據。可以使用Guava Cache、Ehcache 3.x、 MapDB實現。
G. JAVA目前比較常用的緩存有哪些 集中式緩存與分布式緩存有何區別 它們應用場景是
java目前常用的緩存：
Generic
JCache (JSR-107) (EhCache 3, Hazelcast, Infinispan, etc)
EhCache 2.x
Hazelcast
Infinispan
Couchbase
Redis
Caffeine
Guava (deprecated)
Simple
建議使用spring boot集成方式，可插拔，簡單。
集中式緩存適用場景：
1、伺服器集群部署。
2、數據高一致性（任何數據變化都能及時的被查詢到）
分布式緩存適用場景：
系統需要緩存的數據量大
對數據的可用性較高的情況
需要橫向擴展，從而達到緩存的容量無限的要求
H. 為什麼要用 redis 而不用 map/guava 做緩存
因為前置款存的話要好一點，而且實用性要高一點。
I. 如何使用Guava的緩存管理
首先，看一下使用範例： Java代碼 LoadingCache<Key,Graph> graphs =CacheBuilder.newBuilder() .maximumSize(1000) .expireAfterWrite(10,TimeUnit.MINUTES) .removalListener(MY_LISTENER) .build( newCacheLoader<Key,Graph>(){ publicGraph load(Key key)throwsAnyException{ return createExpensiveGraph(key); } }); 適用性 緩存在很多情況下都是非常有用的。比如，我們需要多次根據給定的輸入獲取值，而且該值計算或者獲取的開銷是非常昂貴的。 緩存和ConcurrentMap是非常相像的，但是它們也不完全一樣。最根本的區別就是，ConcurrentMap會持有所有添加的對象，直到被顯示的移除。而緩存為了限制其內存的使用，通常都會配置成可以自動的將對象移除。在某些情況下即使不自動移除對象也是非常有用的，如LoadingCache它會自動載入緩存對象。 一般，Guava緩存適用於以下幾種情況： 你願意花費一些內存來換取性能提升； 你預測到某些鍵會多次進行查詢； 你的緩存數據不超過內存（Guava緩存是單個應用中的本地緩存。它不會將數據存儲到文件中，或者外部服...