A. java內存模型的JMM簡介
1)JSR133：
在Java語言規范裡面指出了JMM是一個比較開拓性的嘗試，這種嘗試視圖定義一個一致的、跨平台的內存模型，但是它有一些比較細微而且很重要的缺點。其實Java語言裡面比較容易混淆的關鍵字主要是synchronized和volatile，也因為這樣在開發過程中往往開發者會忽略掉這些規則，這也使得編寫同步代碼比較困難。
JSR133本身的目的是為了修復原本JMM的一些缺陷而提出的，其本身的制定目標有以下幾個： 保留目JVM的安全保證，以進行類型的安全檢查： 提供（out-of-thin-air safety）無中生有安全性，這樣「正確同步的」應該被正式而且直觀地定義 程序員要有信心開發多線程程序，當然沒有其他辦法使得並發程序變得很容易開發，但是該規范的發布主要目標是為了減輕程序員理解內存模型中的一些細節負擔 提供大范圍的流行硬體體系結構上的高性能JVM實現，現在的處理器在它們的內存模型上有著很大的不同，JMM應該能夠適合於實際的盡可能多的體系結構而不以性能為代價，這也是Java跨平台型設計的基礎 提供一個同步的習慣用法，以允許發布一個對象使他不用同步就可見，這種情況又稱為初始化安全（initialization safety）的新的安全保證 對現有代碼應該只有最小限度的影響 2)同步、非同步【這里僅僅指概念上的理解，不牽涉到計算機底層基礎的一些操作】：
在系統開發過程，經常會遇到這幾個基本概念，不論是網路通訊、對象之間的消息通訊還是Web開發人員常用的Http請求都會遇到這樣幾個概念，經常有人提到Ajax是非同步通訊方式，那麼究竟怎樣的方式是這樣的概念描述呢？
同步：同步就是在發出一個功能調用的時候，在沒有得到響應之前，該調用就不返回，按照這樣的定義，其實大部分程序的執行都是同步調用的，一般情況下，在描述同步和非同步操作的時候，主要是指代需要其他部件協作處理或者需要協作響應的一些任務處理。比如有一個線程A，在A執行的過程中，可能需要B提供一些相關的執行數據，當然觸發B響應的就是A向B發送一個請求或者說對B進行一個調用操作，如果A在執行該操作的時候是同步的方式，那麼A就會停留在這個位置等待B給一個響應消息，在B沒有任何響應消息回來的時候，A不能做其他事情，只能等待，那麼這樣的情況，A的操作就是一個同步的簡單說明。
非同步：非同步就是在發出一個功能調用的時候，不需要等待響應，繼續進行它該做的事情，一旦得到響應了過後給予一定的處理，但是不影響正常的處理過程的一種方式。比如有一個線程A，在A執行的過程中，同樣需要B提供一些相關數據或者操作，當A向B發送一個請求或者對B進行調用操作過後，A不需要繼續等待，而是執行A自己應該做的事情，一旦B有了響應過後會通知A，A接受到該非同步請求的響應的時候會進行相關的處理，這種情況下A的操作就是一個簡單的非同步操作。
3)可見性、可排序性
Java內存模型的兩個關鍵概念：可見性（Visibility）和可排序性（Ordering）
開發過多線程程序的程序員都明白，synchronized關鍵字強制實施一個線程之間的互斥鎖（相互排斥），該互斥鎖防止每次有多個線程進入一個給定監控器所保護的同步語句塊，也就是說在該情況下，執行程序代碼所獨有的某些內存是獨占模式，其他的線程是不能針對它執行過程所獨占的內存進行訪問的，這種情況稱為該內存不可見。但是在該模型的同步模式中，還有另外一個方面：JMM中指出了，JVM在處理該強制實施的時候可以提供一些內存的可見規則，在該規則裡面，它確保當存在一個同步塊時，緩存被更新，當輸入一個同步塊時，緩存失效。因此在JVM內部提供給定監控器保護的同步塊之中，一個線程所寫入的值對於其餘所有的執行由同一個監控器保護的同步塊線程來說是可見的，這就是一個簡單的可見性的描述。這種機器保證編譯器不會把指令從一個同步塊的內部移到外部，雖然有時候它會把指令由外部移動到內部。JMM在預設情況下不做這樣的保證——只要有多個線程訪問相同變數時必須使用同步。簡單總結：
可見性就是在多核或者多線程運行過程中內存的一種共享模式，在JMM模型裡面，通過並發線程修改變數值的時候，必須將線程變數同步回主存過後，其他線程才可能訪問到。
可排序性提供了內存內部的訪問順序，在不同的程序針對不同的內存塊進行訪問的時候，其訪問不是無序的，比如有一個內存塊，A和B需要訪問的時候，JMM會提供一定的內存分配策略有序地分配它們使用的內存，而在內存的調用過程也會變得有序地進行，內存的折中性質可以簡單理解為有序性。而在Java多線程程序裡面，JMM通過Java關鍵字volatile來保證內存的有序訪問。 1)簡單分析：
Java語言規范中提到過，JVM中存在一個主存區（Main Memory或Java Heap Memory），Java中所有變數都是存在主存中的，對於所有線程進行共享，而每個線程又存在自己的工作內存（Working Memory），工作內存中保存的是主存中某些變數的拷貝，線程對所有變數的操作並非發生在主存區，而是發生在工作內存中，而線程之間是不能直接相互訪問，變數在程序中的傳遞，是依賴主存來完成的。而在多核處理器下，大部分數據存儲在高速緩存中，如果高速緩存不經過內存的時候，也是不可見的一種表現。在Java程序中，內存本身是比較昂貴的資源，其實不僅僅針對Java應用程序，對操作系統本身而言內存也屬於昂貴資源，Java程序在性能開銷過程中有幾個比較典型的可控制的來源。synchronized和volatile關鍵字提供的內存中模型的可見性保證程序使用一個特殊的、存儲關卡（memory barrier）的指令，來刷新緩存，使緩存無效，刷新硬體的寫緩存並且延遲執行的傳遞過程，無疑該機制會對Java程序的性能產生一定的影響。
JMM的最初目的，就是為了能夠支持多線程程序設計的，每個線程可以認為是和其他線程不同的CPU上運行，或者對於多處理器的機器而言，該模型需要實現的就是使得每一個線程就像運行在不同的機器、不同的CPU或者本身就不同的線程上一樣，這種情況實際上在項目開發中是常見的。對於CPU本身而言，不能直接訪問其他CPU的寄存器，模型必須通過某種定義規則來使得線程和線程在工作內存中進行相互調用而實現CPU本身對其他CPU、或者說線程對其他線程的內存中資源的訪問，而表現這種規則的運行環境一般為運行該程序的運行宿主環境（操作系統、伺服器、分布式系統等），而程序本身表現就依賴於編寫該程序的語言特性，這里也就是說用Java編寫的應用程序在內存管理中的實現就是遵循其部分原則，也就是前邊提及到的JMM定義了Java語言針對內存的一些的相關規則。然而，雖然設計之初是為了能夠更好支持多線程，但是該模型的應用和實現當然不局限於多處理器，而在JVM編譯器編譯Java編寫的程序的時候以及運行期執行該程序的時候，對於單CPU的系統而言，這種規則也是有效的，這就是是上邊提到的線程和線程之間的內存策略。JMM本身在描述過程沒有提過具體的內存地址以及在實現該策略中的實現方法是由JVM的哪一個環節（編譯器、處理器、緩存控制器、其他）提供的機制來實現的，甚至針對一個開發非常熟悉的程序員，也不一定能夠了解它內部對於類、對象、方法以及相關內容的一些具體可見的物理結構。相反，JMM定義了一個線程與主存之間的抽象關系，其實從上邊的圖可以知道，每一個線程可以抽象成為一個工作內存（抽象的高速緩存和寄存器），其中存儲了Java的一些值，該模型保證了Java裡面的屬性、方法、欄位存在一定的數學特性，按照該特性，該模型存儲了對應的一些內容，並且針對這些內容進行了一定的序列化以及存儲排序操作，這樣使得Java對象在工作內存裡面被JVM順利調用，（當然這是比較抽象的一種解釋）既然如此，大多數JMM的規則在實現的時候，必須使得主存和工作內存之間的通信能夠得以保證，而且不能違反內存模型本身的結構，這是語言在設計之處必須考慮到的針對內存的一種設計方法。這里需要知道的一點是，這一切的操作在Java語言裡面都是依靠Java語言自身來操作的，因為Java針對開發人員而言，內存的管理在不需要手動操作的情況下本身存在內存的管理策略，這也是Java自己進行內存管理的一種優勢。
[1]原子性（Atomicity）：
這一點說明了該模型定義的規則針對原子級別的內容存在獨立的影響，對於模型設計最初，這些規則需要說明的僅僅是最簡單的讀取和存儲單元寫入的的一些操作，這種原子級別的包括——實例、靜態變數、數組元素，只是在該規則中不包括方法中的局部變數。
[2]可見性（Visibility）：
在該規則的約束下，定義了一個線程在哪種情況下可以訪問另外一個線程或者影響另外一個線程，從JVM的操作上講包括了從另外一個線程的可見區域讀取相關數據以及將數據寫入到另外一個線程內。
[3]可排序性（Ordering）：
該規則將會約束任何一個違背了規則調用的線程在操作過程中的一些順序，排序問題主要圍繞了讀取、寫入和賦值語句有關的序列。
如果在該模型內部使用了一致的同步性的時候，這些屬性中的每一個屬性都遵循比較簡單的原則：和所有同步的內存塊一樣，每個同步塊之內的任何變化都具備了原子性以及可見性，和其他同步方法以及同步塊遵循同樣一致的原則，而且在這樣的一個模型內，每個同步塊不能使用同一個鎖，在整個程序的調用過程是按照編寫的程序指定指令運行的。即使某一個同步塊內的處理可能會失效，但是該問題不會影響到其他線程的同步問題，也不會引起連環失效。簡單講：當程序運行的時候使用了一致的同步性的時候，每個同步塊有一個獨立的空間以及獨立的同步控制器和鎖機制，然後對外按照JVM的執行指令進行數據的讀寫操作。這種情況使得使用內存的過程變得非常嚴謹！
如果不使用同步或者說使用同步不一致（這里可以理解為非同步，但不一定是非同步操作），該程序執行的答案就會變得極其復雜。而且在這樣的情況下，該內存模型處理的結果比起大多數程序員所期望的結果而言就變得十分脆弱，甚至比起JVM提供的實現都脆弱很多。因為這樣所以出現了Java針對該內存操作的最簡單的語言規范來進行一定的習慣限制，排除該情況發生的做法在於：
JVM線程必須依靠自身來維持對象的可見性以及對象自身應該提供相對應的操作而實現整個內存操作的三個特性，而不是僅僅依靠特定的修改對象狀態的線程來完成如此復雜的一個流程。
[4]三個特性的解析（針對JMM內部）：
原子性（Atomicity）：
訪問存儲單元內的任何類型的欄位的值以及對其更新操作的時候，除開long類型和double類型，其他類型的欄位是必須要保證其原子性的，這些欄位也包括為對象服務的引用。此外，該原子性規則擴展可以延伸到基於long和double的另外兩種類型：volatile long和volatile double（volatile為java關鍵字），沒有被volatile聲明的long類型以及double類型的欄位值雖然不保證其JMM中的原子性，但是是被允許的。針對non-long/non-double的欄位在表達式中使用的時候，JMM的原子性有這樣一種規則：如果你獲得或者初始化該值或某一些值的時候，這些值是由其他線程寫入，而且不是從兩個或者多個線程產生的數據在同一時間戳混合寫入的時候，該欄位的原子性在JVM內部是必須得到保證的。也就是說JMM在定義JVM原子性的時候，只要在該規則不違反的條件下，JVM本身不去理睬該數據的值是來自於什麼線程，因為這樣使得Java語言在並行運算的設計的過程中針對多線程的原子性設計變得極其簡單，而且即使開發人員沒有考慮到最終的程序也沒有太大的影響。再次解釋一下：這里的原子性指的是原子級別的操作，比如最小的一塊內存的讀寫操作，可以理解為Java語言最終編譯過後最接近內存的最底層的操作單元，這種讀寫操作的數據單元不是變數的值，而是本機碼，也就是前邊在講《Java基礎知識》中提到的由運行器解釋的時候生成的Native Code。
可見性（Visibility）：
當一個線程需要修改另外線程的可見單元的時候必須遵循以下原則： 一個寫入線程釋放的同步鎖和緊隨其後進行讀取的讀線程的同步鎖是同一個從本質上講，釋放鎖操作強迫它的隸屬線程【釋放鎖的線程】從工作內存中的寫入緩存裡面刷新（專業上講這里不應該是刷新，可以理解為提供）數據（flush操作），然後獲取鎖操作使得另外一個線程【獲得鎖的線程】直接讀取前一個線程可訪問域（也就是可見區域）的欄位的值。因為該鎖內部提供了一個同步方法或者同步塊，該同步內容具有線程排他性，這樣就使得上邊兩個操作只能針對單一線程在同步內容內部進行操作，這樣就使得所有操作該內容的單一線程具有該同步內容（加鎖的同步方法或者同步塊）內的線程排他性，這種情況的交替也可以理解為具有「短暫記憶效應」。這里需要理解的是同步的雙重含義：使用鎖機制允許基於高層同步協議進行處理操作，這是最基本的同步；同時系統內存（很多時候這里是指基於機器指令的底層存儲關卡memory barrier，前邊提到過）在處理同步的時候能夠跨線程操作，使得線程和線程之間的數據是同步的。這樣的機制也折射出一點，並行編程相對於順序編程而言，更加類似於分布式編程。後一種同步可以作為JMM機制中的方法在一個線程中運行的效果展示，注意這里不是多個線程運行的效果展示，因為它反應了該線程願意發送或者接受的雙重操作，並且使得它自己的可見區域可以提供給其他線程運行或者更新，從這個角度來看，使用鎖和消息傳遞可以視為相互之間的變數同步，因為相對其他線程而言，它的操作針對其他線程也是對等的。 一旦某個欄位被申明為volatile，在任何一個寫入線程在工作內存中刷新緩存的之前需要進行進一步的內存操作，也就是說針對這樣的欄位進行立即刷新，可以理解為這種volatile不會出現一般變數的緩存操作，而讀取線程每次必須根據前一個線程的可見域裡面重新讀取該變數的值，而不是直接讀取。 當某個線程第一次去訪問某個對象的域的時候，它要麼初始化該對象的值，要麼從其他寫入線程可見域裡面去讀取該對象的值；這里結合上邊理解，在滿足某種條件下，該線程對某對象域的值的讀取是直接讀取，有些時候卻需要重新讀取。這里需要小心一點的是，在並發編程裡面，不好的一個實踐就是使用一個合法引用去引用不完全構造的對象，這種情況在從其他寫入線程可見域裡面進行數據讀取的時候發生頻率比較高。從編程角度上講，在構造函數裡面開啟一個新的線程是有一定的風險的，特別是該類是屬於一個可子類化的類的時候。Thread.start由調用線程啟動，然後由獲得該啟動的線程釋放鎖具有相同的「短暫記憶效應」，如果一個實現了Runnable介面的超類在子類構造子執行之前調用了Thread(this).start()方法，那麼就可能使得該對象在線程方法run執行之前並沒有被完全初始化，這樣就使得一個指向該對象的合法引用去引用了不完全構造的一個對象。同樣的，如果創建一個新的線程T並且啟動該線程，然後再使用線程T來創建對象X，這種情況就不能保證X對象裡面所有的屬性針對線程T都是可見的除非是在所有針對X對象的引用中進行同步處理，或者最好的方法是在T線程啟動之前創建對象X。 若一個線程終止，所有的變數值都必須從工作內存中刷到主存，比如，如果一個同步線程因為另一個使用Thread.join方法的線程而終止，那麼該線程的可見域針對那個線程而言其發生的改變以及產生的一些影響是需要保證可知道的。 注意：如果在同一個線程裡面通過方法調用去傳一個對象的引用是絕對不會出現上邊提及到的可見性問題的。JMM保證所有上邊的規定以及關於內存可見性特性的描述——一個特殊的更新、一個特定欄位的修改都是某個線程針對其他線程的一個「可見性」的概念，最終它發生的場所在內存模型中Java線程和線程之間，至於這個發生時間可以是一個任意長的時間，但是最終會發生，也就是說，Java內存模型中的可見性的特性主要是針對線程和線程之間使用內存的一種規則和約定，該約定由JMM定義。
不僅僅如此，該模型還允許不同步的情況下可見性特性。比如針對一個線程提供一個對象或者欄位訪問域的原始值進行操作，而針對另外一個線程提供一個對象或者欄位刷新過後的值進行操作。同樣也有可能針對一個線程讀取一個原始的值以及引用對象的對象內容，針對另外一個線程讀取一個刷新過後的值或者刷新過後的引用。
盡管如此，上邊的可見性特性分析的一些特徵在跨線程操作的時候是有可能失敗的，而且不能夠避免這些故障發生。這是一個不爭的事實，使用同步多線程的代碼並不能絕對保證線程安全的行為，只是允許某種規則對其操作進行一定的限制，但是在最新的JVM實現以及最新的Java平台中，即使是多個處理器，通過一些工具進行可見性的測試發現其實是很少發生故障的。跨線程共享CPU的共享緩存的使用，其缺陷就在於影響了編譯器的優化操作，這也體現了強有力的緩存一致性使得硬體的價值有所提升，因為它們之間的關系在線程與線程之間的復雜度變得更高。這種方式使得可見度的自由測試顯得更加不切實際，因為這些錯誤的發生極為罕見，或者說在平台上我們開發過程中根本碰不到。在並行程開發中，不使用同步導致失敗的原因也不僅僅是對可見度的不良把握導致的，導致其程序失敗的原因是多方面的，包括緩存一致性、內存一致性問題等。
可排序性（Ordering）：
可排序規則在線程與線程之間主要有下邊兩點： 從操作線程的角度看來，如果所有的指令執行都是按照普通順序進行，那麼對於一個順序運行的程序而言，可排序性也是順序的 從其他操作線程的角度看來，排序性如同在這個線程中運行在非同步方法中的一個「間諜」，所以任何事情都有可能發生。唯一有用的限制是同步方法和同步塊的相對排序，就像操作volatile欄位一樣，總是保留下來使用 【*：如何理解這里「間諜」的意思，可以這樣理解，排序規則在本線程裡面遵循了第一條法則，但是對其他線程而言，某個線程自身的排序特性可能使得它不定地訪問執行線程的可見域，而使得該線程對本身在執行的線程產生一定的影響。舉個例子，A線程需要做三件事情分別是A1、A2、A3，而B是另外一個線程具有操作B1、B2，如果把參考定位到B線程，那麼對A線程而言，B的操作B1、B2有可能隨時會訪問到A的可見區域，比如A有一個可見區域a，A1就是把a修改稱為1，但是B線程在A線程調用了A1過後，卻訪問了a並且使用B1或者B2操作使得a發生了改變，變成了2，那麼當A按照排序性進行A2操作讀取到a的值的時候，讀取到的是2而不是1，這樣就使得程序最初設計的時候A線程的初衷發生了改變，就是排序被打亂了，那麼B線程對A線程而言，其身份就是「間諜」，而且需要注意到一點，B線程的這些操作不會和A之間存在等待關系，那麼B線程的這些操作就是非同步操作，所以針對執行線程A而言，B的身份就是「非同步方法中的『間諜』。】
同樣的，這僅僅是一個最低限度的保障性質，在任何給定的程序或者平台，開發中有可能發現更加嚴格的排序，但是開發人員在設計程序的時候不能依賴這種排序，如果依賴它們會發現測試難度會成指數級遞增，而且在復合規定的時候會因為不同的特性使得JVM的實現因為不符合設計初衷而失敗。
注意：第一點在JLS（Java Language Specification）的所有討論中也是被採用的，例如算數表達式一般情況都是從上到下、從左到右的順序，但是這一點需要理解的是，從其他操作線程的角度看來這一點又具有不確定性，對線程內部而言，其內存模型本身是存在排序性的。【*：這里討論的排序是最底層的內存裡面執行的時候的NativeCode的排序，不是說按照順序執行的Java代碼具有的有序性質，本文主要分析的是JVM的內存模型，所以希望讀者明白這里指代的討論單元是內存區。】 JMM最初設計的時候存在一定的缺陷，這種缺陷雖然現有的JVM平台已經修復，但是這里不得不提及，也是為了讀者更加了解JMM的設計思路，這一個小節的概念可能會牽涉到很多更加深入的知識，如果讀者不能讀懂沒有關系先看了文章後邊的章節再返回來看也可以。
1)問題1：不可變對象不是不可變的
學過Java的朋友都應該知道Java中的不可變對象，這一點在本文最後講解String類的時候也會提及，而JMM最初設計的時候，這個問題一直都存在，就是：不可變對象似乎可以改變它們的值（這種對象的不可變指通過使用final關鍵字來得到保證），（Publis Service Reminder：讓一個對象的所有欄位都為final並不一定使得這個對象不可變——所有類型還必須是原始類型而不能是對象的引用。而不可變對象被認為不要求同步的。但是，因為在將內存寫方面的更改從一個線程傳播到另外一個線程的時候存在潛在的延遲，這樣就使得有可能存在一種競態條件，即允許一個線程首先看到不可變對象的一個值，一段時間之後看到的是一個不同的值。這種情況以前怎麼發生的呢？在JDK 1.4中的String實現里，這兒基本有三個重要的決定性欄位：對字元數組的引用、長度和描述字元串的開始數組的偏移量。String就是以這樣的方式在JDK 1.4中實現的，而不是只有字元數組，因此字元數組可以在多個String和StringBuffer對象之間共享，而不需要在每次創建一個String的時候都拷貝到一個新的字元數組里。假設有下邊的代碼：
String s1 = /usr/tmp;
String s2 = s1.substring(4); // /tmp
這種情況下，字元串s2將具有大小為4的長度和偏移量，但是它將和s1共享「/usr/tmp」裡面的同一字元數組，在String構造函數運行之前，Object的構造函數將用它們默認的值初始化所有的欄位，包括決定性的長度和偏移欄位。當String構造函數運行的時候，字元串長度和偏移量被設置成所需要的值。但是在舊的內存模型中，因為缺乏同步，有可能另一個線程會臨時地看到偏移量欄位具有初始默認值0，而後又看到正確的值4，結果是s2的值從「/usr」變成了「/tmp」，這並不是我們真正的初衷，這個問題就是原始JMM的第一個缺陷所在，因為在原始JMM模型裡面這是合理而且合法的，JDK 1.4以下的版本都允許這樣做。
2)問題2：重新排序的易失性和非易失性存儲
另一個主要領域是與volatile欄位的內存操作重新排序有關，這個領域中現有的JMM引起了一些比較混亂的結果。現有的JMM表明易失性的讀和寫是直接和主存打交道的，這樣避免了把值存儲到寄存器或者繞過處理器特定的緩存，這使得多個線程一般能看見一個給定變數最新的值。可是，結果是這種volatile定義並沒有最初想像中那樣如願以償，並且導致了volatile的重大混亂。為了在缺乏同步的情況下提供較好的性能，編譯器、運行時和緩存通常是允許進行內存的重新排序操作的，只要當前執行的線程分辨不出它們的區別。（這就是within-thread as-if-serial semantics[線程內似乎是串列]的解釋）但是，易失性的讀和寫是完全跨線程安排的，編譯器或緩存不能在彼此之間重新排序易失性的讀和寫。遺憾的是，通過參考普通變數的讀寫，JMM允許易失性的讀和寫被重排序，這樣以為著開發人員不能使用易失性標志作為操作已經完成的標志。比如：
Map configOptions;
char[] configText;
volatile boolean initialized = false;
// 線程1
configOptions = new HashMap();
configText = readConfigFile(filename);
processConfigOptions(configText,configOptions);
initialized = true;
// 線程2
while(!initialized)
sleep();
這里的思想是使用易失性變數initialized擔任守衛來表明一套別的操作已經完成了，這是一個很好的思想，但是不能在JMM下工作，因為舊的JMM允許非易失性的寫（比如寫到configOptions欄位，以及寫到由configOptions引用Map的欄位中）與易失性的寫一起重新排序，因此另外一個線程可能會看到initialized為true，但是對於configOptions欄位或它所引用的對象還沒有一個一致的或者說當前的針對內存的視圖變數，volatile的舊語義只承諾在讀和寫的變數的可見性，而不承諾其他變數，雖然這種方法更加有效的實現，但是結果會和我們設計之初大相徑庭。
B. java如何將從資料庫取出的數據預先存入到內存
你要實現的這個可能跟SpringMvc的關系不是很大。
你要達到的目的其實就是在jvm啟動的時候把資料庫數據載入一份到內存，一個靜態變數和一個靜態初始化塊就可以搞定你的問題，這兩者都是在類載入的時候初始化一次，像前面回答的一樣，你可以用一個HashMap搞定。稍微具體來說，一個靜態變數
public static final Map<key,value> cache=new HashMap<key,value>()
static {
cache=請求資料庫操作
}
key你自己加，String還是int都行，value是你資料庫的結構，可以寫個實體。獲取的時候直接cache.get(key)就可以了。
C. java byte[] 和ByteBuffer作為中間緩存各有什麼特點
byteBuffer就是在byte[]基礎上發明的輪子。抽象上高一級，原理一樣。
如果用byte[]能直接實現，用byte[]是最直接有效的。
bytebuffer主要和NIO配套使用，讓自己的代碼融入NIO，不一定適用於脫離NIO相關的自製環境。
D. 請教java中怎麼緩存大量的數據，比如100w條記錄
小子，解決問題的思路首先就不對，什麼叫JAVA中……JVM虛擬內存一般只有幾百M，為何別人那麼多大型系統都能跑起來？
第一，大量的數據是不會考慮放在JVM內存中；
第二，如果需要緩存大量的dto，動態數據（又稱過程數據）一般用的是redis；如果是靜態，系統啟動時就載入的大量配置，一般考慮放ehcache。
第三，由於redis用的是物理內存，不是JVM內存，一般情況下往redis里丟千萬級別的記錄數基本不影響性能，小小100w條算什麼呢。
E. Java JVM怎麼學習啊從哪方面入手
一、 JVM的生命周期
1. JVM實例對應了一個獨立運行的java程序它是進程級別
a) 啟動。啟動一個Java程序時，一個JVM實例就產生了，任何一個擁有public static void main(String[] args)函數的class都可以作為JVM實例運行的起點
b) 運行。main()作為該程序初始線程的起點，任何其他線程均由該線程啟動。JVM內部有兩種線程：守護線程和非守護線程，main()屬於非守護線程，守護線程通常由JVM自己使用，java程序也可以標明自己創建的線程是守護線程
c) 消亡。當程序中的所有非守護線程都終止時，JVM才退出；若安全管理器允許，程序也可以使用Runtime類或者System.exit()來退出
2. JVM執行引擎實例則對應了屬於用戶運行程序的線程它是線程級別的
二、 JVM的體系結構
1. 類裝載器（ClassLoader）（用來裝載.class文件）
2. 執行引擎（執行位元組碼，或者執行本地方法）
3. 運行時數據區（方法區、堆、java棧、PC寄存器、本地方法棧）
三、 JVM類載入器
JVM整個類載入過程的步驟：
1. 裝載
裝載過程負責找到二進制位元組碼並載入至JVM中，JVM通過類名、類所在的包名通過ClassLoader來完成類的載入，同樣，也採用以上三個元素來標識一個被載入了的類：類名+
包名+ClassLoader實例ID。
2. 鏈接
鏈接過程負責對二進制位元組碼的格式進行校驗、初始化裝載類中的靜態變數以及解析類中調用的介面、類。
完成校驗後，JVM初始化類中的靜態變數，並將其值賦為默認值。
最後對類中的所有屬性、方法進行驗證，以確保其需要調用的屬性、方法存在，以及具備應的許可權（例如public、private域許可權等），會造成NoSuchMethodError、NoSuchFieldError等錯誤信息。
3. 初始化
初始化過程即為執行類中的靜態初始化代碼、構造器代碼以及靜態屬性的初始化，在四種情況下初始化過程會被觸發執行：
調用了new；
反射調用了類中的方法；
子類調用了初始化；
JVM啟動過程中指定的初始化類。
JVM類載入順序：
JVM兩種類裝載器包括：啟動類裝載器和用戶自定義類裝載器。
啟動類裝載器是JVM實現的一部分；
用戶自定義類裝載器則是Java程序的一部分，必須是ClassLoader類的子類。
JVM裝載順序：
Jvm啟動時，由Bootstrap向User-Defined方向載入類；
應用進行ClassLoader時，由User-Defined向Bootstrap方向查找並載入類；
1. Bootstrap ClassLoader
這是JVM的根ClassLoader，它是用C++實現的，JVM啟動時初始化此ClassLoader，並由此ClassLoader完成$JAVA_HOME中jre/lib/rt.jar（Sun JDK的實現）中所有class文件的載入，這個jar中包含了java規范定義的所有介面以及實現。
2. Extension ClassLoader
JVM用此classloader來載入擴展功能的一些jar包。
3. System ClassLoader
JVM用此classloader來載入啟動參數中指定的Classpath中的jar包以及目錄，在Sun JDK中ClassLoader對應的類名為AppClassLoader。
4. User-Defined ClassLoader
User-DefinedClassLoader是Java開發人員繼承ClassLoader抽象類自行實現的ClassLoader，基於自定義的ClassLoader可用於載入非Classpath中的jar以及目錄。
ClassLoader抽象類的幾個關鍵方法：
（1） loadClass
此方法負責載入指定名字的類，ClassLoader的實現方法為先從已經載入的類中尋找，如沒有則繼續從parent ClassLoader中尋找，如仍然沒找到，則從System ClassLoader中尋找，最後再調用findClass方法來尋找，如要改變類的載入順序，則可覆蓋此方法
（2） findLoadedClass
此方法負責從當前ClassLoader實例對象的緩存中尋找已載入的類，調用的為native的方法。
（3） findClass
此方法直接拋出ClassNotFoundException，因此需要通過覆蓋loadClass或此方法來以自定義的方式載入相應的類。
（4） findSystemClass
此方法負責從System ClassLoader中尋找類，如未找到，則繼續從Bootstrap ClassLoader中尋找，如仍然為找到，則返回null。
（5） defineClass
此方法負責將二進制的位元組碼轉換為Class對象
（6） resolveClass
此方法負責完成Class對象的鏈接，如已鏈接過，則會直接返回。
四、 JVM執行引擎
在執行方法時JVM提供了四種指令來執行：
（1）invokestatic：調用類的static方法
（2）invokevirtual：調用對象實例的方法
（3）invokeinterface：將屬性定義為介面來進行調用
（4）invokespecial：JVM對於初始化對象（Java構造器的方法為：<init>）以及調用對象實例中的私有方法時。
主要的執行技術有:
解釋，即時編譯，自適應優化、晶元級直接執行
（1）解釋屬於第一代JVM，
（2）即時編譯JIT屬於第二代JVM，
（3）自適應優化（目前Sun的HotspotJVM採用這種技術）則吸取第一代JVM和第二代
JVM的經驗，採用兩者結合的方式
開始對所有的代碼都採取解釋執行的方式，並監視代碼執行情況，然後對那些經常調用的方法啟動一個後台線程，將其編譯為本地代碼，並進行優化。若方法不再頻繁使用，則取消編譯過的代碼，仍對其進行解釋執行。
五、 JVM運行時數據區
第一塊：PC寄存器
PC寄存器是用於存儲每個線程下一步將執行的JVM指令，如該方法為native的，則PC寄存器中不存儲任何信息。
第二塊：JVM棧
JVM棧是線程私有的，每個線程創建的同時都會創建JVM棧，JVM棧中存放的為當前線程中局部基本類型的變數（java中定義的八種基本類型：boolean、char、byte、short、int、long、float、double）、部分的返回結果以及Stack Frame，非基本類型的對象在JVM棧上僅存放一個指向堆上的地址
第三塊：堆（Heap）
它是JVM用來存儲對象實例以及數組值的區域，可以認為Java中所有通過new創建的對象的內存都在此分配，Heap中的對象的內存需要等待GC進行回收。
（1） 堆是JVM中所有線程共享的，因此在其上進行對象內存的分配均需要進行加鎖，這也導致了new對象的開銷是比較大的
（2） Sun Hotspot JVM為了提升對象內存分配的效率，對於所創建的線程都會分配一塊獨立的空間TLAB（Thread Local Allocation Buffer），其大小由JVM根據運行的情況計算而得，在TLAB上分配對象時不需要加鎖，因此JVM在給線程的對象分配內存時會盡量的在TLAB上分配，在這種情況下JVM中分配對象內存的性能和C基本是一樣高效的，但如果對象過大的話則仍然是直接使用堆空間分配
（3） TLAB僅作用於新生代的Eden Space，因此在編寫Java程序時，通常多個小的對象比大的對象分配起來更加高效。
第四塊：方法區域（Method Area）
（1）在Sun JDK中這塊區域對應的為PermanetGeneration，又稱為持久代。
（2）方法區域存放了所載入的類的信息（名稱、修飾符等）、類中的靜態變數、類中定義為final類型的常量、類中的Field信息、類中的方法信息，當開發人員在程序中通過Class
對象中的getName、isInterface等方法來獲取信息時，這些數據都來源於方法區域，同時方法區域也是全局共享的，在一定的條件下它也會被GC，當方法區域需要使用的內存超過其允許的大小時，會拋出OutOfMemory的錯誤信息。
第五塊：運行時常量池（Runtime Constant Pool）
存放的為類中的固定的常量信息、方法和Field的引用信息等，其空間從方法區域中分配。
第六塊：本地方法堆棧（Native Method Stacks）
JVM採用本地方法堆棧來支持native方法的執行，此區域用於存儲每個native方法調用的狀態。
六、 JVM垃圾回收
GC的基本原理：將內存中不再被使用的對象進行回收，GC中用於回收的方法稱為收集器，由於GC需要消耗一些資源和時間，Java在對對象的生命周期特徵進行分析後，按照新生代、舊生代的方式來對對象進行收集，以盡可能的縮短GC對應用造成的暫停
（1）對新生代的對象的收集稱為minor GC；
（2）對舊生代的對象的收集稱為Full GC；
（3）程序中主動調用System.gc()強制執行的GC為Full GC。
不同的對象引用類型， GC會採用不同的方法進行回收，JVM對象的引用分為了四種類型：
（1）強引用：默認情況下，對象採用的均為強引用（這個對象的實例沒有其他對象引用，GC時才會被回收）
（2）軟引用：軟引用是Java中提供的一種比較適合於緩存場景的應用（只有在內存不夠用的情況下才會被GC）
（3）弱引用：在GC時一定會被GC回收
（4）虛引用：由於虛引用只是用來得知對象是否被GC
F. 什麼時候使用緩存jvm級別緩存與獨立緩存的主要區別是什麼
簡單地說：一級指令緩存用於暫時存儲並向CPU遞送各類運算指令；二級緩存就是一級緩存的緩沖器，作用就是存儲那些CPU處理時需要用到、一級緩存又無法存儲的數據。同理，三級是二級的存儲器。
G. java緩存是什麼意思 文件放在哪
Java的緩存機制是通過JVM(Java虛擬機)提供的運行時緩存來實現的，由於JVM是不跨平台的(Java的跨平台正是通過JVM的不跨平台來實現的)，所以JVM的緩存機制沒有實現本地臨時存儲，因此你找不到所謂Java的緩存文件夾。這些問題你不用這么糾結，實在不清楚的話打電話問一下官方人員就清楚了。
H. 高並發 緩存 jvm 先學哪個
JVM是最好的軟體工程之一，它為Java提供了堅實的基礎，許多流行語言如Kotlin、Scala、Clojure、Groovy都使用JVM作為運行基礎。一個專業的Java工程師必須要了解並掌握JVM，接下來就給大家分享Java基礎知識中JVM調優相關知識點。
杭州Java基礎知識學習之JVM調優講解
JVM常見的調優參數包括：
-Xmx：指定java程序的最大堆內存, 使用java -Xmx5000M -version判斷當前系統能分配的最大堆內存；
-Xms：指定最小堆內存, 通常設置成跟最大堆內存一樣，減少GC；
-Xmn：設置年輕代大小。整個堆大小=年輕代大小+年老代大小。所以增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的3/8；
-Xss：指定線程的最大棧空間, 此參數決定了java函數調用的深度, 值越大調用深度越深, 若值太小則容易出棧溢出錯誤(StackOverflowError)；
-XX:PermSize：指定方法區(永久區)的初始值,默認是物理內存的1/64，在Java8永久區移除, 代之的是元數據區，由-XX:MetaspaceSize指定；
-XX:MaxPermSize：指定方法區的最大值, 默認是物理內存的1/4，在java8中由-XX:MaxMetaspaceSize指定元數據區的大小；
-XX:NewRatio=n：年老代與年輕代的比值，-XX:NewRatio=2, 表示年老代與年輕代的比值為2:1；
-XX:SurvivorRatio=n：Eden區與Survivor區的大小比值，-XX:SurvivorRatio=8表示Eden區與Survivor區的大小比值是8:1:1，因為Survivor區有兩個(from, to)。
JVM實質上分為三大塊，年輕代(YoungGen)，年老代(Old Memory)，及持久代(Perm，在Java8中被取消)。
年輕代大小選擇
響應時間優先的應用：盡可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的對象。
吞吐量優先的應用：盡可能的設置大，可能到達Gbit的程度。因為對響應時間沒有要求，垃圾收集可以並行進行，一般適合8CPU以上的應用。
年老代大小選擇
響應時間優先的應用：年老代使用並發收集器，所以其大小需要小心設置，一般要考慮並發會話率和會話持續時間等一些參數。如果堆設置小了，可以會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；如果堆大了，則需要較長的收集時間。最優化的方案，一般需要參考以下數據獲得：並發垃圾收集信息、持久代並發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。
減少年輕代和年老代花費的時間，一般會提高應用的效率。
吞吐量優先的應用：一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是，這樣可以盡可能回收掉大部分短期對象，減少中期的對象，而年老代盡存放長期存活對象。
較小堆引起的碎片問題
因為年老代的並發收集器使用標記、清除演算法，所以不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合並，這樣可以分配給較大的對象。但是，當堆空間較小時，運行一段時間以後，就會出現「碎片」，如果並發收集器找不到足夠的空間，那麼並發收集器將會停止，然後使用傳統的標記、清除方式進行回收。如果出現「碎片」，可能需要進行如下配置：
-XX:+UseCMSCompactAtFullCollection：使用並發收集器時，開啟對年老代的壓縮。
-XX:CMSFullGCsBeforeCompaction=0：上面配置開啟的情況下，這里設置多少次Full GC後，對年老代進行壓縮。
I. 北大青鳥設計培訓：java多線程的內存模型
硬體的內存模型物理機並發處理的方案對於jvm的內存模型實現，也有很大的參考作用，畢竟jvm也是在硬體層上來做事情，底層架構也決定了上層的建築建模方式。
計算機並發並非只是多個處理器都參與進來計算就可以了，會牽扯到一些列硬體的問題，最直接的就是要和內存做交互。
但計算機的存儲設備與處理器的預算速度相差太大，完全不能滿足處理器的處理速度，怎麼辦，這就是後續加入的一層讀寫速度接近處理器運算速度的高速緩存來作為處理器和內存之間的緩沖。
高速緩存一邊把使用的數據，從內存復制搬入，方便處理器快速運算，一邊把運算後的數據，再同步到主內存中，如此處理器就無需等待了。
高速緩存雖然解決了處理器和內存的矛盾，但也為計算機帶來了另一個問題：緩存一致性。
特別是當多個處理器都涉及到同一塊主內存區域的時候，將可能會導致各自的緩存數據不一致。
那麼出現不一致情況的時候，以誰的為准？為了解決這個問題，處理器和內存之間的讀寫的時候需要遵循一定的協議來操作，這類協議有：MSI、MESI、MOSI、Synapse、Firefly以及DragonProtocol等。
這就是上圖中處理器、高速緩存、以及內存之間的處理方式。
另外除了高速緩存之外，為了充分利用處理器，處理器還會把輸入的指令碼進行亂序執行優化，只要保證輸出一致，輸入的信息可以亂序執行重組，所以程序中的語句計算順序和輸入代碼的順序並非一致。
JVM內存模型上面我們了解了硬體的內存模型，以此為借鑒，我們看看jvm的內存模型。
jvm定義的一套java內存模型為了能夠跨平台達到一致的內存訪問效果，從而屏蔽掉了各種硬體和操作系統的內存訪問差異。
這點和c和c++並不一樣，C和C++會直接使用物理硬體和操作系統的內存模型來處理，所以在各個平台上會有差異，這一點java不會。
java的內存模型規定了所有的變數都存儲在主內存中，java課程http://www.kmbdqn.cn/發現每個線程擁有自己的工作內存，工作內存保存了該線程使用到的變數的主內存拷貝，線程對變數所有操作，讀取，賦值，都必須在工作內存中進行，不能直接寫主內存變數，線程間變數值的傳遞均需要主內存來完成。
J. ehcache java 對象緩存怎麼實現
EhCache裡面有一個CacheManager類型，它負責管理cache。Cache裡面存儲著Element對象，Element必須是key-value對。Cache是實際物理實現的，在內存中或者磁碟。這些組件的邏輯表示就是下面即將要討論的類。他們的方法提供了可編程的訪問方式。
CacheManager
負責Cache的創建、訪問、移除。
CacheManager創建
CacheManager支持兩種創建模式：單例（Singleton mode）和實例（InstanceMode）。
在2.5之前的版本中，在同一個JVM中允許存在任意數量相同名字的CacheManager。每調用new CacheManager(...)一次，就會產生一個新的CacheManager實例，而不管已經存在多少個。調用CacheManager.create(...)，則返回的是已經存在的那個配置對應的單例CacheManager，如果不存在，則創建一個。
2.5之後的版本，不允許在同一個JVM內存在多個具有相同名字的CacheManager。創建非單例實例的CacheManager()構造函數可能會打破這一規則，但是會拋出NPE異常。如果你的代碼要在同一個JVM創建多個同名的實例，請使用靜態方法CacheManager.create()，總是返回對應名的CacheManager（如果已經存在），否則創建一個