1.自定義ClassLoader的方法
首先先直接繼承一下ClassLoader接口，然後重寫findClass方法
2.CMS 標記的過程
1、InitialMarking（初始化標記，整個過程STW）
該階段單線程執行，主要分分爲兩步：
標記GC Roots可達的老年代對象；
遍歷新生代對象，標記可達的老年代對象；
2、Marking（併發標記）
該階段GC線程和應用線程併發執行，遍歷InitialMarking階段標記出來的存活對象，然後繼續遞歸標記這些對象可達的對象。
因爲該階段併發執行的，在運行期間可能發生新生代的對象晉升到老年代、或者是直接在老年代分配對象、或者更新老年代對象的引用關係等等，對於這些對象，都是需要進行重新標記的，否則有些對象就會被遺漏，發生漏標的情況。
爲了提高重新標記的效率，該階段會把上述對象所在的Card標識爲Dirty，後續只需掃描這些Dirty Card的對象，避免掃描整個老年代。
3、Precleaning（預清理）
通過參數CMSPrecleaningEnabled選擇關閉該階段，默認啓用，主要做兩件事情：
處理新生代已經發現的引用，比如在併發階段，在Eden區中分配了一個A對象，A對象引用了一個老年代對象B（這個B之前沒有被標記），在這個階段就會標記對象B爲活躍對象。
在併發標記階段，如果老年代中有對象內部引用發生變化，會把所在的Card標記爲Dirty（其實這裏並非使用CardTable，而是一個類似的數據結構，叫ModUnionTalble），通過掃描這些Table，重新標記那些在併發標記階段引用被更新的對象（晉升到老年代的對象、原本就在老年代的對象）
4、AbortablePreclean（可中斷的預清理）
該階段發生的前提是，新生代Eden區的內存使用量大於參數CMSScheduleRemarkEdenSizeThreshold 默認是2M，如果新生代的對象太少，就沒有必要執行該階段，直接執行重新標記階段。
5、FinalMarking（併發重新標記，STW過程）
遍歷新生代對象，重新標記
根據GC Roots，重新標記
遍歷老年代的Dirty Card，重新標記，這裏的Dirty Card大部分已經在clean階段處理過
3.CMS的缺點
由於STW時間太短額外消耗的性能，而且加上本身的多線程，所以很佔用CPU性能。
另外就是會產生內存碎片
計算複雜
4.線程數太多導致棧OOM，線程池
談論了很多種導致oom的原因，其中有一種棧oom的原因可能是線程數開得太多。
5.可重複讀 如何避免幻讀
表象：快照讀（非阻塞讀），僞MVCC
底層：next-key（行鎖+Gap鎖）
a. 在read-uncommited、read-commited隔離級別下不存在Gap鎖，所以在read-uncommited、read-commited隔離級別下無法解決幻讀；在read-repeated、Serializable隔離級別下都實現了Gap鎖，所以解決了幻讀現象。
b. 在read-repeated隔離級別下，如果刪、改、查語句的where條件走的是主鍵索引或者唯一索引
i. where條件全部命中，則給該記錄加上記錄鎖。
ii. where條件不全部命中，則給該記錄周圍加上Gap鎖。
iii. 加上記錄鎖或者是Gap鎖都是爲了防止read-repeated隔離級別下發生幻讀現象。
c. 在RR隔離級別下，如果刪、改、查語句的where條件沒有走索引或者是非唯一索引或非主鍵索引
在當前讀where條件如果沒有走非唯一索引或者沒有走索引，則會使用Gap鎖鎖住當前記錄的Gap，防止幻讀的發生
6.持久性用redo log，事務通經過undo log
7.mybatis只有jdk動態代理，因爲是基於接口實現。
8.關於redis分佈式鎖如何保證不死鎖
設置過期時間
守護線程監聽鎖的過期時間
9.CORS的過程
響應頭中有一個 Access-Control-Allow-Origin 字段，用來記錄可以訪問該資源的域。當瀏覽 器收到這樣的響應頭信息之後，提取出 Access-Control-Allow-Origin 字段中的值，發現該值包含當前頁面所在的域，就知道這個跨域是被允許的，因此就不再對前端的跨域請求進行限制。這就是 GET 請求的整個跨域流程，在這個過程中，前端請求的代碼不需要修改，主要是後端進行處理。這個流程主要是針對 GET、 POST 以及 HEAD 請求，並且沒有自定義請求頭，如果用戶發起一個 DELETE 請求、 PUT 請求或者自定義請求頭，流程就會稍微複雜一些。
比如delete請求，按照上面的流程請求發過來之後，會先進行一個探測，如果有權限，就會返回一段json證明是可以支持跨域的，然後前端和後端就可以進行交互的。