點贊再看，養成習慣，微信搜尋【三太子敖丙】關注這個網際網路苟且偷生的工具人。
本文 GitHub https://github.com/JavaFamily 已收錄，有一線大廠面試完整考點、資料以及我的系列文章。
前言
前段時間敖丙不是在複習嘛，很多小夥伴也想要我的複習路線，以及我自己筆記裡面的一些知識點，好了，丙丙花了一個月的時間，整整一個月啊，給大家整理出來了。
一上來我就放個大招好吧，我的複習腦圖，可以說是全得不行，為了防止被盜圖，我加了水印哈。
這期看下去你會發現很硬核，而且我會持續更新，啥也不說了，看在我熬夜一個月滿臉痘痘的份上，你可以點讚了哈哈。
注：如果圖被壓縮了，可以去公眾號【三太子敖丙】回覆【複習】獲取原圖
Spring
Spring框架的七大模組
Spring Core：框架的最基礎部分，提供 IoC 容器，對 bean 進行管理。
Spring Context：繼承BeanFactory，提供上下文資訊，擴充套件出JNDI、EJB、電子郵件、國際化等功能。
Spring DAO：提供了JDBC的抽象層，還提供了宣告性事務管理方法。
Spring ORM：提供了JPA、JDO、Hibernate、MyBatis 等ORM對映層.
Spring AOP：整合了所有AOP功能
Spring Web：提供了基礎的 Web 開發的上下文資訊，現有的Web框架，如JSF、Tapestry、Structs等，提供了整合
Spring Web MVC：提供了 Web 應用的 Model-View-Controller 全功能實現。
Bean定義5種作用域
singleton（單例） prototype（原型） request session global session
spring ioc初始化流程?
resource定位 即尋找使用者定義的bean資源，由 ResourceLoader通過統一的介面Resource介面來完成 beanDefinition載入 BeanDefinitionReader讀取、解析Resource定位的資源 成BeanDefinition 載入到ioc中（通過HashMap進行維護BD） BeanDefinition註冊 即向IOC容器註冊這些BeanDefinition， 通過BeanDefinitionRegistery實現
BeanDefinition載入流程?
定義BeanDefinitionReader解析xml的document BeanDefinitionDocumentReader解析document成beanDefinition
DI依賴注入流程? （例項化，處理Bean之間的依賴關係）
過程在Ioc初始化後，依賴注入的過程是使用者第一次向IoC容器索要Bean時觸發
如果設定lazy-init=true，會在第一次getBean的時候才初始化bean， lazy-init=false，會容器啟動的時候直接初始化（singleton bean）；
呼叫BeanFactory.getBean（）生成bean的；
生成bean過程運用裝飾器模式產生的bean都是beanWrapper（bean的增強）；
依賴注入怎麼處理bean之間的依賴關係?
其實就是通過在beanDefinition載入時，如果bean有依賴關係，通過佔位符來代替，在呼叫getbean時候，如果遇到佔位符，從ioc裡獲取bean注入到本例項來
Bean的生命週期?
例項化Bean： Ioc容器通過獲取BeanDefinition物件中的資訊進行例項化，例項化物件被包裝在BeanWrapper物件中 設定物件屬性（DI）：通過BeanWrapper提供的設定屬性的介面完成屬性依賴注入； 注入Aware介面（BeanFactoryAware， 可以用這個方式來獲取其它 Bean，ApplicationContextAware）：Spring會檢測該物件是否實現了xxxAware介面，並將相關的xxxAware例項注入給bean BeanPostProcessor：自定義的處理（分前置處理和後置處理） InitializingBean和init-method：執行我們自己定義的初始化方法 使用 destroy：bean的銷燬
IOC：控制反轉：將物件的建立權，由Spring管理. DI（依賴注入）：在Spring建立物件的過程中，把物件依賴的屬性注入到類中。
Spring的IOC注入方式
構造器注入 setter方法注入 註解注入 介面注入
怎麼檢測是否存在迴圈依賴?
Bean在建立的時候可以給該Bean打標，如果遞迴呼叫回來發現正在建立中的話，即說明了迴圈依賴了。
Spring如解決Bean迴圈依賴問題?
Spring中迴圈依賴場景有：
構造器的迴圈依賴 屬性的迴圈依賴 singletonObjects：第一級快取，裡面放置的是例項化好的單例物件； earlySingletonObjects：第二級快取，裡面存放的是提前曝光的單例物件； singletonFactories：第三級快取，裡面存放的是要被例項化的物件的物件工廠 建立bean的時候Spring首先從一級快取singletonObjects中獲取。如果獲取不到，並且物件正在建立中，就再從二級快取earlySingletonObjects中獲取，如果還是獲取不到就從三級快取singletonFactories中取（Bean呼叫建構函式進行例項化後，即使屬性還未填充，就可以通過三級快取向外提前暴露依賴的引用值（提前曝光），根據物件引用能定位到堆中的物件，其原理是基於Java的引用傳遞），取到後從三級快取移動到了二級快取完全初始化之後將自己放入到一級快取中供其他使用， 因為加入singletonFactories三級快取的前提是執行了構造器，所以構造器的迴圈依賴沒法解決。 構造器迴圈依賴解決辦法：在建構函式中使用@Lazy註解延遲載入。在注入依賴時，先注入代理物件，當首次使用時再建立物件說明：一種互斥的關係而非層次遞進的關係，故稱為三個Map而非三級快取的緣由 完成注入；
Spring 中使用了哪些設計模式？
工廠模式： spring中的BeanFactory就是簡單工廠模式的體現，根據傳入唯一的標識來獲得bean物件； 單例模式： 提供了全域性的訪問點BeanFactory； 代理模式： AOP功能的原理就使用代理模式（1、JDK動態代理。2、CGLib位元組碼生成技術代理。） 裝飾器模式： 依賴注入就需要使用BeanWrapper； 觀察者模式： spring中Observer模式常用的地方是listener的實現。如ApplicationListener。 策略模式： Bean的例項化的時候決定採用何種方式初始化bean例項（反射或者CGLIB動態位元組碼生成）
AOP 核心概念
1、切面（aspect）：類是對物體特徵的抽象，切面就是對橫切關注點的抽象
2、橫切關注點：對哪些方法進行攔截，攔截後怎麼處理，這些關注點稱之為橫切關注點。
3、連線點（joinpoint）：被攔截到的點，因為 Spring 只支援方法型別的連線點，所以在Spring 中連線點指的就是被攔截到的方法，實際上連線點還可以是欄位或者構造器。
4、切入點（pointcut）：對連線點進行攔截的定義
5、通知（advice）：所謂通知指的就是指攔截到連線點之後要執行的程式碼，通知分為前置、後置、異常、最終、環繞通知五類。
6、目標物件：代理的目標物件
7、織入（weave）：將切面應用到目標物件並導致代理物件建立的過程
8、引入（introduction）：在不修改程式碼的前提下，引入可以在執行期為類動態地新增方法或欄位。
解釋一下AOP
傳統oop開發程式碼邏輯自上而下的，這個過程中會產生一些橫切性問題，這些問題與我們主業務邏輯關係不大，會散落在程式碼的各個地方，造成難以維護，aop思想就是把業務邏輯與橫切的問題進行分離，達到解耦的目的，提高程式碼重用性和開發效率；
AOP 主要應用場景有：
記錄日誌 監控效能 許可權控制 事務管理
AOP原始碼分析
@EnableAspectJAutoProxy給容器（beanFactory）中註冊一個AnnotationAwareAspectJAutoProxyCreator物件；
AnnotationAwareAspectJAutoProxyCreator對目標物件進行代理物件的建立，物件內部，是封裝JDK和CGlib兩個技術，實現動態代理物件建立的（建立代理物件過程中，會先建立一個代理工廠，獲取到所有的增強器（通知方法），將這些增強器和目標類注入代理工廠，再用代理工廠建立物件）；
代理物件執行目標方法，得到目標方法的攔截器鏈，利用攔截器的鏈式機制，依次進入每一個攔截器進行執行
AOP應用場景
日誌記錄 事務管理 執行緒池關閉等
AOP使用哪種動態代理?
當bean的是實現中存在介面或者是Proxy的子類，---jdk動態代理；不存在介面，spring會採用CGLIB來生成代理物件； JDK 動態代理主要涉及到 java.lang.reflect 包中的兩個類：Proxy 和 InvocationHandler。 Proxy 利用 InvocationHandler（定義橫切邏輯） 介面動態建立 目標類的代理物件。
jdk動態代理
通過bind方法建立代理與真實物件關係，通過Proxy.newProxyInstance（target）生成代理物件 代理物件通過反射invoke方法實現呼叫真實物件的方法
動態代理與靜態代理區別
靜態代理，程式執行前代理類的.class檔案就存在了； 動態代理：在程式執行時利用反射動態建立代理物件<複用性，易用性，更加集中都呼叫invoke>
CGLIB與JDK動態代理區別
Jdk必須提供介面才能使用； C不需要，只要一個非抽象類就能實現動態代理
SpringMVC
springMVC流程：
（1）：使用者請求傳送給DispatcherServlet，DispatcherServlet呼叫HandlerMapping處理器對映器；
（2）：HandlerMapping根據xml或註解找到對應的處理器，生成處理器物件返回給DispatcherServlet；
（3）：DispatcherServlet會呼叫相應的HandlerAdapter；
（4）：HandlerAdapter經過適配呼叫具體的處理器去處理請求，生成ModelAndView返回給DispatcherServlet
（5）：DispatcherServlet將ModelAndView傳給ViewReslover解析生成View返回給DispatcherServlet；
（6）：DispatcherServlet根據View進行渲染檢視；
->DispatcherServlet->HandlerMapping->Handler ->DispatcherServlet->HandlerAdapter處理handler->ModelAndView ->DispatcherServlet->ModelAndView->ViewReslover->View ->DispatcherServlet->返回給客戶
Mybatis
Mybatis原理
sqlsessionFactoryBuilder生成sqlsessionFactory（單例） 工廠模式生成sqlsession執行sql以及控制事務 Mybatis通過動態代理使Mapper（sql對映器）介面能執行起來即為介面生成代理物件將sql查詢到結果對映成pojo
sqlSessionFactory構建過程
解析並讀取配置中的xml建立Configuration物件 （單例） 使用Configruation類去建立sqlSessionFactory（builder模式）
Mybatis一級快取與二級快取
預設情況下一級快取是開啟的，而且是不能關閉的。
一級快取是指 SqlSession 級別的快取 原理：使用的資料結構是一個 map，如果兩次中間出現 commit 操作 （修改、新增、刪除），本 sqlsession 中的一級快取區域全部清空 二級快取是指可以跨 SqlSession 的快取。是 mapper 級別的快取； 原理： 是通過 CacheExecutor 實現的。CacheExecutor其實是 Executor 的代理物件
Zookeeper+eureka+springcloud
SpringBoot啟動流程
new springApplication物件，利用spi機制載入applicationContextInitializer， applicationLister介面例項（META-INF/spring.factories）；
調run方法準備Environment，載入應用上下文（applicationContext），釋出事件 很多通過lister實現
建立spring容器， refreshContext（） ，實現starter自動化配置，spring.factories檔案載入， bean例項化
SpringBoot自動配置的原理
@EnableAutoConfiguration找到META-INF/spring.factories（需要建立的bean在裡面）配置檔案 讀取每個starter中的spring.factories檔案
Spring Boot 的核心註解
核心註解是@SpringBootApplication 由以下三種組成
@SpringBootConfiguration：組合了 @Configuration 註解，實現配置檔案的功能。 @EnableAutoConfiguration：開啟自動配置的功能。 @ComponentScan：Spring元件掃描。
SpringBoot常用starter都有哪些
spring-boot-starter-web - Web 和 RESTful 應用程式； spring-boot-starter-test - 單元測試和整合測試； spring-boot-starter-jdbc - 傳統的 JDBC； spring-boot-starter-security - 使用 SpringSecurity 進行身份驗證和授權； spring-boot-starter-data-jpa - 帶有 Hibernate 的 Spring Data JPA； spring-boot-starter-data-rest - 使用 Spring Data REST 公佈簡單的 REST 服務
Spring Boot 的核心配置檔案
（1）：Application.yml 一般用來定義單個應用級別的，如果搭配 spring-cloud-config 使用
（2）.Bootstrap.yml（先載入） 系統級別的一些引數配置，這些引數一般是不變的
Zuul與Gateway區別
（1）：zuul則是netflix公司的專案整合在spring-cloud中使用而已， Gateway是spring-cloud的 一個子專案；
（2）：zuul不提供非同步支援流控等均由hystrix支援， gateway提供了非同步支援，提供了抽象負載均衡，提供了抽象流控； 理論上gateway則更適合於提高系統吞吐量（但不一定能有更好的效能），最終效能還需要通過嚴密的壓測來決定
（3）：兩者底層實現都是servlet，但是gateway多巢狀了一層webflux框架
（4）： zuul可用至其他微服務框架中，內部沒有實現限流、負載均衡；gateway只能用在springcloud中；
Zuul原理分析
（1）：請求給zuulservlet處理（HttpServlet子類） zuulservlet中有一個zuulRunner物件，該物件中初始化了RequestContext（儲存請求的資料），RequestContext被所有的zuulfilter共享；
（2）： zuulRunner中有 FilterProcessor（zuulfilter的管理器），其從filterloader 中獲取zuulfilter；
（3）：有了這些filter之後， zuulservelet執行的Pre-> route-> post 型別的過濾器，如果在執行這些過濾器有錯誤的時候則會執行error型別的過濾器，執行完後把結果返回給客戶端.
Gateway原理分析
（1）：請求到達DispatcherHandler， DispatchHandler在IOC容器初始化時會在容器中例項化HandlerMapping介面
（2）：用handlerMapping根據請求URL匹配到對應的Route，然後有對應的filter做對應的請求轉發最終response返回去
Zookeeper 工作原理（待查）
Zookeeper 的核心是原子廣播，這個機制保證了各個 server 之間的同步。實現這個機制的協議叫做 Zab 協議。Zab 協議有兩種模式，它們分別是恢復模式和廣播模式。
zoo與eur區別
zookeeper保證cp（一致性） eureka保證ap（可用性） zoo在選舉期間註冊服務癱瘓，期間不可用 eur各個節點平等關係，只要有一臺就可保證服務可用，而查詢到的資料可能不是最新的，可以很好應對網路故障導致部分節點失聯情況 zoo有leader和follower角色，eur各個節點平等 zoo採用半數存活原則（避免腦裂），eur採用自我保護機制來解決分割槽問題 eur本質是個工程，zoo只是一個程式 ZooKeeper基於CP，不保證高可用，如果zookeeper正在選主，或者Zookeeper叢集中半數以上機器不可用，那麼將無法獲得資料。 Eureka基於AP，能保證高可用，即使所有機器都掛了，也能拿到本地快取的資料。作為註冊中心，其實配置是不經常變動的，只有發版（釋出新的版本）和機器出故障時會變。對於不經常變動的配置來說，CP是不合適的，而AP在遇到問題時可以用犧牲一致性來保證可用性，既返回舊資料，快取資料。 所以理論上Eureka是更適合做註冊中心。而現實環境中大部分專案可能會使用ZooKeeper，那是因為叢集不夠大，並且基本不會遇到用做註冊中心的機器一半以上都掛了的情況。所以實際上也沒什麼大問題。
Hystrix原理（待查）
通過維護一個自己的執行緒池，當執行緒池達到閾值的時候，就啟動服務降級，返回fallback預設值
為什麼需要hystrix熔斷
防止雪崩，及時釋放資源，防止系統發生更多的額級聯故障，需要對故障和延遲進行隔離，防止單個依賴關係的失敗影響整個應用程式；
微服務優缺點
每個服務高內聚，鬆耦合，面向介面程式設計； 服務間通訊成本，資料一致性，多服務運維難度增加，http傳輸效率不如rpc
eureka自我保護機制
eur不移除長時間沒收到心跳而應該過期的服務 仍然接受新服務註冊和查詢請求，但是不會同步到其它節點（高可用） 當網路穩定後，當前例項新註冊資訊會同步到其它節點（最終一致性）
MQ對比
ActiveMQ：Apache出品，最早使用的訊息佇列產品，時間比較長了，最近版本更新比較緩慢。 RabbitMQ：erlang語言開發，支援很多的協議，非常重量級，更適合於企業級的開發。效能較好，但是不利於做二次開發和維護。 RocketMQ：阿里開源的訊息中介軟體，純Java開發，具有高吞吐量、高可用性、適合大規模分散式系統應用的特點，分散式事務。 ZeroMQ：號稱最快的訊息佇列系統，尤其針對大吞吐量的需求場景，採用 C 語言實現。 訊息佇列的選型需要根據具體應用需求而定，ZeroMQ 小而美，RabbitMQ 大而穩，Kakfa 和 RocketMQ 快而強勁
JAVA基礎
AVL樹與紅黑樹（R-B樹）的區別與聯絡
AVL是嚴格的平衡樹，因此在增加或者刪除節點的時候，根據不同情況，旋轉的次數比紅黑樹要多； 紅黑樹是用非嚴格的平衡來換取增刪節點時候旋轉次數的降低開銷； 所以簡單說，查詢多選擇AVL樹，查詢更新次數差不多選紅黑樹 AVL樹順序插入和刪除時有20%左右的效能優勢，紅黑樹隨機操作15%左右優勢，現實應用當然一般都是隨機情況，所以紅黑樹得到了更廣泛的應用 索引為B+樹 Hashmap為紅黑樹
為啥redis zset使用跳躍連結串列而不用紅黑樹實現
skiplist的複雜度和紅黑樹一樣，而且實現起來更簡單。 在併發環境下紅黑樹在插入和刪除時需要rebalance，效能不如跳錶。
JAVA基本資料型別
（1個位元組是8個bit） 整數型：byte（1位元組）、short（2位元組）、int（4位元組）、long（8位元組） 浮點型：float（4位元組）、double（8位元組） 布林型：boolean（1位元組） 字元型：char（2位元組）
IO與NIO
包括 類File，outputStream，inputStream，writer，readerseralizable（5類1介面）
NIO三大核心內容 selector（選擇器，用於監聽channel），channel（通道），buffer（緩衝區）
NIO與IO區別，IO面向流，NIO面向緩衝區；io阻塞，nio非阻塞
異常類
throwable為父類，子為error跟exception，exception分runtime（空指標，越界等）跟checkexception（sql，io，找不到類等異常）
LVS（4層與7層）原理
由前端虛擬負載均衡器和後端真實伺服器群組成； 請求傳送給虛擬伺服器後其根據包轉發策略以及負載均衡排程演算法轉發給真實伺服器 所謂四層（lvs，f5）就是基於IP+埠的負載均衡；七層（nginx）就是基於URL等應用層資訊的負載均衡
StringBuilder與StringBuffer
StringBuilder 更快； StringBuffer是執行緒安全的
interrupt/isInterrupted/interrupt區別
interrupt（） 呼叫該方法的執行緒的狀態為將被置為"中斷"狀態（set操作） isinterrupted（） 是作用於呼叫該方法的執行緒物件所對應的執行緒的中斷訊號是true還是false（get操作）。例如我們可以在A執行緒中去呼叫B執行緒物件的isInterrupted方法，檢視的是A interrupted（）是靜態方法：內部實現是呼叫的當前執行緒的isInterrupted（），並且會重置當前執行緒的中斷狀態（getandset）
sleep與wait區別
sleep屬於執行緒類，wait屬於object類；sleep不釋放鎖
CountDownLatch和CyclicBarrier區別
con用於主執行緒等待其他子執行緒任務都執行完畢後再執行，cyc用於一組執行緒相互等待大家都達到某個狀態後，再同時執行； CountDownLatch是不可重用的，CyclicBarrier可重用
終止執行緒方法
使用退出標誌，說執行緒正常退出； 通過判斷this.interrupted（） throw new InterruptedException（）來停止 使用String常量池作為鎖物件會導致兩個執行緒持有相同的鎖，另一個執行緒不執行，改用其他如new Object（）
ThreadLocal的原理和應用
原理：
執行緒中建立副本，訪問自己內部的副本變數，內部實現是其內部類名叫ThreadLocalMap的成員變數threadLocals，key為本身，value為實際存值的變數副本
應用：
用來解決資料庫連線，存放connection物件，不同執行緒存放各自session； 解決simpleDateFormat執行緒安全問題； 會出現記憶體洩漏，顯式remove..不要與執行緒池配合，因為worker往往是不會退出的；
threadLocal 記憶體洩漏問題
如果是強引用，設定tl=null，但是key的引用依然指向ThreadLocal物件，所以會有記憶體洩漏，而使用弱引用則不會； 但是還是會有記憶體洩漏存在，ThreadLocal被回收，key的值變成null，導致整個value再也無法被訪問到； 解決辦法：在使用結束時，呼叫ThreadLocal.remove來釋放其value的引用；
如果我們要獲取父執行緒的ThreadLocal值呢
ThreadLocal是不具備繼承性的，所以是無法獲取到的，但是我們可以用InteritableThreadLocal來實現這個功能。InteritableThreadLocal繼承來ThreadLocal，重寫了createdMap方法，已經對應的get和set方法，不是在利用了threadLocals，而是interitableThreadLocals變數。
這個變數會線上程初始化的時候（呼叫init方法），會判斷父執行緒的interitableThreadLocals變數是否為空，如果不為空，則把放入子執行緒中，但是其實這玩意沒啥鳥用，當父執行緒建立完子執行緒後，如果改變父執行緒內容是同步不到子執行緒的。。。同樣，如果在子執行緒建立完後，再去賦值，也是沒啥鳥用的
執行緒狀態
執行緒池有5種狀態：running，showdown，stop，Tidying，TERMINATED。
running：執行緒池處於執行狀態，可以接受任務，執行任務，建立執行緒預設就是這個狀態了
showdown：呼叫showdown（）函式，不會接受新任務，但是會慢慢處理完堆積的任務。
stop：呼叫showdownnow（）函式，不會接受新任務，不處理已有的任務，會中斷現有的任務。
Tidying：當執行緒池狀態為showdown或者stop，任務數量為0，就會變為tidying。這個時候會呼叫鉤子函式terminated（）。
TERMINATED：terminated（）執行完成。
線上程池中，用了一個原子類來記錄執行緒池的資訊，用了int的高3位表示狀態，後面的29位表示執行緒池中執行緒的個數。
Java中的執行緒池是如何實現的？
執行緒中執行緒被抽象為靜態內部類Worker，是基於AQS實現的存放在HashSet中； 要被執行的執行緒存放在BlockingQueue中； 基本思想就是從workQueue中取出要執行的任務，放在worker中處理；
如果執行緒池中的一個執行緒執行時出現了異常，會發生什麼
如果提交任務的時候使用了submit，則返回的feature裡會存有異常資訊，但是如果數execute則會列印出異常棧。但是不會給其他執行緒造成影響。之後執行緒池會刪除該執行緒，會新增加一個worker。
執行緒池原理
提交一個任務，執行緒池裡存活的核心執行緒數小於corePoolSize時，執行緒池會建立一個核心執行緒去處理提交的任務 如果執行緒池核心執行緒數已滿，即執行緒數已經等於corePoolSize，一個新提交的任務，會被放進任務佇列workQueue排隊等待執行。 當執行緒池裡面存活的執行緒數已經等於corePoolSize了，並且任務佇列workQueue也滿，判斷執行緒數是否達到maximumPoolSize，即最大執行緒數是否已滿，如果沒到達，建立非核心執行緒執行提交的任務。 如果當前的執行緒數達到了maximumPoolSize，還有新的任務過來的話，直接採用拒絕策略處理。
拒絕策略
AbortPolicy直接丟擲異常阻止執行緒執行； CallerRunsPolicy如果被丟棄的執行緒任務未關閉，則執行該執行緒； DiscardOldestPolicy移除佇列最早執行緒嘗試提交當前任務 DiscardPolicy丟棄當前任務，不做處理
newFixedThreadPool （固定數目執行緒的執行緒池）
阻塞佇列為無界佇列LinkedBlockingQueue 適用於處理CPU密集型的任務，適用執行長期的任務
newCachedThreadPool（可快取執行緒的執行緒池）
阻塞佇列是SynchronousQueue 適用於併發執行大量短期的小任務
newSingleThreadExecutor（單執行緒的執行緒池）
阻塞佇列是LinkedBlockingQueue 適用於序列執行任務的場景，一個任務一個任務地執行
newScheduledThreadPool（定時及週期執行的執行緒池）
阻塞佇列是DelayedWorkQueue 週期性執行任務的場景，需要限制執行緒數量的場景
java鎖相關
synchronized實現原理
contentionList（請求鎖執行緒佇列） entryList（有資格的候選者佇列） waitSet（wait方法後阻塞佇列） onDeck（競爭候選者） ower（競爭到鎖執行緒） !ower（執行成功釋放鎖後狀態）； Synchronized 是非公平鎖。
Synchronized 線上程進入 ContentionList 時，等待的執行緒會先嚐試自旋獲取鎖，如果獲取不到就進入 ContentionList，這明顯對於已經進入佇列的執行緒是不公平的，還有一個不公平的事情就是自旋獲取鎖的執行緒還可能直接搶佔 OnDeck 執行緒的鎖資源。
底層是由一對monitorenter和monitorexit指令實現的（監視器鎖）
每個物件有一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，執行緒執行monitorenter指令時嘗試獲取monitor的所有權，過程：
如果monitor的進入數為0，則該執行緒進入monitor，然後將進入數設定為1，該執行緒即為monitor的所有者。 如果執行緒已經佔有該monitor，只是重新進入，則進入monitor的進入數加1. 如果其他執行緒已經佔用了monitor，則該執行緒進入阻塞狀態，直到monitor的進入數為0，再重新嘗試獲取monitor的所有權。
ReentrantLock 是如何實現可重入性的 ？
內部自定義了同步器 Sync，加鎖的時候通過CAS 演算法 ，將執行緒物件放到一個雙向連結串列 中，每次獲取鎖的時候 ，看下當前維 護的那個執行緒ID和當前請求的執行緒ID是否一樣，一樣就可重入了；
ReentrantLock如何避免死鎖?
響應中斷lockInterruptibly（） 可輪詢鎖tryLock（） 定時鎖tryLock（long time）
tryLock 和 lock 和 lockInterruptibly 的區別
（1）：tryLock 能獲得鎖就返回 true，不能就立即返回 false，
（2）：tryLock（long timeout，TimeUnit unit），可以增加時間限制，如果超過該時間段還沒獲得鎖，返回 false
（3）：lock 能獲得鎖就返回 true，不能的話一直等待獲得鎖
（4）：lock 和 lockInterruptibly，如果兩個執行緒分別執行這兩個方法，但此時中斷這兩個執行緒， lock 不會丟擲異常，而 lockInterruptibly 會丟擲異常。
CountDownLatch和CyclicBarrier的區別是什麼
CountDownLatch是等待其他執行緒執行到某一個點的時候，在繼續執行邏輯（子執行緒不會被阻塞，會繼續執行），只能被使用一次。最常見的就是join形式，主執行緒等待子執行緒執行完任務，在用主執行緒去獲取結果的方式（當然不一定），內部是用計數器相減實現的（沒錯，又特麼是AQS），AQS的state承擔了計數器的作用，初始化的時候，使用CAS賦值，主執行緒呼叫await（）則被加入共享執行緒等待佇列裡面，子執行緒呼叫countDown的時候，使用自旋的方式，減1，知道為0，就觸發喚醒。
CyclicBarrier迴環屏障，主要是等待一組執行緒到底同一個狀態的時候，放閘。CyclicBarrier還可以傳遞一個Runnable物件，可以到放閘的時候，執行這個任務。CyclicBarrier是可迴圈的，當呼叫await的時候如果count變成0了則會重置狀態，如何重置呢，CyclicBarrier新增了一個欄位parties，用來儲存初始值，當count變為0的時候，就重新賦值。還有一個不同點，CyclicBarrier不是基於AQS的，而是基於RentrantLock實現的。存放的等待佇列是用了條件變數的方式。
synchronized與ReentrantLock區別
都是可重入鎖； R是顯示獲取和釋放鎖，s是隱式； R更靈活可以知道有沒有成功獲取鎖，可以定義讀寫鎖，是api級別，s是JVM級別； R可以定義公平鎖；Lock是介面，s是java中的關鍵字
什麼是訊號量Semaphore
訊號量是一種固定資源的限制的一種併發工具包，基於AQS實現的，在構造的時候會設定一個值，代表著資源數量。訊號量主要是應用於是用於多個共享資源的互斥使用，和用於併發執行緒數的控制（druid的資料庫連線數，就是用這個實現的），訊號量也分公平和非公平的情況，基本方式和reentrantLock差不多，在請求資源呼叫task時，會用自旋的方式減1，如果成功，則獲取成功了，如果失敗，導致資源數變為了0，就會加入佇列裡面去等待。呼叫release的時候會加一，補充資源,並喚醒等待佇列。
Semaphore 應用
acquire（） release（） 可用於物件池，資源池的構建，比如靜態全域性物件池，資料庫連線池； 可建立計數為1的S，作為互斥鎖（二元訊號量）
可重入鎖概念
（1）：可重入鎖是指同一個執行緒可以多次獲取同一把鎖，不會因為之前已經獲取過還沒釋放而阻塞；
（2）：reentrantLock和synchronized都是可重入鎖
（3）：可重入鎖的一個優點是可一定程度避免死鎖
ReentrantLock原理（CAS+AQS）
CAS+AQS佇列來實現
（1）：先通過CAS嘗試獲取鎖， 如果此時已經有執行緒佔據了鎖，那就加入AQS佇列並且被掛起；
（2）： 當鎖被釋放之後， 排在隊首的執行緒會被喚醒CAS再次嘗試獲取鎖，
（3）：如果是非公平鎖， 同時還有另一個執行緒進來嘗試獲取可能會讓這個執行緒搶到鎖；
（4）：如果是公平鎖， 會排到隊尾，由隊首的執行緒獲取到鎖。
AQS 原理
Node內部類構成的一個雙向連結串列結構的同步佇列，通過控制（volatile的int型別）state狀態來判斷鎖的狀態，對於非可重入鎖狀態不是0則去阻塞；
對於可重入鎖如果是0則執行，非0則判斷當前執行緒是否是獲取到這個鎖的執行緒，是的話把state狀態＋1，比如重入5次，那麼state=5。 而在釋放鎖的時候，同樣需要釋放5次直到state=0其他執行緒才有資格獲得鎖
AQS兩種資源共享方式
Exclusive：獨佔，只有一個執行緒能執行，如ReentrantLock Share：共享，多個執行緒可以同時執行，如Semaphore、CountDownLatch、ReadWriteLock，CyclicBarrier
CAS原理
記憶體值V，舊的預期值A，要修改的新值B，當A=V時，將記憶體值修改為B，否則什麼都不做；
CAS的缺點：
（1）：ABA問題； （2）：如果CAS失敗，自旋會給CPU帶來壓力； （3）：只能保證對一個變數的原子性操作，i++這種是不能保證的
CAS在java中的應用：
（1）：Atomic系列
公平鎖與分公平鎖
（1）：公平鎖指在分配鎖前檢查是否有執行緒在排隊等待獲取該鎖，優先分配排隊時間最長的執行緒，非公平直接嘗試獲取鎖 （2）：公平鎖需多維護一個鎖執行緒佇列，效率低；預設非公平
獨佔鎖與共享鎖
（1）：ReentrantLock為獨佔鎖（悲觀加鎖策略） （2）：ReentrantReadWriteLock中讀鎖為共享鎖 （3）： JDK1.8 郵戳鎖（StampedLock）， 不可重入鎖 讀的過程中也允許獲取寫鎖後寫入！這樣一來，我們讀的資料就可能不一致，所以，需要一點額外的程式碼來判斷讀的過程中是否有寫入，這種讀鎖是一種樂觀鎖， 樂觀鎖的併發效率更高，但一旦有小概率的寫入導致讀取的資料不一致，需要能檢測出來，再讀一遍就行
4種鎖狀態
無鎖
偏向鎖 會偏向第一個訪問鎖的執行緒，當一個執行緒訪問同步程式碼塊獲得鎖時，會在物件頭和棧幀記錄裡儲存鎖偏向的執行緒ID，當這個執行緒再次進入同步程式碼塊時，就不需要CAS操作來加鎖了，只要測試一下物件頭裡是否儲存著指向當前執行緒的偏向鎖 如果偏向鎖未啟動，new出的物件是普通物件（即無鎖，有稍微競爭會成輕量級鎖），如果啟動，new出的物件是匿名偏向（偏向鎖） 物件頭主要包括兩部分資料：Mark Word（標記欄位， 儲存物件自身的執行時資料）、class Pointer（型別指標， 是物件指向它的類後設資料的指標）
輕量級鎖（自旋鎖） （1）：在把執行緒進行阻塞操作之前先讓執行緒自旋等待一段時間，可能在等待期間其他執行緒已經 解鎖，這時就無需再讓執行緒執行阻塞操作，避免了使用者態到核心態的切換。（自適應自旋時間為一個執行緒上下文切換的時間）
（2）：在用自旋鎖時有可能造成死鎖，當遞迴呼叫時有可能造成死鎖
（3）：自旋鎖底層是通過指向執行緒棧中Lock Record的指標來實現的
重量級鎖
輕量級鎖與偏向鎖的區別
（1）：輕量級鎖是通過CAS來避免進入開銷較大的互斥操作
（2）：偏向鎖是在無競爭場景下完全消除同步，連CAS也不執行
自旋鎖升級到重量級鎖條件
（1）：某執行緒自旋次數超過10次；
（2）：等待的自旋執行緒超過了系統core數的一半；
讀寫鎖瞭解嘛，知道讀寫鎖的實現方式嘛
常用的讀寫鎖ReentrantReanWritelock，這個其實和reentrantLock相似，也是基於AQS的，但是這個是基於共享資源的，不是互斥，關鍵在於state的處理，讀寫鎖把高16為記為讀狀態，低16位記為寫狀態，就分開了，讀讀情況其實就是讀鎖重入，讀寫/寫讀/寫寫都是互斥的，只要判斷低16位就好了。
zookeeper實現分散式鎖
（1）：利用節點名稱唯一性來實現，加鎖時所有客戶端一起建立節點，只有一個建立成功者獲得鎖，解鎖時刪除節點。
（2）：利用臨時順序節點實現，加鎖時所有客戶端都建立臨時順序節點，建立節點序列號最小的獲得鎖，否則監視比自己序列號次小的節點進行等待
（3）：方案2比1好處是當zookeeper當機後，臨時順序節點會自動刪除釋放鎖，不會造成鎖等待；
（4）：方案1會產生驚群效應（當有很多程式在等待鎖的時候，在釋放鎖的時候會有很多程式就過來爭奪鎖）。
（5）：由於需要頻繁建立和刪除節點，效能上不如redis鎖
volatile變數
（1）：變數可見性
（2）：防止指令重排序
（3）：保障變數單次讀，寫操作的原子性，但不能保證i++這種操作的原子性，因為本質是讀，寫兩次操作
volatile如何保證執行緒間可見和避免指令重排
volatile可見性是有指令原子性保證的，在jmm中定義了8類原子性指令，比如write，store，read，load。而volatile就要求write-store，load-read成為一個原子性操作，這樣子可以確保在讀取的時候都是從主記憶體讀入，寫入的時候會同步到主記憶體中（準確來說也是記憶體屏障），指令重排則是由記憶體屏障來保證的，由兩個記憶體屏障:
一個是編譯器屏障：阻止編譯器重排，保證編譯程式時在優化屏障之前的指令不會在優化屏障之後執行。 第二個是cpu屏障：sfence保證寫入，lfence保證讀取，lock類似於鎖的方式。java多執行了一個“load addl $0x0, (%esp)”操作，這個操作相當於一個lock指令，就是增加一個完全的記憶體屏障指令。
JVM
jre、jdk、jvm的關係：
jdk是最小的開發環境，由jre++java工具組成。
jre是java執行的最小環境，由jvm+核心類庫組成。
jvm是虛擬機器，是java位元組碼執行的容器，如果只有jvm是無法執行java的，因為缺少了核心類庫。
JVM記憶體模型
（1）：堆<物件，靜態變數，共享
（2）：方法區<存放類資訊，常量池，共享>（java8移除了永久代（PermGen），替換為元空間（Metaspace））
（3）：虛擬機器棧<執行緒執行方法的時候內部存區域性變數會存堆中物件的地址等等資料>
（4）：本地方法棧<存放各種native方法的區域性變數表之類的資訊>
（5）：程式計數器<記錄當前執行緒執行到哪一條位元組碼指令位置>
物件4種引用
（1）：強（記憶體洩露主因）
（2）：軟（只有軟引用的話，空間不足將被回收），適合快取用
（3）：弱（只，GC會回收）
（4）：虛引用（用於跟蹤GC狀態）用於管理堆外記憶體
物件的構成：
一個物件分為3個區域：物件頭、例項資料、對齊填充
物件頭：主要是包括兩部分，1.儲存自身的執行時資料比如hash碼，分代年齡，鎖標記等（但是不是絕對哦，鎖狀態如果是偏向鎖，輕量級鎖，是沒有hash碼的。。。是不固定的）2.指向類的後設資料指標。還有可能存在第三部分，那就是陣列型別，會多一塊記錄陣列的長度（因為陣列的長度是jvm判斷不出來的，jvm只有後設資料資訊）
例項資料：會根據虛擬機器分配策略來定，分配策略中，會把相同大小的型別放在一起，並按照定義順序排列（父類的變數也會在哦）
對齊填充：這個意義不是很大，主要在虛擬機器規範中物件必須是8位元組的整數，所以當物件不滿足這個情況時，就會用佔位符填充
如果判斷一個物件是否存活：
一般判斷物件是否存活有兩種演算法，一種是引用計數，另外一種是可達性分析。在java中主要是第二種
java是根據什麼來執行可達性分析的：
根據GC ROOTS。GC ROOTS可以的物件有：虛擬機器棧中的引用物件，方法區的類變數的引用，方法區中的常量引用，本地方法棧中的物件引用。
JVM 類載入順序
（1）：載入 獲取類的二進位制位元組流，將其靜態儲存結構轉化為方法區的執行時資料結構
（2）：校驗 檔案格式驗證，後設資料驗證，位元組碼驗證，符號引用驗證
（3）：準備 在方法區中對類的static變數分配記憶體並設定類變數資料型別預設的初始值，不包括例項變數，例項變數將會在物件例項化的時候隨著物件一起分配在Java堆中
（4）：解析 將常量池內的符號引用替換為直接引用的過程
（5）：初始化 為類的靜態變數賦予正確的初始值（Java程式碼中被顯式地賦予的值）
JVM三種類載入器
（1）：啟動類載入器（home） 載入jvm核心類庫，如java.lang.*等
（2）：擴充套件類載入器（ext）， 父載入器為啟動類載入器，從jre/lib/ext下載入類庫
（3）：應用程式類載入器（使用者classpath路徑） 父載入器為擴充套件類載入器，從環境變數中載入類
雙親委派機制
（1）：類載入器收到類載入的請求
（2）：把這個請求委託給父載入器去完成，一直向上委託，直到啟動類載入器
（3）：啟動器載入器檢查能不能載入，能就載入（結束）；否則，丟擲異常，通知子載入器進行載入
（4）：保障類的唯一性和安全性以及保證JDK核心類的優先載入
雙親委派模型有啥作用：
保證java基礎類在不同的環境還是同一個Class物件，避免出現了自定義類覆蓋基礎類的情況，導致出現安全問題。還可以避免類的重複載入。
如何打破雙親委派模型？
（1）：自定義類載入器，繼承ClassLoader類重寫loadClass方法；
（2）：SPI
tomcat是如何打破雙親委派模型：
tomcat有著特殊性，它需要容納多個應用，需要做到應用級別的隔離，而且需要減少重複性載入，所以劃分為：/common 容器和應用共享的類資訊，/server容器本身的類資訊，/share應用通用的類資訊,/WEB-INF/lib應用級別的類資訊。整體可以分為：boostrapClassLoader->ExtensionClassLoader->ApplicationClassLoader->CommonClassLoader->CatalinaClassLoader（容器本身的載入器）/ShareClassLoader（共享的）->WebAppClassLoader。雖然第一眼是滿足雙親委派模型的，但是不是的，因為雙親委派模型是要先提交給父類裝載，而tomcat是優先判斷是否是自己負責的檔案位置，進行載入的。
SPI： （Service Provider interface）
（1）：服務提供介面（服務發現機制）：
（2）：通過載入ClassPath下META_INF/services，自動載入檔案裡所定義的類
（3）：通過ServiceLoader.load/Service.providers方法通過反射拿到實現類的例項
SPI應用?
（1）：應用於JDBC獲取資料庫驅動連線過程就是應用這一機制
（2）：apache最早提供的common-logging只有介面.沒有實現..發現日誌的提供商通過SPI來具體找到日誌提供商實現類
雙親委派機制缺陷?
（1）：雙親委派核心是越基礎的類由越上層的載入器進行載入， 基礎的類總是作為被呼叫程式碼呼叫的API，無法實現基礎類呼叫使用者的程式碼….
（2）：JNDI服務它的程式碼由啟動類載入器去載入，但是他需要調獨立廠商實現的應用程式，如何解決? 執行緒上下檔案類載入器（Thread Context ClassLoader）， JNDI服務使用這個執行緒上下文類載入器去載入所需要的SPI程式碼，也就是父類載入器請求子類載入器去完成類載入動作Java中所有涉及SPI的載入動作基本上都採用這種方式，例如JNDI，JDBC
導致fullGC的原因
（1）：老年代空間不足
（2）：永久代（方法區）空間不足
（3）：顯式呼叫system.gc（）
堆外記憶體的優缺點
Ehcache中的一些版本，各種 NIO 框架，Dubbo，Memcache 等中會用到，NIO包下ByteBuffer來建立堆外記憶體 堆外記憶體，其實就是不受JVM控制的記憶體。
相比於堆內記憶體有幾個優勢：
減少了垃圾回收的工作，因為垃圾回收會暫停其他的工作。 加快了複製的速度。因為堆內在 flush 到遠端時，會先複製到直接記憶體（非堆記憶體），然後在傳送；而堆外記憶體相當於省略掉了複製這項工作。 可以擴充套件至更大的記憶體空間。比如超過 1TB 甚至比主存還大的空間。
缺點總結如下：
堆外記憶體難以控制，如果記憶體洩漏，那麼很難排查，通過-XX：MaxDirectMemerySize來指定，當達到閾值的時候，呼叫system.gc來進行一次full gc 堆外記憶體相對來說，不適合儲存很複雜的物件。一般簡單的物件或者扁平化的比較適合 jstat檢視記憶體回收概況，實時檢視各個分割槽的分配回收情況， jmap檢視記憶體棧，檢視記憶體中物件佔用大小， jstack檢視執行緒棧，死鎖，效能瓶頸
JVM七種垃圾收集器
（1）： Serial 收集器 複製演算法，單執行緒，新生代）
（2）： ParNew 收集器（複製演算法，多執行緒，新生代）
（3）： Parallel Scavenge 收集器（多執行緒，複製演算法，新生代，高吞吐量）
（4）：Serial Old 收集器（標記-整理演算法，老年代）
（5）：Parallel Old 收集器（標記-整理演算法，老年代，注重吞吐量的場景下，jdk8預設採用 Parallel Scavenge + Parallel Old 的組合）
（6）：CMS 收集器（標記-清除演算法，老年代，垃圾回收執行緒幾乎能做到與使用者執行緒同時工作，吞吐量低，記憶體碎片）以犧牲吞吐量為代價來獲得最短回收停頓時間-XX：+UseConcMarkSweepGC jdk1.8 預設垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代） jdk1.9 預設垃圾收集器G1
使用場景：
（1）：應用程式對停頓比較敏感
（2）：在JVM中，有相對較多存活時間較長的物件（老年代比較大）會更適合使用CMS
cms垃圾回收過程：
（1）：初始標識<找到gcroot（stw）>
GC Roots有以下幾種：
1：系統類載入器載入的物件
2：處於啟用狀態的執行緒
3：JNI棧中的物件
4：正在被用於同步的各種鎖物件
5：JVM自身持有的物件，比如系統類載入器等。
（2）：併發標記（三色標記演算法） 三色標記演算法處理併發標記出現物件引用變化情況： 黑：自己+子物件標記完成 灰：自己完成，子物件未完成 白：未標記； 併發標記 黑->灰->白 重新標記 灰->白引用消失，黑引用指向->白，導致白漏標 cms處理辦法是incremental update方案 （增量更新）把黑色變成灰色 多執行緒下併發標記依舊會產生漏標問題，所以cms必須remark一遍（jdk1.9以後不用cms了）
G1 處理方案：
SATB（snapshot at the begining）把白放入棧中，標記過程是和應用程式併發執行的（不需要Stop-The-World） 這種方式會造成某些是垃圾的物件也被當做是存活的，所以G1會使得佔用的記憶體被實際需要的記憶體大。不過下一次就回收了 ZGC 處理方案： 顏色指標（color pointers） 2*42方=4T
（3）：重新標記（stw）
（4）併發清理
備註：重新標記是防止標記成垃圾之後，物件被引用
（5）：G1 收集器（新生代 + 老年代，在多 CPU 和大記憶體的場景下有很好的效能） G1在java9 便是預設的垃圾收集器，是cms 的替代者 邏輯分代，用分割槽（region）的思想（預設分2048份） 還是有stw 為解決CMS演算法產生空間碎片HotSpot提供垃圾收集器，通過-XX：+UseG1GC來啟用
G1中提供了三種模式垃圾回收模式
（1）：young gc（eden region被耗盡無法申請記憶體時，就會觸發）
（2）：mixed gc（當老年代大小佔整個堆大小百分比達到該閾值時，會觸發）
（3）：full gc（物件記憶體分配速度過快，mixed gc來不及回收，導致老年代被填滿，就會觸發）
（8）：ZGC和shenandoah （oracle產收費） no stw
arthas 監控工具
（1）：dashboard命令檢視總體jvm執行情況
（2）：jvm顯示jvm詳細資訊
（3）：thread 顯示jvm裡面所有執行緒資訊（類似於jstack） 檢視死鎖執行緒命令thread -b
（4）：sc * 顯示所有類（search class）
（5）：trace 跟蹤方法
定位頻繁full GC，堆記憶體滿 oom
第一步：jps獲取程式號 第二步：jmap -histo pid | head -20 得知有個物件在不斷建立 備註：jmap如果線上伺服器堆記憶體特別大，，會卡死需堆轉存（一般會說在測試環境壓測，匯出轉存） -XX：+HeapDumpOnOutOfMemoryError或jmap -dumpLformat=b，file=xxx pid 轉出檔案進行分析 （arthas沒有實現jmap命令）heapdump --live /xxx/xx.hprof匯出檔案
G1垃圾回收器（重點）
回收過程 （1）：young gc（年輕代回收）--當年輕代的Eden區用盡時--stw 第一階段，掃描根。 根是指static變數指向的物件，正在執行的方法呼叫鏈條上的區域性變數等 第二階段，更新RS（Remembered Sets）。 處理dirty card queue中的card，更新RS。此階段完成後，RS可以準確的反映老年代對所在的記憶體分段中物件的引用 第三階段，處理RS。 識別被老年代物件指向的Eden中的物件，這些被指向的Eden中的物件被認為是存活的物件。 第四階段，複製物件。 此階段，物件樹被遍歷，Eden區記憶體段中存活的物件會被複制到Survivor區中空的記憶體分段 第五階段，處理引用。 處理Soft，Weak，Phantom，Final，JNI Weak 等引用。
（2）：concrruent marking（老年代併發標記） 當堆記憶體使用達到一定值（預設45%）時，不需要Stop-The-World，在併發標記前先進行一次young gc
（3）：混合回收（mixed gc） 併發標記過程結束以後，緊跟著就會開始混合回收過程。混合回收的意思是年輕代和老年代會同時被回收
（4）：Full GC? Full GC是指上述方式不能正常工作，G1會停止應用程式的執行，使用單執行緒的記憶體回收演算法進行垃圾回收，效能會非常差，應用程式停頓時間會很長。要避免Full GC的發生，一旦發生需要進行調整。
什麼時候發生Full GC呢？
比如堆記憶體太小，當G1在複製存活物件的時候沒有空的記憶體分段可用，則會回退到full gc，這種情況可以通過增大記憶體解決
儘管G1堆記憶體仍然是分代的，但是同一個代的記憶體不再採用連續的記憶體結構
年輕代分為Eden和Survivor兩個區，老年代分為Old和Humongous兩個區
新分配的物件會被分配到Eden區的記憶體分段上
Humongous區用於儲存大物件，如果一個物件佔用的空間超過記憶體分段Region的一半；
如果物件的大小超過一個甚至幾個分段的大小，則物件會分配在物理連續的多個Humongous分段上。
Humongous物件因為佔用記憶體較大並且連續會被優先回收
為了在回收單個記憶體分段的時候不必對整個堆記憶體的物件進行掃描（單個記憶體分段中的物件可能被其他記憶體分段中的物件引用）引入了RS資料結構。RS使得G1可以在年輕代回收的時候不必去掃描老年代的物件，從而提高了效能。每一個記憶體分段都對應一個RS，RS儲存了來自其他分段內的物件對於此分段的引用
JVM會對應用程式的每一個引用賦值語句object.field=object進行記錄和處理，把引用關係更新到RS中。但是這個RS的更新並不是實時的。G1維護了一個Dirty Card Queue
那為什麼不在引用賦值語句處直接更新RS呢？
這是為了效能的需要，使用佇列效能會好很多。
執行緒本地分配緩衝區（TLAB： Thread Local Allocation Buffer）?
棧上分配->tlab->堆上分配 由於堆記憶體是應用程式共享的，應用程式的多個執行緒在分配記憶體的時候需要加鎖以進行同步。為了避免加鎖，提高效能每一個應用程式的執行緒會被分配一個TLAB。TLAB中的記憶體來自於G1年輕代中的記憶體分段。當物件不是Humongous物件，TLAB也能裝的下的時候，物件會被優先分配於建立此物件的執行緒的TLAB中。這樣分配會很快，因為TLAB隸屬於執行緒，所以不需要加鎖
PLAB： Promotion Thread Local Allocation Buffer
G1會在年輕代回收過程中把Eden區中的物件複製（“提升”）到Survivor區中，Survivor區中的物件複製到Old區中。G1的回收過程是多執行緒執行的，為了避免多個執行緒往同一個記憶體分段進行復制，那麼複製的過程也需要加鎖。為了避免加鎖，G1的每個執行緒都關聯了一個PLAB，這樣就不需要進行加鎖了
OOM問題定位方法
（1）：jmap -heap 10765如上圖，可以檢視新生代，老生代堆記憶體的分配大小以及使用情況；
（2）：jstat 檢視GC收集情況
（3）：jmap -dump：live，format=b，file=到本地
（4）：通過MAT工具開啟分析
DUBBO
dubbo流程
（1）：生產者（Provider）啟動，向註冊中心（Register）註冊
（2）：消費者（Consumer）訂閱，而後註冊中心通知消費者
（3）：消費者從生產者進行消費
（4）：監控中心（Monitor）統計生產者和消費者
Dubbo推薦使用什麼序列化框架，還有哪些？
推薦使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化
Dubbo預設使用的是什麼通訊框架，還有哪些？
預設使用 Netty 框架，也是推薦的選擇，另外內容還整合有Mina、Grizzly。
Dubbo有哪幾種負載均衡策略，預設是哪種?
（1）：隨機呼叫<預設>
（2）：權重輪詢
（3）：最少活躍數
（4）：一致性Hash
RPC流程
（1）消費者呼叫需要消費的服務，
（2）：客戶端存根將方法、入參等資訊序列化傳送給服務端存根
（3）：服務端存根反序列化操作根據解碼結果呼叫本地的服務進行相關處理
（4）：本地服務執行具體業務邏輯並將處理結果返回給服務端存根
（5）：服務端存根序列化
（6）：客戶端存根反序列化
（7）：服務消費方得到最終結果
RPC框架的實現目標PC框架的實現目標是把呼叫、編碼/解碼的過程給封裝起來，讓使用者感覺上像呼叫本地服務一樣的呼叫遠端服務
服務暴露、服務引用、服務呼叫（TODO）
Redis
redis單執行緒為什麼執行速度這麼快?
（1）：純記憶體操作，避免大量訪問資料庫，減少直接讀取磁碟資料，redis將資料儲存在記憶體裡面，讀寫資料的時候都不會受到硬碟 I/O 速度的限制，所以速度快
（2）：單執行緒操作，避免了不必要的上下文切換和競爭條件，也不存在多程式或者多執行緒導致的切換而消耗CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的效能消耗
（3）：採用了非阻塞I/O多路複用機制
Redis資料結構底層實現
String：
（1）Simple dynamic string（SDS）的資料結構
struct sdshdr{
//記錄buf陣列中已使用位元組的數量
//等於 SDS 儲存字串的長度
int len；
//記錄 buf 陣列中未使用位元組的數量
int free；
//位元組陣列，用於儲存字串
char buf[]；
}
它的優點： （1）不會出現字串變更造成的記憶體溢位問題
（2）獲取字串長度時間複雜度為1
（3）空間預分配， 惰性空間釋放free欄位，會預設留夠一定的空間防止多次重分配記憶體
應用場景： String 快取結構體使用者資訊，計數
Hash：
陣列+連結串列的基礎上，進行了一些rehash優化； 1.Reids的Hash採用鏈地址法來處理衝突，然後它沒有使用紅黑樹優化。
2.雜湊表節點採用單連結串列結構。
3.rehash優化 （採用分而治之的思想，將龐大的遷移工作量劃分到每一次CURD中，避免了服務繁忙）
應用場景： 儲存結構體資訊可部分獲取不用序列化所有欄位
List：
應用場景： （1）：比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現
（2）：list的實現為一個雙向連結串列，即可以支援反向查詢和遍歷
Set：
內部實現是一個 value為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員 是否在集合內的原因。 應用場景： 去重的場景，交集（sinter）、並集（sunion）、差集（sdiff），實現如共同關注、共同喜好、二度好友等功能
Zset：
內部使用HashMap和跳躍表（SkipList）來保證資料的儲存和有序，HashMap裡放的是成員到score的對映，而跳躍表裡存放的是所有的成員，排序依據是HashMap裡存的score，使用跳躍表的結構可以獲得比較高的查詢效率，並且在實現上比較簡單。 跳錶：每個節點中維持多個指向其他節點的指標，從而達到快速訪問節點的目的 應用場景： 實現延時佇列
redis事務
（1）：Multi開啟事務
（2）：Exec執行事務塊內命令
（3）：Discard 取消事務
（4）：Watch 監視一個或多個key，如果事務執行前key被改動，事務將打斷
redis事務的實現特徵
（1）：所有命令都將會被序列化的順序執行，事務執行期間，Redis不會再為其它客戶端的請求提供任何服務，從而保證了事物中的所有命令被原子的執行
（2）：Redis事務中如果有某一條命令執行失敗，其後的命令仍然會被繼續執行
（3）：在事務開啟之前，如果客戶端與伺服器之間出現通訊故障並導致網路斷開，其後所有待執行的語句都將不會被伺服器執行。然而如果網路中斷事件是發生在客戶端執行EXEC命令之後，那麼該事務中的所有命令都會被伺服器執行
（4）：當使用Append-Only模式時，Redis會通過呼叫系統函式write將該事務內的所有寫操作在本次呼叫中全部寫入磁碟。
然而如果在寫入的過程中出現系統崩潰，如電源故障導致的當機，那麼此時也許只有部分資料被寫入到磁碟，而另外一部分資料卻已經丟失。
Redis伺服器會在重新啟動時執行一系列必要的一致性檢測，一旦發現類似問題，就會立即退出並給出相應的錯誤提示。此時，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到資料不一致的錯誤，並將已經寫入的部分資料進行回滾。修復之後我們就可以再次重新啟動Redis伺服器了
Redis的同步機制？
（1）：全量拷貝， 1.slave第一次啟動時，連線Master，傳送PSYNC命令，
2.master會執行bgsave命令來生成rdb檔案，期間的所有寫命令將被寫入緩衝區。
master bgsave執行完畢，向slave傳送rdb檔案
slave收到rdb檔案，丟棄所有舊資料，開始載入rdb檔案
rdb檔案同步結束之後，slave執行從master緩衝區傳送過來的所以寫命令。
此後 master 每執行一個寫命令，就向slave傳送相同的寫命令。
（2）：增量拷貝 如果出現網路閃斷或者命令丟失等異常情況，從節點之前儲存了自身已複製的偏移量和主節點的執行ID
主節點根據偏移量把複製積壓緩衝區裡的資料傳送給從節點，保證主從複製進入正常狀態。
redis叢集模式效能優化
（1） Master最好不要做任何持久化工作，如RDB記憶體快照和AOF日誌檔案
（2） 如果資料比較重要，某個Slave開啟AOF備份資料，策略設定為每秒同步一次
（3） 為了主從複製的速度和連線的穩定性，Master和Slave最好在同一個區域網內
（4） 儘量避免在壓力很大的主庫上增加從庫
（5） 主從複製不要用圖狀結構，用單向連結串列結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3…這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。
Redis叢集方案
（1）：官方cluster方案
（2）：twemproxy
代理方案twemproxy是一個單點，很容易對其造成很大的壓力，所以通常會結合keepalived來實twemproy的高可用
（3）：codis 基於客戶端來進行分片
叢集不可用場景
（1）：master掛掉，且當前master沒有slave
（2）：叢集超過半數以上master掛掉，無論是否有slave叢集進入fail狀態
redis 最適合的場景
（1）：會話快取session cache
（2）：排行榜/計數器ZRANGE
（3）：釋出/訂閱
快取淘汰策略
（1）：先進先出演算法（FIFO）
（2）：最近使用最少Least Frequently Used（LFU）
（3）：最長時間未被使用的Least Recently Used（LRU）
當存在熱點資料時，LRU的效率很好，但偶發性的、週期性的批量操作會導致LRU命中率急劇下降，快取汙染情況比較嚴重
redis過期key刪除策略
（1）：惰性刪除，cpu友好，但是浪費cpu資源
（2）：定時刪除（不常用）
（3）：定期刪除，cpu友好，節省空間
快取雪崩以及處理辦法
同一時刻大量快取失效；
處理方法：
（1）：快取資料增加過期標記
（2）：設定不同的快取失效時間
（3）：雙層快取策略C1為短期，C2為長期
（4）：定時更新策略
快取擊穿原因以及處理辦法
頻繁請求查詢系統中不存在的資料導致；
處理方法：
（1）：cache null策略，查詢反饋結果為null仍然快取這個null結果，設定不超過5分鐘過期時間
（2）：布隆過濾器，所有可能存在的資料對映到足夠大的bitmap中 google布隆過濾器：基於記憶體，重啟失效不支援大資料量，無法在分散式場景 redis布隆過濾器：可擴充套件性，不存在重啟失效問題，需要網路io，效能低於google
redis阻塞原因
（1）：資料結構使用不合理bigkey
（2）：CPU飽和
（3）：持久化阻塞，rdb fork子執行緒，aof每秒刷盤等
hot key出現造成叢集訪問量傾斜解決辦法
（1）：使用本地快取
（2）： 利用分片演算法的特性，對key進行打散處理（給hot key加上字首或者字尾，把一個hotkey 的數量變成 redis 例項個數N的倍數M，從而由訪問一個 redis key 變成訪問 N * M 個redis key）
Redis分散式鎖
2.6版本以後lua指令碼保證setnx跟setex進行原子性（setnx之後，未setex，服務掛了，鎖不釋放） a獲取鎖，超過過期時間，自動釋放鎖，b獲取到鎖執行，a程式碼執行完remove鎖，a和b是一樣的key，導致a釋放了b的鎖。 解決辦法：remove之前判斷value（高併發下value可能被修改，應該用lua來保證原子性）
Redis如何做持久化
bgsave做映象全量持久化，aof做增量持久化。因為bgsave會耗費較長時間，不夠實時，在停機的時候會導致大量丟失資料 ，所以需要aof來配合使用。在redis例項重啟時，會使用bgsave持久化檔案重新構建記憶體，再使用aof重放近期的操作指令來 實 現完整恢復重啟之前的狀態。
對方追問那如果突然機器掉電會怎樣？
取決於aof日誌sync屬性的配置，如果不要求效能，在每條寫指令時都sync一下磁碟，就不會丟失資料。但是在高效能的要求下每次都sync是不現實的，一般都使用定時sync，比如1s1次，這個時候最多就會丟失1s的資料.
redis鎖續租問題?
（1）：基於redis的redission分散式可重入鎖RLock，以及配合java集合中lock；
（2）：Redission 內部提供了一個監控鎖的看門狗，不斷延長鎖的有效期，預設檢查鎖的超時時間是30秒
（3）：此方案的問題：如果你對某個redis master例項，寫入了myLock這種鎖key的value，此時會非同步複製給對應的master ，slave例項。但是這個過程中一旦發生redis master當機，主備切換，redis slave變為了redis master。
接著就會導致，客戶端2來嘗試加鎖的時候，在新的redis master上完成了加鎖，而客戶端1也以為自己成功加了鎖。 此時就會導致多個客戶端對一個分散式鎖完成了加鎖 解決辦法：只需要將新的redis例項，在一個TTL時間內，對客戶端不可用即可，在這個時間內，所有客戶端鎖將被失效或者自動釋放.
bgsave的原理是什麼？
fork和cow。fork是指redis通過建立子程式來進行bgsave操作，cow指的是copy on write，子程式建立後，父子程式共享資料段，父程式繼續提供讀寫服務，寫進的頁面資料會逐漸和子程式分離開來。
RDB與AOF區別
（1）：R檔案格式緊湊，方便資料恢復，儲存rdb檔案時父程式會fork出子程式由其完成具體持久化工作，最大化redis效能，恢復大資料集速度更快，只有手動提交save命令或關閉命令時才觸發備份操作；
（2）：A記錄對伺服器的每次寫操作（預設1s寫入一次），儲存資料更完整，在redis重啟是會重放這些命令來恢復資料，操作效率高，故障丟失資料更少，但是檔案體積更大；
1億個key，其中有10w個key是以某個固定的已知的字首開頭的，如果將它們全部找出來？
使用keys指令可以掃出指定模式的key列表。 如果這個redis正在給線上的業務提供服務，那使用keys指令會有什麼問題？ redis的單執行緒的。keys指令會導致執行緒阻塞一段時間，線上服務會停頓，直到指令執行完畢，服務才能恢復。這個時候可以使用scan指令，scan指令可以無阻塞的提取出指定模式的key列表，但是會有一定的重複概率，在客戶端做一次去重就可以了 ，但是整體所花費的時間會比直接用keys指令長。
如何使用Redis做非同步佇列?
一般使用list結構作為佇列，rpush生產訊息，lpop消費訊息。當lpop沒有訊息的時候，要適當sleep一會再重試。
可不可以不用sleep呢？
list還有個指令叫blpop，在沒有訊息的時候，它會阻塞住直到訊息到來。
能不能生產一次消費多次呢？
使用pub/sub主題訂閱者模式，可以實現1：N的訊息佇列。
pub/sub有什麼缺點？
在消費者下線的情況下，生產的訊息會丟失，得使用專業的訊息佇列如rabbitmq等。
redis如何實現延時佇列？
使用sortedset，想要執行時間的時間戳作為score，訊息內容作為key呼叫zadd來生產訊息，消費者用zrangebyscore指令獲取N秒之前的資料輪詢進行處理。
為啥redis zset使用跳躍連結串列而不用紅黑樹實現?
（1）：skiplist的複雜度和紅黑樹一樣，而且實現起來更簡單。
（2）：在併發環境下紅黑樹在插入和刪除時需要rebalance，效能不如跳錶。
MYSQL
資料庫三正規化
一： 確保每列的原子性
二：非主鍵列不存在對主鍵的部分依賴 （要求每個表只描述一件事情）
三： 滿足第二正規化，並且表中的列不存在對非主鍵列的傳遞依賴
資料庫主從複製原理
（1）：主庫db的更新事件（update、insert、delete）被寫到binlog
（2）：主庫建立一個binlog dump thread執行緒，把binlog的內容傳送到從庫
（3）：從庫建立一個I/O執行緒，讀取主庫傳過來的binlog內容並寫入到relay log.
（4）：從庫還會建立一個SQL執行緒，從relay log裡面讀取內容寫入到slave的db.
複製方式分類
（1）：非同步複製（預設） 主庫寫入binlog日誌後即可成功返回客戶端，無須等待binlog日誌傳遞給從庫的過程，但是一旦主庫當機，就有可能出現丟失資料的情況。
（2）半同步複製：（ 5.5版本之後） （安裝半同步複製外掛）確保從庫接收完成主庫傳遞過來的binlog內容已經寫入到自己的relay log（傳送log）後才會通知主庫上面的等待執行緒。如果等待超時，則關閉半同步複製，並自動轉換為非同步複製模式，直到至少有一臺從庫通知主庫已經接收到binlog資訊為止
儲存引擎
（1）：Myiasm是mysql預設的儲存引擎，不支援資料庫事務，行級鎖，外來鍵；插入更新需鎖表，效率低，查詢速度快，Myisam使用的是非聚集索引
（2）：innodb 支援事務，底層為B+樹實現，適合處理多重併發更新操作，普通select都是快照讀，快照讀不加鎖。InnoDb使用的是聚集索引
聚集索引
（1）：聚集索引就是以主鍵建立的索引
（2）：每個表只能有一個聚簇索引，因為一個表中的記錄只能以一種物理順序存放，實際的資料頁只能按照一顆 B+ 樹進行排序
（3）：表記錄的排列順序和與索引的排列順序一致
（4）：聚集索引儲存記錄是物理上連續存在
（5）：聚簇索引主鍵的插入速度要比非聚簇索引主鍵的插入速度慢很多
（6）：聚簇索引適合排序，非聚簇索引不適合用在排序的場合，因為聚簇索引葉節點本身就是索引和資料按相同順序放置在一起，索引序即是資料序，資料序即是索引序，所以很快。非聚簇索引葉節點是保留了一個指向資料的指標，索引本身當然是排序的，但是資料並未排序，資料查詢的時候需要消耗額外更多的I/O，所以較慢
（7）：更新聚集索引列的代價很高，因為會強制innodb將每個被更新的行移動到新的位置
非聚集索引
（1）：除了主鍵以外的索引
（2）：聚集索引的葉節點就是資料節點，而非聚簇索引的葉節點仍然是索引節點，並保留一個連結指向對應資料塊
（3）：聚簇索引適合排序，非聚簇索引不適合用在排序的場合
（4）：聚集索引儲存記錄是物理上連續存在，非聚集索引是邏輯上的連續。
使用聚集索引為什麼查詢速度會變快？
使用聚簇索引找到包含第一個值的行後，便可以確保包含後續索引值的行在物理相鄰
建立聚集索引有什麼需要注意的地方嗎？
在聚簇索引中不要包含經常修改的列，因為碼值修改後，資料行必須移動到新的位置，索引此時會重排，會造成很大的資源浪費
InnoDB 表對主鍵生成策略是什麼樣的？
優先使用使用者自定義主鍵作為主鍵，如果使用者沒有定義主鍵，則選取一個Unique鍵作為主鍵，如果表中連Unique鍵都沒有定義的話，則InnoDB會為表預設新增一個名為row_id隱藏列作為主鍵。
非聚集索引最多可以有多少個？
每個表你最多可以建立249個非聚簇索引。非聚簇索引需要大量的硬碟空間和記憶體
BTree 與 Hash 索引有什麼區別？
（1）：BTree索引可能需要多次運用折半查詢來找到對應的資料塊 （2）：HASH索引是通過HASH函式，計算出HASH值，在表中找出對應的資料 （3）：大量不同資料等值精確查詢，HASH索引效率通常比B+TREE高 （4）：HASH索引不支援模糊查詢、範圍查詢和聯合索引中的最左匹配規則，而這些Btree索引都支援
資料庫索引優缺點
（1）：需要查詢，排序，分組和聯合操作的欄位適合建立索引
（2）：索引多，資料更新表越慢，儘量使用欄位值不重複比例大的欄位作為索引，聯合索引比多個獨立索引效率高
（3）：對資料進行頻繁查詢進建立索引，如果要頻繁更改資料不建議使用索引
（4）：當對錶中的資料進行增加、刪除和修改的時候，索引也要動態的維護，降低了資料的維護速度。
索引的底層實現是B+樹，為何不採用紅黑樹，B樹?
（1）：B+Tree非葉子節點只儲存鍵值資訊，降低B+Tree的高度，所有葉子節點之間都有一個鏈指標，資料記錄都存放在葉子節點中
（2）： 紅黑樹這種結構，h明顯要深的多，效率明顯比B-Tree差很多
（3）：B+樹也存在劣勢，由於鍵會重複出現，因此會佔用更多的空間。但是與帶來的效能優勢相比，空間劣勢往往可以接受，因此B+樹的在資料庫中的使用比B樹更加廣泛
索引失效條件
（1）：條件是or，如果還想讓or條件生效，給or每個欄位加個索引
（2）：like開頭%
（3）：如果列型別是字串，那一定要在條件中將資料使用引號引用起來，否則不會使用索引
（4）：where中索引列使用了函式或有運算
資料庫事務特點
ACID 原子性，一致性，隔離性，永久性
資料庫事務說是如何實現的?
（1）：通過預寫日誌方式實現的，redo和undo機制是資料庫實現事務的基礎
（2）：redo日誌用來在斷電/資料庫崩潰等狀況發生時重演一次刷資料的過程，把redo日誌裡的資料刷到資料庫裡，保證了事務 的永續性（Durability）
（3）：undo日誌是在事務執行失敗的時候撤銷對資料庫的操作，保證了事務的原子性
資料庫事務隔離級別
（1）：讀未提交read-uncommitted-- 髒，不可重複讀--幻讀 A讀取了B未提交的事務，B回滾，A 出現髒讀；
（2）：不可重複讀read-committed-- 不可重複讀--幻讀 A只能讀B已提交的事務，但是A還沒結束，B又更新資料隱式提交，然後A又讀了一次出現不可重複讀；
（3）：可重複讀repeatable-read<預設>-- 幻讀 事務開啟，不允許其他事務的UPDATE修改操作 A讀取B已提交的事務，然而B在該表插入新的行，之後A在讀取的時候多出一行，出現幻讀；
（4）：序列化serializable--
七種事務傳播行為
（1）Propagation.REQUIRED<預設> 如果當前存在事務，則加入該事務，如果當前不存在事務，則建立一個新的事務。
（2）Propagation.SUPPORTS 如果當前存在事務，則加入該事務；如果當前不存在事務，則以非事務的方式繼續執行。
（3）Propagation.MANDATORY 如果當前存在事務，則加入該事務；如果當前不存在事務，則丟擲異常。
（4）Propagation.REQUIRES_NEW 重新建立一個新的事務，如果當前存在事務，延緩當前的事務。
（5）Propagation.NOT_SUPPORTED 以非事務的方式執行，如果當前存在事務，暫停當前的事務。
（6）Propagation.NEVER 以非事務的方式執行，如果當前存在事務，則丟擲異常。
（7）Propagation.NESTED 如果沒有，就新建一個事務；如果有，就在當前事務中巢狀其他事務。
產生死鎖的四個必要條件
（1）：互斥： 資源x的任意一個時刻只能被一個執行緒持有 （2）：佔有且等待：執行緒1佔有資源x的同時等待資源y，並不釋放x （3）：不可搶佔：資源x一旦被執行緒1佔有，其他執行緒不能搶佔x （4）：迴圈等待：執行緒1持有x，等待y，執行緒2持有y，等待x 當全部滿足時才會死鎖
@Transaction
底層實現是AOP，動態代理 （1）：實現是通過Spring代理來實現的。生成當前類的代理類，呼叫代理類的invoke（）方法，在invoke（）方法中呼叫 TransactionInterceptor攔截器的invoke（）方法；
（2）：非public方式其事務是失效的；
（3）：自呼叫也會失效，因為動態代理機制導致
（4）多個方法外層加入try...catch，解決辦法是可以在catch裡 throw new RuntimeException（）來處理
分散式事務
XA方案
有一個事務管理器的概念，負責協調多個資料庫（資源管理器）的事務 不適合高併發場景，嚴重依賴資料庫層面，同步阻塞問題；協調者故障則所有參與者會阻塞
TCC方案
嚴重依賴程式碼補償和回滾，一般銀行用，和錢相關的支付、交易等相關的場景，我們會用TCC Try，對各個服務的資源做檢測，對資源進行鎖定或者預留 Confirm，在各個服務中執行實際的操作 Cancel，如果任何一個服務的業務方法執行出錯，那麼這裡就需要進行補償，即執行已操作成功的業務邏輯的回滾操作
可靠訊息最終一致性方案
1）：本地訊息服務 本地訊息表其實是國外的 ebay 搞出來的這麼一套思想。 主動方是認證服務，有個訊息異常處理系統，mq，還有訊息消費端應用系統，還有采集服務；
在我認證返回資料中如果有發票是已經認證的，在處理認證資料的操作與傳送訊息在同一個本地事務中，業務執行完，訊息資料也同時存在一條待確認的資料； 傳送訊息給mq，，mq傳送訊息給訊息消費端服務，同時存一份訊息資料，然後傳送給採集服務，進行抵賬表更新操作； 採集服務邏輯處理完以後反饋給訊息消費端服務，其服務刪除訊息資料，同時通知認證服務，把訊息記錄改為已確認成功費狀態； 對於異常流程，訊息異常處理系統會查詢認證服務中過期未確認的訊息傳送給mq，相當於重試
2）：獨立訊息最終一致性方案： A 主動方應用系統，B訊息服務子系統，C訊息狀態確認子系統，C2訊息管理子系統 D 訊息恢復子系統，mq ，訊息消費端E ，被動系統F
流程：
A預傳送訊息給B，然後執行A業務邏輯，B儲存預傳送訊息，A執行完業務邏輯傳送業務操作結果給B，B更新預傳送訊息為確認併傳送訊息狀態同時傳送訊息給mq，然後被E監聽然後傳送給F消費掉
C：對預傳送訊息異常的處理，去查詢待確認狀態超時的訊息，去A中查詢進行資料處理，如果A中業務處理成功了，那麼C需改訊息狀態為確認併傳送狀態，然後傳送訊息給mq；如果A中業務處理失敗了..那麼C直接把訊息刪除即可.
C2 ： 查詢訊息的頁面，對訊息的視覺化，以及批量處理死亡訊息；
D： B給mq放入資料如果失敗，，通過D去重試，多次重試失敗，訊息設定為死亡
E：確保F執行完成，傳送訊息給B刪除訊息
優化建議：
（1）資料庫：如果用redis，持久化要配置成appendfsync always，確保每次新新增訊息都能持久化進磁碟
（2）在被動方應用業務冪等性判斷比較麻煩或者比較耗效能情況下，增加訊息日誌記錄表.用於判斷之前有無傳送過；
最大努力通知性（定期校對）
（1）業務主動方完成業務處理之後，設定時間階梯型通知規則向業務活動的被動方傳送訊息，允許訊息丟失.
（2）被動方根據定時策略，向主動方查詢，恢復丟失的業務訊息
（3）被動方的處理結果不影響主動方的處理結果
（4）需增加業務查詢，通知服務，校對系統服務的建設成本
（5）適用於對業務最終一致性的時間敏感度低，跨企業的業務通知活動
（6）比如銀行通知，商戶通知，交易業務平臺間商戶通知，多次通知，查詢校對等
Seata（阿里）
應用層基於SQL解析實現了自動補償，從而最大程度的降低業務侵入性； 將分散式事務中TC（事務協調者）獨立部署，負責事務的註冊、回滾； 通過全域性鎖實現了寫隔離與讀隔離。
網路
TCP和UDP的比較
TCP向上層提供面向連線的可靠服務 ，UDP向上層提供無連線不可靠服務。 雖然 UDP 並沒有 TCP 傳輸來的準確，但是也能在很多實時性要求高的地方有所作為 對資料準確性要求高，速度可以相對較慢的，可以選用TCP
TCP三次握手
TCP四次揮手
（1）：客戶端傳送終止命令FIN
（2）：服務端收到後回覆ACK，處於close_wait狀態
（3）：伺服器將關閉前需要傳送資訊傳送給客戶端後處於last_ack狀態
（4）：客戶端收到FIN後傳送ack後處於tim-wait而後進入close狀態
為什麼要進行第三次握手
為了防止伺服器端開啟一些無用的連線增加伺服器開銷以及防止已失效的連線請求報文段突然又傳送到了服務端
JDK1.8新特性
Lambda表示式
java也開始承認了函數語言程式設計， 就是說函式既可以作為引數，也可以作為返回值， 大大的簡化了程式碼的開發
default關鍵字
打破介面裡面是隻能有抽象方法，不能有任何方法的實現，介面裡面也可以有方法的實現了
新時間日期APILocalDate | LocalTime | LocalDateTime
之前使用的java.util.Date月份從0開始，我們一般會+1使用，很不方便，java.time.LocalDate月份和星期都改成了enum java.util.Date和SimpleDateFormat都不是執行緒安全的，而LocalDate和LocalTime和最基本的String一樣，是不變型別，不但執行緒安全，而且不能修改。 新介面更好用的原因是考慮到了日期時間的操作，經常發生往前推或往後推幾天的情況。用java.util.Date配合Calendar要寫好多程式碼，而且一般的開發人員還不一定能寫對。
JDK1.7與JDK1.8 ConcurrentHashMap對比
（1）：JDK1.7版本的ReentrantLock+Segment+HashEntry（陣列）
（2）：JDK1.7採用segment的分段鎖機制實現執行緒安全
（3）：JDK1.8版本中synchronized+CAS+HashEntry（陣列）+紅黑樹
（4）：JDK1.8採用CAS+Synchronized保證執行緒安全
（5）：查詢時間複雜度從原來的遍歷連結串列O（n），變成遍歷紅黑樹O（logN）
1.8 HashMap陣列+連結串列+紅黑樹來實現hashmap，當碰撞的元素個數大於8時 & 總容量大於64，會有紅黑樹的引入 除了新增之後，效率都比連結串列高，1.8之後連結串列新進元素加到末尾
JDK1.8使用synchronized來代替重入鎖ReentrantLock?
（1）：因為粒度降低了，在相對而言的低粒度加鎖方式，synchronized並不比ReentrantLock差
（2）：基於JVM的synchronized優化空間更大
（3）：在大資料量下，基於API的ReentrantLock會比基於JVM的記憶體壓力開銷更多的記憶體
JDK1.9新特性
模組系統：
模組是一個包的容器，Java 9 最大的變化之一是引入了模組系統（Jigsaw 專案）。
集合工廠方法
通常，您希望在程式碼中建立一個集合（例如，List 或 Set ），並直接用一些元素填充它。 例項化集合，幾個 “add” 呼叫，使得程式碼重複。 Java 9，新增了幾種集合工廠方法：
Set<Integer> ints = Set.of（1， 2， 3）；
List<String> strings = List.of（"first"， "second"）；
改進的 Stream API
Stream 介面中新增了 4 個新的方法：dropWhile， takeWhile， ofNullable。還有個 iterate 方法的新過載方法
改進的 Javadoc：
Javadoc 現在支援在 API 文件中的進行搜尋。另外，Javadoc 的輸出現在符合相容 HTML5 標準。
redis代理叢集模式，spring有哪些註解，b+b 紅黑樹區別，三次握手，valitile重排序底層程式碼， cas 事務的4個特性，java8 java11 特性， filter和interceptor的區別 @autowired原理， dispatcherservlet，分散式事務解決方案spring都有哪些模組，fork join佇列，排序演算法，
集合
java的集合框架有哪幾種：
兩種：collection和map，其中collection分為set和List。
List你使用過哪些
ArrayList和linkedList使用的最多，也最具代表性。
你知道vector和ArrayList和linkedList的區別嘛
ArrayList實現是一個陣列，可變陣列，預設初始化長度為10，也可以我們設定容量，但是沒有設定的時候是預設的空陣列，只有在第一步add的時候會進行擴容至10（重新建立了陣列），後續擴容按照3/2的大小進行擴容，是執行緒不安全的，適用多讀取，少插入的情況
linkedList是基於雙向連結串列的實現，使用了尾插法的方式，內部維護了連結串列的長度，以及頭節點和尾節點，所以獲取長度不需要遍歷。適合一些插入/刪除頻繁的情況。
Vector是執行緒安全的，實現方式和ArrayList相似，也是基於陣列，但是方法上面都有synchronized關鍵詞修飾。其擴容方式是原來的兩倍。
hashMap和hashTable和ConcurrentHashMap的區別
hashMap是map型別的一種最常用的資料結構，其底部實現是陣列+連結串列（在1.8版本後變為了陣列+連結串列/紅黑樹的方式），其key是可以為null的，預設hash值為0。擴容以2的冪等次（為什麼。。。因為只有是2的冪等次的時候（n-1）&x==x%n，當然不一定只有一個原因）。是執行緒不安全的
hashTable的實現形式和hashMap差不多，它是執行緒安全的，是繼承了Dictionary，也是key-value的模式，但是其key不能為null。
ConcurrentHashMap是JUC併發包的一種，在hashMap的基礎上做了修改，因為hashmap其實是執行緒不安全的，那在併發情況下使用hashTable嘛，但是hashTable是全程加鎖的，效能不好，所以採用分段的思想，把原本的一個陣列分成預設16段，就可以最多容納16個執行緒併發操作，16個段叫做Segment，是基於ReetrantLock來實現的
說說你瞭解的hashmap吧
hashMap是Map的結構，內部用了陣列+連結串列的方式，在1.8後，當連結串列長度達到8的時候，會變成紅黑樹，這樣子就可以把查詢的複雜度變成O（nlogn）了，預設負載因子是0.75，為什麼是0.75呢？
我們知道當負載因子太小，就很容易觸發擴容，如果負載因子太大就容易出現碰撞。所以這個是空間和時間的一個均衡點，在1.8的hashmap介紹中，就有描述了，貌似是0.75的負載因子中，能讓隨機hash更加滿足0.5的泊松分佈。
除此之外，1.7的時候是頭插法，1.8後就變成了尾插法，主要是為了解決rehash出現的死迴圈問題，而且1.7的時候是先擴容後插入，1.8則是先插入後擴容(為什麼？正常來說，如果先插入，就有可能節點變為樹化，那麼是不是多做一次樹轉化，比1.7要多損耗，個人猜測，因為讀寫問題，因為hashmap並不是執行緒安全的，如果說是先擴容，後寫入，那麼在擴容期間，是訪問不到新放入的值的，是不是不太合適，所以會先放入值，這樣子在擴容期間，那個值是在的）。
1.7版本的時候用了9次擾動，5次異或，4次位移，減少hash衝突，但是1.8就只用了兩次，覺得就足夠了一次異或，一次位移。
concurrentHashMap呢
concurrentHashMap是執行緒安全的map結構，它的核心思想是分段鎖。在1.7版本的時候，內部維護了segment陣列，預設是16個，segment中有一個table陣列（相當於一個segmeng存放著一個hashmap。。。），segment繼承了reentrantlock，使用了互斥鎖，map的size其實就是segment陣列的count和。而在1.8的時候做了一個大改版，廢除了segment，採用了cas加synchronize方式來進行分段鎖（還有自旋鎖的保證），而且節點物件改用了Node不是之前的HashEntity。
Node可以支援連結串列和紅黑樹的轉化，比如TreeBin就是繼承了Node，這樣子可以直接用instanceof來區分。1.8的put就很複雜來，會先計算出hash值，然後根據hash值選出Node陣列的下標（預設陣列是空的，所以一開始put的時候會初始化，指定負載因子是0.75，不可變），判斷是否為空，如果為空，則用cas的操作來賦值首節點，如果失敗，則因為自旋，會進入非空節點的邏輯，這個時候會用synchronize加鎖頭節點（保證整條鏈路鎖定）這個時候還會進行二次判斷，是否是同一個首節點，在分首節點到底是連結串列還是樹結構，進行遍歷判斷。
concurrentHashMap的擴容方式
1.7版本的concurrentHashMap是基於了segment的，segment內部維護了HashEntity陣列，所以擴容是在這個基礎上的，類比hashmap的擴容，
1.8版本的concurrentHashMap擴容方式比較複雜，利用了ForwardingNode,先會根據機器核心數來分配每個執行緒能分到的busket數，（最小是16），這樣子可以做到多執行緒協助遷移，提升速度。然後根據自己分配的busket數來進行節點轉移，如果為空，就放置ForwardingNode，代表已經遷移完成，如果是非空節點（判斷是不是ForwardingNode，是就結束了），加鎖，鏈路迴圈,進行遷移。
hashMap的put方法的過程
判斷key是否是null，如果是null對應的hash值就是0，獲得hash值過後則進行擾動，（1.7是9次，5次異或，4次位移，1.8是2次），獲取到的新hash值找出所在的index，（n-1）&hash，根據下標找到對應的Node/entity，然後遍歷連結串列/紅黑樹，如果遇到hash值相同且equals相同，則覆蓋值，如果不是則新增。如果節點數大於8了，則進行樹化（1.8）。完成後，判斷當前的長度是否大於閥值，是就擴容（1.7是先擴容在put）。
為什麼修改hashcode方法要修改equals
都是map惹的禍，我們知道在map中判斷是否是同一個物件的時候，會先判斷hash值，在判斷equals的，如果我們只是重寫了hashcode，沒有順便修改equals，比如Intger，hashcode就是value值，如果我們不改寫equals，而是用了Object的equals，那麼就是判斷兩者指標是否一致了，那就會出現valueOf和new出來的物件會對於map而言是兩個物件，那就是個問題了
TreeMap瞭解嘛
TreeMap是Map中的一種很特殊的map，我們知道Map基本是無序的，但是TreeMap是會自動進行排序的，也就是一個有序Map(使用了紅黑樹來實現），如果設定了Comparator比較器，則會根據比較器來對比兩者的大小，如果沒有則key需要是Comparable的子類（程式碼中沒有事先check，會直接丟擲轉化異常，有點坑啊）。
LinkedHashMap瞭解嘛
LinkedHashMap是HashMap的一種特殊分支，是某種有序的hashMap，和TreeMap是不一樣的概念，是用了HashMap+連結串列的方式來構造的，有兩者有序模式：訪問有序，插入順序，插入順序是一直存在的，因為是呼叫了hashMap的put方法，並沒有過載，但是過載了newNode方法，在這個方法中，會把節點插入連結串列中，訪問有序預設是關閉的，如果開啟，則在每次get的時候都會把連結串列的節點移除掉，放到連結串列的最後面。這樣子就是一個LRU的一種實現方式。
資料結構+演算法
TODO（未完待續）
總結
內容過於硬核了，導致很多排版細節，我沒辦法做得像其他期一樣精緻了，大家見諒。
涉及的內容和東西太多了，可能很多都是點到為止，也有很多不全的，也有很多錯誤的點，已經快3W字了，我校驗實在困難，我會放在GitHub上面，大家可以跟我一起更新這個文章，造福後人吧。
搞不好下次我需要看的時候，我都得看著這個複習了。
我是敖丙，一個在網際網路苟且偷生的工具人。
你知道的越多，你不知道的越多，人才們的 【三連】 就是丙丙創作的最大動力，我們下期見！
注：如果本篇部落格有任何錯誤和建議，歡迎人才們留言，你快說句話啊！
文章持續更新，可以微信搜尋「 三太子敖丙 」第一時間閱讀，回覆【資料】【面試】【簡歷】有我準備的一線大廠面試資料和簡歷模板，本文 GitHub https://github.com/JavaFamily 已經收錄，有大廠面試完整考點，歡迎Star。
