1、 GC

（1）jvm中一次完整的GC流程（從ygc到fgc）是怎樣的，重點講講物件如何晉升到老年代等
答：物件優先在新生代區中分配，若沒有足夠空間，Minor GC；
大物件（需要大量連續記憶體空間）直接進入老年態；長期存活的物件進入老年態。如果物件在新生代出生並經過第一次MGC後仍然存活，年齡+1，若年齡超過一定限制（15），則被晉升到老年態。

（2）JVM垃圾回收機制，何時觸發MinorGC等操作
分代垃圾回收機制：不同的物件生命週期不同。把不同生命週期的物件放在不同代上，不同代上採用最合適它的垃圾回收方式進行回收。
JVM中共劃分為三個代：年輕代、年老代和持久代。

• 年輕代：存放所有新生成的物件；
• 年老代：在年輕代中經歷了N次垃圾回收仍然存活的物件，將被放到年老代中，故都是一些生命週期較長的物件；
• 持久代：用於存放靜態檔案，如Java類、方法等。

新生代的垃圾收集器命名為“minor gc”，老生代的GC命名為”Full Gc 或者Major GC”.其中用System.gc()強制執行的是Full GC.

判斷物件是否需要回收的方法有兩種：

• 引用計數 ：當某物件的引用數為0時，便可以進行垃圾收集。
• 物件引用遍歷 ：果某物件不能從這些根物件的一個（至少一個）到達，則將它作為垃圾收集。在物件遍歷階段，gc必須記住哪些物件可以到達，以便刪除不可到達的物件，這稱為標記（marking）物件。

觸發GC（Garbage Collector）的條件：

• GC在優先順序最低的執行緒中執行，一般在應用程式空閒即沒有應用執行緒在執行時被呼叫。
• Java堆記憶體不足時，GC會被呼叫。

實戰問題

1、一個請求超過20秒了，你怎麼排查和解決；

2、說說你覺得做的比較不錯的專案，講一下專案結構和用到的框架，再說一下為什麼要選擇這些框架；

3、“商品秒殺”的解決方案；

（1）秒殺架構設計理念

• 限流： 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，只允許少部分流量進入服務後端。
• 削峰：對於秒殺系統瞬時會有大量使用者湧入，所以在搶購一開始會有很高的瞬間峰值。高峰值流量是壓垮系統很重要的原因，所以如何把瞬間的高流量變成一段時間平穩的流量也是設計秒殺系統很重要的思路。實現削峰的常用的方法有利用快取和訊息中介軟體等技術。
• 非同步處理：秒殺系統是一個高併發系統，採用非同步處理模式可以極大地提高系統併發量，其實非同步處理就是削峰的一種實現方式。
• 記憶體快取：秒殺系統最大的瓶頸一般都是資料庫讀寫，由於資料庫讀寫屬於磁碟IO，效能很低，如果能夠把部分資料或業務邏輯轉移到記憶體快取，效率會有極大地提升。
• 可拓展：當然如果我們想支援更多使用者，更大的併發，最好就將系統設計成彈性可拓展的，如果流量來了，拓展機器就好了。像淘寶、京東等雙十一活動時會增加大量機器應對交易高峰。

（2）設計思路
將請求攔截在系統上游，降低下游壓力：秒殺系統特點是併發量極大，但實際秒殺成功的請求數量卻很少，所以如果不在前端攔截很可能造成資料庫讀寫鎖衝突，甚至導致死鎖，最終請求超時。

• 充分利用快取：利用快取可極大提高系統讀寫速度。
• 訊息佇列：訊息佇列可以削峰，將攔截大量併發請求，這也是一個非同步處理過程，後臺業務根據自己的處理能力，從訊息佇列中主動的拉取請求訊息進行業務處理。

（3）前端方案

瀏覽器端(js)：
頁面靜態化：將活動頁面上的所有可以靜態的元素全部靜態化，並儘量減少動態元素。通過CDN來抗峰值。
禁止重複提交：使用者提交之後按鈕置灰，禁止重複提交
使用者限流：在某一時間段內只允許使用者提交一次請求，比如可以採取IP限流

（3）後端方案

• 服務端控制器層(閘道器層)
  限制uid（UserID）訪問頻率：我們上面攔截了瀏覽器訪問的請求，但針對某些惡意攻擊或其它外掛，在服務端控制層需要針對同一個訪問uid，限制訪問頻率。

• 服務層
  上面只攔截了一部分訪問請求，當秒殺的使用者量很大時，即使每個使用者只有一個請求，到服務層的請求數量還是很大。比如我們有100W使用者同時搶100臺手機，服務層併發請求壓力至少為100W。
  採用訊息佇列快取請求：既然服務層知道庫存只有100臺手機，那完全沒有必要把100W個請求都傳遞到資料庫啊，那麼可以先把這些請求都寫到訊息佇列快取一下，資料庫層訂閱訊息減庫存，減庫存成功的請求返回秒殺成功，失敗的返回秒殺結束。
  利用快取應對讀請求：對類似於12306等購票業務，是典型的讀多寫少業務，大部分請求是查詢請求，所以可以利用快取分擔資料庫壓力。
  利用快取應對寫請求：快取也是可以應對寫請求的，比如我們就可以把資料庫中的庫存資料轉移到Redis快取中，所有減庫存操作都在Redis中進行，然後再通過後臺程序把Redis中的使用者秒殺請求同步到資料庫中。

• 資料庫層
  資料庫層是最脆弱的一層，一般在應用設計時在上游就需要把請求攔截掉，資料庫層只承擔“能力範圍內”的訪問請求。所以，上面通過在服務層引入佇列和快取，讓最底層的資料庫高枕無憂。

4、手寫個單例模式出來；

5、分散式鎖的解決方案

6、分散式事務解決方案

7、分散式環境下的定時任務管理