為了提高程式的執行效能，編譯器和處理器都會對指令做重排序，其中處理器的重排序在前面已經分析過了。所謂的重排序其實就是指執行的指令順序。
編譯器的重排序指的是程式編寫的指令在編譯之後，指令可能會產生重排序來優化程式的執行效能。
從源**到最終執行的指令，可能會經過三種重排序。
2和3屬於處理器重排序。這些重排序可能會導致可見性問題。
編譯器的重排序，jmm提供了禁止特定型別的編譯器重排序。
處理器重排序，jmm會要求編譯器生成指令時，會插入記憶體屏障來禁止處理器重排序
當然並不是所有的程式都會出現重排序問題
編譯器的重排序和cpu的重排序的原則一樣，會遵守資料依賴性原則，編譯器和處理器不會改變存在資料依賴關係的兩個操作的執行順序,比如下面的**，
a=1; b=a;
a=1;a=2;
a=b;b=1;
這三種情況在單執行緒裡面如果改變**的執行順序，都會導致結果不一致，所以重排序不會對這類的指令做優化。這種規則也成為as-if-serial。不管怎麼重排序，對於單個執行緒來說執行結果不能改變。比如
int a=2; //1
int b=3; //2
int rs=a*b; //3
1和3、2和3存在資料依賴，所以在最終執行的指令中，3不能重排序到1和2之前，否則程式會報錯。由於1和2不存在資料依賴，所以可以重新排列1和2的順序
快取一致性問題怎麼解決
關於 redis 的其他的一些面試問題已經寫過了，比如常見的快取穿透 雪崩 擊穿 熱點的問題，但是還有乙個比較麻煩的問題就是如何保證快取一致性。對於快取和資料庫的操作，主要有以下兩種方式。先刪除快取，資料庫還沒有更新成功，此時如果讀取快取，快取不存在，去資料庫中讀取到的是舊值，快取不一致發生。延時雙...
併發一致性問題
常見併發併發一致性問題包括 丟失的修改 不可重複讀 讀髒資料 幻影讀 幻影讀在一些資料中往往與不可重複讀歸為一類 2.2.1.1 丟失修改 下面我們先來看乙個例子，說明併發操作帶來的資料的不一致性問題。考慮飛機訂票系統中的乙個活動序列 甲售票點 甲事務 讀出某航班的機票餘額a,設a 16.乙售票點 ...
Session一致性問題
1 什麼是session session在網路應用上表示 會話控制 用於儲存特定使用者會話所需的屬性及配置資訊 session又表示乙個特定的時間間隔，指從登入進入系統到登出退出系統之間所經過的時間。http是無狀態的協議，在動態web應用中，往往需要知道前面的操作和後面的操作是不是乙個使用者。也就...