不羨鴛鴦不羨仙，一行代碼調半天。原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。
緩存，在高併發的應用中，用的那是相當多。爲什麼？就因爲I/O實在是慢！爲了解決不同組件之間的速度差，大家都寄希望於加入一箇中間層，期待產生一些魔幻的事。
就拿Redis來說，火的就一塌糊塗，但中間會產生很多數據同步和數據一致性問題。有的牛x公司嫌煩，同時有錢，乾脆幹掉緩存後面的DB，直接把所有的數據放在了緩存上。哦不，這時候緩存已經不叫做緩存，應該叫做快存，因爲它最終是要通過rdb落地的。
看到這裏，先不要懷疑事實的正確性。有些公司的業務，確實不需要什麼關係型數據庫，一個redis就能玩得轉。
閃電緩存場景
那閃電緩存又是何方神聖？實在不好意思， 這個名詞，是xjjdog自創的。
它用在下面的場景之中。
一份數據，通過耗時的請求獲取之後，會在極短的時間內，再次被用到。
業務對數據的一致性要求不是特別強烈，但也不是無底線忍受。
內存的空間有限，不適合把大量數據放在內存中。
數據的使用跨方法、跨代碼塊、甚至跨線程，只在時間概念上有關聯
這個時候，我們就可以將數據緩存一小段時間，儘量在下次的使用的時候，從這個時間極短的緩存中獲取。
srping-data-jpa背後的Hibernate一級緩存，在同一session下的數據被自動緩存，可以變相的看作是閃電緩存的一種實現。不過人家叫一級緩存，顯得更高大上一些，應用也更侷限一些。
Java有多種緩存數據的方法，也有不同的生命週期。你可以想一下Session中的數據該如何存取，也可以想一下Java框架中各種各樣的Context，都是爲了共享數據。
實現方式
閃電緩存，在Java中其實是有多種方式的，也有各種各樣的優缺點。
ThreadLocal
第一種方式，就是ThreadLocal。拿最常用的Spring來說，它事務管理的傳播機制，就是使用ThreadLocal實現的。
我可以在數據第一次被獲取的時候，使用set方法給它設置一個值。然後在最後一個操作用的使用，把它remove掉，變相的實現請求級別的閃電緩存。（爲什麼要remove？因爲在線程池中可能會有複用的問題）
但由於ThreadLocal是線程私有的，所以它不能夠跨線程。上面Spring的事務傳播機制是不能夠跨線程的，我們的閃電緩存也是不能夠跨線程的。
要想做到線程透傳，也不是不可能。可以參照xjjdog以前的一篇文章。