JMM 即 java memery model 卫键，java 內存模型傀履，再談java內存模型之前，先認識下Java內存接口
Java內存結構主要分為推（heap）,棧（stack）,方法區(qū)莉炉，本地方法區(qū)钓账，寄存器/計數(shù)器碴犬，
寄存器/程序計數(shù)器：確切的講是一個數(shù)據(jù)結構，用來保存正在執(zhí)行的程序的內存地址官扣，每個線程都有一個獨立的程序計數(shù)器翅敌，互不影響，相當于threadlocal 惕蹄，是線程安全的
java棧：存放一些基本數(shù)據(jù)類型初始數(shù)據(jù)和對象的引用蚯涮，Java棧總是與線程關聯(lián)在一起的卖陵，每當創(chuàng)建一個線程遭顶，JVM就會為該線程創(chuàng)建對應的Java棧
由于Java棧是與線程對應起來的，Java棧數(shù)據(jù)不是線程共有的泪蔫，所以不需要關心其數(shù)據(jù)一致性棒旗，也不會存在同步鎖的問題。
在Hot Spot虛擬機中撩荣，可以使用-Xss參數(shù)來設置棧的大小铣揉。
堆 Heap:堆是JVM所管理的內存中國最大的一塊，是被所有Java線程鎖共享的餐曹，不是線程安全的逛拱，在JVM啟動時創(chuàng)建。堆是存儲Java對象的地方台猴，這一點Java虛擬機規(guī)范中描述是：所有的對象實例以及數(shù)組都要在堆上分配朽合。Java堆是GC管理的主要區(qū)域，從內存回收的角度來看饱狂，由于現(xiàn)在GC基本都采用分代收集算法曹步，所以Java堆還可以細分為：新生代和老年代；新生代再細致一點有Eden空間休讳、From Survivor空間讲婚、To Survivor空間等。
方法區(qū)：存放java類的一些信息俊柔，包括所加載類的信息包括名稱磺樱，修飾符，常量婆咸，final變量，靜態(tài)變量即類變量芜辕，位于方法區(qū)方法信息以及filed信息尚骄，Class 的getClassName, isinterface等方法都源于此，方法區(qū)是線程間共享的侵续，不會頻繁的被GC,存放于JVM的永久代中倔丈，大小可以通過參數(shù)來設置,可以通過-XX:PermSize指定初始值憨闰，-XX:MaxPermSize指定最大值。
常量池：是方法區(qū)中的一個數(shù)據(jù)結構需五。常量池中存儲了如字符串鹉动、final變量值、類名和方法名常量宏邮。常量池在編譯期間就被確定泽示，并保存在已編譯的.class文件中。一般分為兩類：字面量和應用量蜜氨。字面量就是字符串械筛、final變量等。類名和方法名屬于引用量飒炎。引用量最常見的是在調用方法的時候埋哟，根據(jù)方法名找到方法的引用，并以此定為到函數(shù)體進行函數(shù)代碼的執(zhí)行郎汪。引用量包含：類和接口的權限定名赤赊、字段的名稱和描述符，方法的名稱和描述符煞赢。
本地方法區(qū)：本地方法棧和Java棧所發(fā)揮的作用非常相似抛计，區(qū)別不過是Java棧為JVM執(zhí)行Java方法服務，而本地方法棧為JVM執(zhí)行Native方法服務耕驰。本地方法棧也會拋出StackOverflowError和OutOfMemoryError異常蟆炊。
Java內存模型的主要目標是定義程序中各個變量的訪問規(guī)則遥缕，即在JVM中將變量存儲到內存和從內存中取出變量這樣的底層細節(jié)。此處的變量與Java編程里面的變量有所不同步，它包含了實例字段诗祸、靜態(tài)字段和構成數(shù)組對象的元素，但不包含局部變量（基本數(shù)據(jù)類型和引用類型）和方法參數(shù)蝇完，因為后者是線程私有的洒敏，不會共享，當然不存在數(shù)據(jù)競爭問題（如果局部變量是一個reference引用類型趴生，它引用的對象在Java堆中可被各個線程共享阀趴，但是reference引用本身在Java棧的局部變量表中，是線程私有的）苍匆。為了獲得較高的執(zhí)行效能刘急，Java內存模型并沒有限制執(zhí)行引起使用處理器的特定寄存器或者緩存來和主內存進行交互，也沒有限制即時編譯器進行調整代碼執(zhí)行順序這類優(yōu)化措施浸踩。
JMM規(guī)定了所有的變量都存儲在主內存（Main Memory）中叔汁。每個線程還有自己的工作內存（Working Memory）,線程的工作內存中保存了該線程使用到的變量的主內存的副本拷貝，線程對變量的所有操作（讀取、賦值等）都必須在工作內存中進行据块，而不能直接讀寫主內存中的變量（volatile變量仍然有工作內存的拷貝码邻，但是由于它特殊的操作順序性規(guī)定，所以看起來如同直接在主內存中讀寫訪問一般）另假。不同的線程之間也無法直接訪問對方工作內存中的變量像屋，線程之間值的傳遞都需要通過主內存來完成。
Java內存模型是圍繞著并發(fā)編程中原子性边篮、可見性己莺、有序性這三個特征來建立的，那我們依次看一下這三個特征：
原子性：操作具有事務性苟耻，指令執(zhí)行要么全部執(zhí)行完篇恒，要么回滾！
基本類型數(shù)據(jù)的訪問大都是原子操作凶杖，long 和double類型的變量是64位胁艰，但是在32位JVM中，32位的JVM會將64位數(shù)據(jù)的讀寫操作分為2次32位的讀寫操作來進行智蝠，這就導致了long腾么、double類型的變量在32位虛擬機中是非原子操作，數(shù)據(jù)有可能會被破壞杈湾，也就意味著多個線程在并發(fā)訪問的時候是線程非安全的解虱。
可見性：變量在主內存進行變更，對所有的線程都是可見漆撞，同步的殴泰！
除了volatile關鍵字能實現(xiàn)可見性之外，還有synchronized,Lock浮驳，final也是可以的
Java內存屏障和可見性
由于現(xiàn)代的操作系統(tǒng)都是多處理器.而每一個處理器都有自己的緩存,并且這些緩存并不是實時都與內存發(fā)生信息交換.這樣就可能出現(xiàn)一個cpu上的緩存數(shù)據(jù)與另一個cpu上的緩存數(shù)據(jù)不一致的問題.而這樣在多線程開發(fā)中,就有可能導致出現(xiàn)一些異常行為.
而操作系統(tǒng)底層為了這些問題,提供了一些內存屏障用以解決這樣的問題.目前有4種屏障.
LoadLoad屏障：對于這樣的語句Load1; LoadLoad; Load2悍汛，在Load2及后續(xù)讀取操作要讀取的數(shù)據(jù)被訪問前，保證Load1要讀取的數(shù)據(jù)被讀取完畢至会。
StoreStore屏障：對于這樣的語句Store1; StoreStore; Store2离咐，在Store2及后續(xù)寫入操作執(zhí)行前，保證Store1的寫入操作對其它處理器可見奉件。
LoadStore屏障：對于這樣的語句Load1; LoadStore; Store2宵蛀，在Store2及后續(xù)寫入操作被刷出前，保證Load1要讀取的數(shù)據(jù)被讀取完畢县貌。
StoreLoad屏障：對于這樣的語句Store1; StoreLoad; Load2术陶，在Load2及后續(xù)所有讀取操作執(zhí)行前，保證Store1的寫入對所有處理器可見煤痕。它的開銷是四種屏障中最大的瞳别。在大多數(shù)處理器的實現(xiàn)中征候，這個屏障是個萬能屏障，兼具其它三種內存屏障的功能祟敛。
使用
java中對內存屏障的使用在一般的代碼中不太容易見到.常見的有兩種.
通過 Synchronized關鍵字包住的代碼區(qū)域,當線程進入到該區(qū)域讀取變量信息時,保證讀到的是最新的值.這是因為在同步區(qū)內對變量的寫入操作,在離開同步區(qū)時就將當前線程內的數(shù)據(jù)刷新到內存中,而對數(shù)據(jù)的讀取也不能從緩存讀取,只能從內存中讀取,保證了數(shù)據(jù)的讀有效性.這就是插入了StoreStore屏障
使用了volatile修飾變量,則對變量的寫操作,會插入StoreLoad屏障.
其余的操作,則需要通過Unsafe這個類來執(zhí)行.
Unsafe中內存屏障的使用
UNSAFE.putOrderedObject類似這樣的方法,會插入StoreStore內存屏障
Unsafe.putVolatiObject 則是插入了StoreLoad屏障
有序性：對于一個線程的代碼而言，我們總是以為代碼的執(zhí)行是從前往后的兆解，依次執(zhí)行的馆铁。這么說不能說完全不對，在單線程程序里锅睛，確實會這樣執(zhí)行埠巨；但是在多線程并發(fā)時，程序的執(zhí)行就有可能出現(xiàn)亂序现拒。用一句話可以總結為：在本線程內觀察辣垒，操作都是有序的；如果在一個線程中觀察另外一個線程印蔬，所有的操作都是無序的勋桶。前半句是指“線程內表現(xiàn)為串行語義（WithIn Thread As-if-Serial Semantics）”,后半句是指“指令重排”現(xiàn)象和“工作內存和主內存同步延遲”現(xiàn)象。
Java提供了兩個關鍵字volatile和synchronized來保證多線程之間操作的有序性,volatile關鍵字本身通過加入內存屏障來禁止指令的重排序侥猬，而synchronized關鍵字通過一個變量在同一時間只允許有一個線程對其進行加鎖的規(guī)則來實現(xiàn)例驹，
在單線程程序中，不會發(fā)生“指令重排”和“工作內存和主內存同步延遲”現(xiàn)象退唠，只在多線程程序中出現(xiàn)鹃锈。
happens-before原則：
Java內存模型中定義的兩項操作之間的次序關系，如果說操作A先行發(fā)生于操作B瞧预，操作A產(chǎn)生的影響能被操作B觀察到屎债，“影響”包含了修改了內存中共享變量的值、發(fā)送了消息垢油、調用了方法等盆驹。
下面是Java內存模型下一些”天然的“happens-before關系，這些happens-before關系無須任何同步器協(xié)助就已經(jīng)存在秸苗，可以在編碼中直接使用召娜。如果兩個操作之間的關系不在此列，并且無法從下列規(guī)則推導出來的話惊楼，它們就沒有順序性保障玖瘸，虛擬機可以對它們進行隨意地重排序。
a.程序次序規(guī)則(Pragram Order Rule)：在一個線程內檀咙，按照程序代碼順序雅倒，書寫在前面的操作先行發(fā)生于書寫在后面的操作。準確地說應該是控制流順序而不是程序代碼順序弧可，因為要考慮分支蔑匣、循環(huán)結構。
b.管程鎖定規(guī)則(Monitor Lock Rule)：一個unlock操作先行發(fā)生于后面對同一個鎖的lock操作。這里必須強調的是同一個鎖裁良，而”后面“是指時間上的先后順序凿将。
c.volatile變量規(guī)則(Volatile Variable Rule)：對一個volatile變量的寫操作先行發(fā)生于后面對這個變量的讀取操作，這里的”后面“同樣指時間上的先后順序价脾。
d.線程啟動規(guī)則(Thread Start Rule)：Thread對象的start()方法先行發(fā)生于此線程的每一個動作牧抵。
e.線程終于規(guī)則(Thread Termination Rule)：線程中的所有操作都先行發(fā)生于對此線程的終止檢測，我們可以通過Thread.join()方法結束侨把，Thread.isAlive()的返回值等作段檢測到線程已經(jīng)終止執(zhí)行犀变。
f.線程中斷規(guī)則(Thread Interruption Rule)：對線程interrupt()方法的調用先行發(fā)生于被中斷線程的代碼檢測到中斷事件的發(fā)生，可以通過Thread.interrupted()方法檢測是否有中斷發(fā)生秋柄。
g.對象終結規(guī)則(Finalizer Rule)：一個對象初始化完成(構造方法執(zhí)行完成)先行發(fā)生于它的finalize()方法的開始获枝。
g.傳遞性(Transitivity)：如果操作A先行發(fā)生于操作B，操作B先行發(fā)生于操作C骇笔，那就可以得出操作A先行發(fā)生于操作C的結論省店。
一個操作”時間上的先發(fā)生“不代表這個操作會是”先行發(fā)生“，那如果一個操作”先行發(fā)生“是否就能推導出這個操作必定是”時間上的先發(fā)生 “呢蜘拉？也是不成立的萨西，一個典型的例子就是指令重排序。所以時間上的先后順序與happens-before原則之間基本沒有什么關系旭旭，所以衡量并發(fā)安全問題一切必須以happens-before 原則為準谎脯。
PS:springmvc controller 是單例的，所以成員變量是線程非安全的持寄，建議使用trheadlocal
實例變量如果是單例的就是線程非安全的源梭，如果不是單例的就是安全的，Struts2默認不是單例的稍味，所以訪問一個類的實例變量是線程安全的废麻！
