前言

前段時間敖丙不是在復(fù)習(xí)嘛，很多小伙伴也想要我的復(fù)習(xí)路線，以及我自己筆記里面的一些知識點(diǎn)，好了，丙丙花了一個月的時間，整整一個月啊，給大家整理出來了。

一上來我就放個大招好吧，我的復(fù)習(xí)腦圖，可以說是全得不行，為了防止被盜圖，我加了水印哈。

這期看下去你會發(fā)現(xiàn)很硬核，而且我會持續(xù)更新，啥也不說了，看在我熬夜一個月滿臉痘痘的份上，你可以點(diǎn)贊了哈哈。

注：如果圖被壓縮了，可以去公眾號【三太子敖丙】回復(fù)【復(fù)習(xí)】獲取原圖

Spring

Spring框架的七大模塊

Spring Core：框架的最基礎(chǔ)部分，提供 IoC 容器，對 bean 進(jìn)行管理。

Spring Context：繼承BeanFactory，提供上下文信息，擴(kuò)展出JNDI、EJB、電子郵件、國際化等功能。

Spring DAO：提供了JDBC的抽象層，還提供了聲明性事務(wù)管理方法。

Spring ORM：提供了JPA、JDO、Hibernate、MyBatis 等ORM映射層.

Spring AOP：集成了所有AOP功能

Spring Web：提供了基礎(chǔ)的 Web 開發(fā)的上下文信息，現(xiàn)有的Web框架，如JSF、Tapestry、Structs等，提供了集成

Spring Web MVC：提供了 Web 應(yīng)用的 Model-View-Controller 全功能實(shí)現(xiàn)。

Bean定義5種作用域

singleton（單例）prototype（原型）requestsessionglobal session

spring ioc初始化流程?

resource定位即尋找用戶定義的bean資源，由 ResourceLoader通過統(tǒng)一的接口Resource接口來完成beanDefinition載入BeanDefinitionReader讀取、解析Resource定位的資源 成BeanDefinition 載入到ioc中（通過HashMap進(jìn)行維護(hù)BD）BeanDefinition注冊即向IOC容器注冊這些BeanDefinition， 通過BeanDefinitionRegistery實(shí)現(xiàn)

BeanDefinition加載流程?

定義BeanDefinitionReader解析xml的documentBeanDefinitionDocumentReader解析document成beanDefinition

DI依賴注入流程? （實(shí)例化，處理Bean之間的依賴關(guān)系）

過程在Ioc初始化后，依賴注入的過程是用戶第一次向IoC容器索要Bean時觸發(fā)

• 如果設(shè)置lazy-init=true，會在第一次getBean的時候才初始化bean， lazy-init=false，會容器啟動的時候直接初始化（singleton bean）；

• 調(diào)用BeanFactory.getBean（）生成bean的；

• 生成bean過程運(yùn)用裝飾器模式產(chǎn)生的bean都是beanWrapper（bean的增強(qiáng)）；

  依賴注入怎么處理bean之間的依賴關(guān)系?

  其實(shí)就是通過在beanDefinition載入時，如果bean有依賴關(guān)系，通過占位符來代替，在調(diào)用getbean時候，如果遇到占位符，從ioc里獲取bean注入到本實(shí)例來

Bean的生命周期?

• 實(shí)例化Bean：Ioc容器通過獲取BeanDefinition對象中的信息進(jìn)行實(shí)例化，實(shí)例化對象被包裝在BeanWrapper對象中
• 設(shè)置對象屬性（DI）：通過BeanWrapper提供的設(shè)置屬性的接口完成屬性依賴注入；
• 注入Aware接口（BeanFactoryAware， 可以用這個方式來獲取其它 Bean，ApplicationContextAware）：Spring會檢測該對象是否實(shí)現(xiàn)了xxxAware接口，并將相關(guān)的xxxAware實(shí)例注入給bean
• BeanPostProcessor：自定義的處理（分前置處理和后置處理）
• InitializingBean和init-method：執(zhí)行我們自己定義的初始化方法
• 使用
• destroy：bean的銷毀

IOC：控制反轉(zhuǎn)：將對象的創(chuàng)建權(quán)，由Spring管理.DI（依賴注入）：在Spring創(chuàng)建對象的過程中，把對象依賴的屬性注入到類中。

Spring的IOC注入方式

構(gòu)造器注入setter方法注入注解注入接口注入

怎么檢測是否存在循環(huán)依賴?

Bean在創(chuàng)建的時候可以給該Bean打標(biāo)，如果遞歸調(diào)用回來發(fā)現(xiàn)正在創(chuàng)建中的話，即說明了循環(huán)依賴了。

Spring如解決Bean循環(huán)依賴問題?

Spring中循環(huán)依賴場景有：

• 構(gòu)造器的循環(huán)依賴
• 屬性的循環(huán)依賴
• singletonObjects：第一級緩存，里面放置的是實(shí)例化好的單例對象；earlySingletonObjects：第二級緩存，里面存放的是提前曝光的單例對象；singletonFactories：第三級緩存，里面存放的是要被實(shí)例化的對象的對象工廠
• 創(chuàng)建bean的時候Spring首先從一級緩存singletonObjects中獲取。如果獲取不到，并且對象正在創(chuàng)建中，就再從二級緩存earlySingletonObjects中獲取，如果還是獲取不到就從三級緩存singletonFactories中?。˙ean調(diào)用構(gòu)造函數(shù)進(jìn)行實(shí)例化后，即使屬性還未填充，就可以通過三級緩存向外提前暴露依賴的引用值（提前曝光），根據(jù)對象引用能定位到堆中的對象，其原理是基于Java的引用傳遞），取到后從三級緩存移動到了二級緩存完全初始化之后將自己放入到一級緩存中供其他使用，
• 因?yàn)榧尤雜ingletonFactories三級緩存的前提是執(zhí)行了構(gòu)造器，所以構(gòu)造器的循環(huán)依賴沒法解決。
• 構(gòu)造器循環(huán)依賴解決辦法：在構(gòu)造函數(shù)中使用@Lazy注解延遲加載。在注入依賴時，先注入代理對象，當(dāng)首次使用時再創(chuàng)建對象說明：一種互斥的關(guān)系而非層次遞進(jìn)的關(guān)系，故稱為三個Map而非三級緩存的緣由完成注入；

Spring 中使用了哪些設(shè)計(jì)模式？

• 工廠模式：spring中的BeanFactory就是簡單工廠模式的體現(xiàn)，根據(jù)傳入唯一的標(biāo)識來獲得bean對象；
• 單例模式：提供了全局的訪問點(diǎn)BeanFactory；
• 代理模式：AOP功能的原理就使用代理模式（1、JDK動態(tài)代理。2、CGLib字節(jié)碼生成技術(shù)代理。）
• 裝飾器模式：依賴注入就需要使用BeanWrapper；
• 觀察者模式：spring中Observer模式常用的地方是listener的實(shí)現(xiàn)。如ApplicationListener。
• 策略模式：Bean的實(shí)例化的時候決定采用何種方式初始化bean實(shí)例（反射或者CGLIB動態(tài)字節(jié)碼生成）

AOP 核心概念

1、切面（aspect）：類是對物體特征的抽象，切面就是對橫切關(guān)注點(diǎn)的抽象

2、橫切關(guān)注點(diǎn)：對哪些方法進(jìn)行攔截，攔截后怎么處理，這些關(guān)注點(diǎn)稱之為橫切關(guān)注點(diǎn)。

3、連接點(diǎn)（joinpoint）：被攔截到的點(diǎn)，因?yàn)?Spring 只支持方法類型的連接點(diǎn)，所以在Spring 中連接點(diǎn)指的就是被攔截到的方法，實(shí)際上連接點(diǎn)還可以是字段或者構(gòu)造器。

4、切入點(diǎn)（pointcut）：對連接點(diǎn)進(jìn)行攔截的定義

5、通知（advice）：所謂通知指的就是指攔截到連接點(diǎn)之后要執(zhí)行的代碼，通知分為前置、后置、異常、最終、環(huán)繞通知五類。

6、目標(biāo)對象：代理的目標(biāo)對象

7、織入（weave）：將切面應(yīng)用到目標(biāo)對象并導(dǎo)致代理對象創(chuàng)建的過程

8、引入（introduction）：在不修改代碼的前提下，引入可以在運(yùn)行期為類動態(tài)地添加方法或字段。

解釋一下AOP

傳統(tǒng)oop開發(fā)代碼邏輯自上而下的，這個過程中會產(chǎn)生一些橫切性問題，這些問題與我們主業(yè)務(wù)邏輯關(guān)系不大，會散落在代碼的各個地方，造成難以維護(hù)，aop思想就是把業(yè)務(wù)邏輯與橫切的問題進(jìn)行分離，達(dá)到解耦的目的，提高代碼重用性和開發(fā)效率；

AOP 主要應(yīng)用場景有：

• 記錄日志
• 監(jiān)控性能
• 權(quán)限控制
• 事務(wù)管理

AOP源碼分析

• @EnableAspectJAutoProxy給容器（beanFactory）中注冊一個AnnotationAwareAspectJAutoProxyCreator對象；

• AnnotationAwareAspectJAutoProxyCreator對目標(biāo)對象進(jìn)行代理對象的創(chuàng)建，對象內(nèi)部，是封裝JDK和CGlib兩個技術(shù)，實(shí)現(xiàn)動態(tài)代理對象創(chuàng)建的（創(chuàng)建代理對象過程中，會先創(chuàng)建一個代理工廠，獲取到所有的增強(qiáng)器（通知方法），將這些增強(qiáng)器和目標(biāo)類注入代理工廠，再用代理工廠創(chuàng)建對象）；

• 代理對象執(zhí)行目標(biāo)方法，得到目標(biāo)方法的攔截器鏈，利用攔截器的鏈?zhǔn)綑C(jī)制，依次進(jìn)入每一個攔截器進(jìn)行執(zhí)行

  AOP應(yīng)用場景

• 日志記錄
• 事務(wù)管理
• 線程池關(guān)閉等

AOP使用哪種動態(tài)代理?

• 當(dāng)bean的是實(shí)現(xiàn)中存在接口或者是Proxy的子類，---jdk動態(tài)代理；不存在接口，spring會采用CGLIB來生成代理對象；
• JDK 動態(tài)代理主要涉及到 java.lang.reflect 包中的兩個類：Proxy 和 InvocationHandler。
• Proxy 利用 InvocationHandler（定義橫切邏輯） 接口動態(tài)創(chuàng)建 目標(biāo)類的代理對象。

jdk動態(tài)代理

• 通過bind方法建立代理與真實(shí)對象關(guān)系，通過Proxy.newProxyInstance（target）生成代理對象
• 代理對象通過反射invoke方法實(shí)現(xiàn)調(diào)用真實(shí)對象的方法

動態(tài)代理與靜態(tài)代理區(qū)別

• 靜態(tài)代理，程序運(yùn)行前代理類的.class文件就存在了；
• 動態(tài)代理：在程序運(yùn)行時利用反射動態(tài)創(chuàng)建代理對象<復(fù)用性，易用性，更加集中都調(diào)用invoke>

CGLIB與JDK動態(tài)代理區(qū)別

• Jdk必須提供接口才能使用；
• C不需要，只要一個非抽象類就能實(shí)現(xiàn)動態(tài)代理

SpringMVC

springMVC流程：

（1）：用戶請求發(fā)送給DispatcherServlet，DispatcherServlet調(diào)用HandlerMapping處理器映射器；

（2）：HandlerMapping根據(jù)xml或注解找到對應(yīng)的處理器，生成處理器對象返回給DispatcherServlet；

（3）：DispatcherServlet會調(diào)用相應(yīng)的HandlerAdapter；

（4）：HandlerAdapter經(jīng)過適配調(diào)用具體的處理器去處理請求，生成ModelAndView返回給DispatcherServlet

（5）：DispatcherServlet將ModelAndView傳給ViewReslover解析生成View返回給DispatcherServlet；

（6）：DispatcherServlet根據(jù)View進(jìn)行渲染視圖；

->DispatcherServlet->HandlerMapping->Handler->DispatcherServlet->HandlerAdapter處理handler->ModelAndView->DispatcherServlet->ModelAndView->ViewReslover->View->DispatcherServlet->返回給客戶

Mybatis

Mybatis原理

• sqlsessionFactoryBuilder生成sqlsessionFactory（單例）
• 工廠模式生成sqlsession執(zhí)行sql以及控制事務(wù)
• Mybatis通過動態(tài)代理使Mapper（sql映射器）接口能運(yùn)行起來即為接口生成代理對象將sql查詢到結(jié)果映射成pojo

sqlSessionFactory構(gòu)建過程

• 解析并讀取配置中的xml創(chuàng)建Configuration對象 （單例）
• 使用Configruation類去創(chuàng)建sqlSessionFactory（builder模式）

Mybatis一級緩存與二級緩存

默認(rèn)情況下一級緩存是開啟的，而且是不能關(guān)閉的。

• 一級緩存是指 SqlSession 級別的緩存原理：使用的數(shù)據(jù)結(jié)構(gòu)是一個 map，如果兩次中間出現(xiàn) commit 操作 （修改、添加、刪除），本 sqlsession 中的一級緩存區(qū)域全部清空
• 二級緩存是指可以跨 SqlSession 的緩存。是 mapper 級別的緩存；原理：是通過 CacheExecutor 實(shí)現(xiàn)的。CacheExecutor其實(shí)是 Executor 的代理對象

Zookeeper+eureka+springcloud

SpringBoot啟動流程

• new springApplication對象，利用spi機(jī)制加載applicationContextInitializer，applicationLister接口實(shí)例（META-INF/spring.factories）；

• 調(diào)run方法準(zhǔn)備Environment，加載應(yīng)用上下文（applicationContext），發(fā)布事件 很多通過lister實(shí)現(xiàn)

• 創(chuàng)建spring容器， refreshContext（） ，實(shí)現(xiàn)starter自動化配置，spring.factories文件加載， bean實(shí)例化

  SpringBoot自動配置的原理

• @EnableAutoConfiguration找到META-INF/spring.factories（需要創(chuàng)建的bean在里面）配置文件
• 讀取每個starter中的spring.factories文件

Spring Boot 的核心注解

核心注解是@SpringBootApplication 由以下三種組成

• @SpringBootConfiguration：組合了 @Configuration 注解，實(shí)現(xiàn)配置文件的功能。
• @EnableAutoConfiguration：打開自動配置的功能。
• @ComponentScan：Spring組件掃描。

SpringBoot常用starter都有哪些

spring-boot-starter-web - Web 和 RESTful 應(yīng)用程序；spring-boot-starter-test - 單元測試和集成測試；spring-boot-starter-jdbc - 傳統(tǒng)的 JDBC；spring-boot-starter-security - 使用 SpringSecurity 進(jìn)行身份驗(yàn)證和授權(quán)；spring-boot-starter-data-jpa - 帶有 Hibernate 的 Spring Data JPA；spring-boot-starter-data-rest - 使用 Spring Data REST 公布簡單的 REST 服務(wù)

Spring Boot 的核心配置文件

（1）：Application.yml一般用來定義單個應(yīng)用級別的，如果搭配 spring-cloud-config 使用

（2）.Bootstrap.yml（先加載）系統(tǒng)級別的一些參數(shù)配置，這些參數(shù)一般是不變的

Zuul與Gateway區(qū)別

（1）：zuul則是netflix公司的項(xiàng)目集成在spring-cloud中使用而已， Gateway是spring-cloud的一個子項(xiàng)目；

（2）：zuul不提供異步支持流控等均由hystrix支持， gateway提供了異步支持，提供了抽象負(fù)載均衡，提供了抽象流控；理論上gateway則更適合于提高系統(tǒng)吞吐量（但不一定能有更好的性能），最終性能還需要通過嚴(yán)密的壓測來決定

（3）：兩者底層實(shí)現(xiàn)都是servlet，但是gateway多嵌套了一層webflux框架

（4）：zuul可用至其他微服務(wù)框架中，內(nèi)部沒有實(shí)現(xiàn)限流、負(fù)載均衡；gateway只能用在springcloud中；

Zuul原理分析

（1）：請求給zuulservlet處理（HttpServlet子類） zuulservlet中有一個zuulRunner對象，該對象中初始化了RequestContext（存儲請求的數(shù)據(jù)），RequestContext被所有的zuulfilter共享；

（2）：zuulRunner中有 FilterProcessor（zuulfilter的管理器），其從filterloader 中獲取zuulfilter；

（3）：有了這些filter之后， zuulservelet執(zhí)行的Pre-> route-> post 類型的過濾器，如果在執(zhí)行這些過濾器有錯誤的時候則會執(zhí)行error類型的過濾器，執(zhí)行完后把結(jié)果返回給客戶端.

Gateway原理分析

（1）：請求到達(dá)DispatcherHandler， DispatchHandler在IOC容器初始化時會在容器中實(shí)例化HandlerMapping接口

（2）：用handlerMapping根據(jù)請求URL匹配到對應(yīng)的Route，然后有對應(yīng)的filter做對應(yīng)的請求轉(zhuǎn)發(fā)最終response返回去

Zookeeper 工作原理（待查）

Zookeeper 的核心是原子廣播，這個機(jī)制保證了各個 server 之間的同步。實(shí)現(xiàn)這個機(jī)制的協(xié)議叫做 Zab 協(xié)議。Zab 協(xié)議有兩種模式，它們分別是恢復(fù)模式和廣播模式。

zoo與eur區(qū)別

• zookeeper保證cp（一致性）
• eureka保證ap（可用性）
• zoo在選舉期間注冊服務(wù)癱瘓，期間不可用
• eur各個節(jié)點(diǎn)平等關(guān)系，只要有一臺就可保證服務(wù)可用，而查詢到的數(shù)據(jù)可能不是最新的，可以很好應(yīng)對網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失聯(lián)情況
• zoo有l(wèi)eader和follower角色，eur各個節(jié)點(diǎn)平等
• zoo采用半數(shù)存活原則（避免腦裂），eur采用自我保護(hù)機(jī)制來解決分區(qū)問題
• eur本質(zhì)是個工程，zoo只是一個進(jìn)程ZooKeeper基于CP，不保證高可用，如果zookeeper正在選主，或者Zookeeper集群中半數(shù)以上機(jī)器不可用，那么將無法獲得數(shù)據(jù)。Eureka基于AP，能保證高可用，即使所有機(jī)器都掛了，也能拿到本地緩存的數(shù)據(jù)。作為注冊中心，其實(shí)配置是不經(jīng)常變動的，只有發(fā)版（發(fā)布新的版本）和機(jī)器出故障時會變。對于不經(jīng)常變動的配置來說，CP是不合適的，而AP在遇到問題時可以用犧牲一致性來保證可用性，既返回舊數(shù)據(jù)，緩存數(shù)據(jù)。所以理論上Eureka是更適合做注冊中心。而現(xiàn)實(shí)環(huán)境中大部分項(xiàng)目可能會使用ZooKeeper，那是因?yàn)榧翰粔虼?，并且基本不會遇到用做注冊中心的機(jī)器一半以上都掛了的情況。所以實(shí)際上也沒什么大問題。

Hystrix原理（待查）

通過維護(hù)一個自己的線程池，當(dāng)線程池達(dá)到閾值的時候，就啟動服務(wù)降級，返回fallback默認(rèn)值

為什么需要hystrix熔斷

防止雪崩，及時釋放資源，防止系統(tǒng)發(fā)生更多的額級聯(lián)故障，需要對故障和延遲進(jìn)行隔離，防止單個依賴關(guān)系的失敗影響整個應(yīng)用程序；

微服務(wù)優(yōu)缺點(diǎn)

• 每個服務(wù)高內(nèi)聚，松耦合，面向接口編程；
• 服務(wù)間通信成本，數(shù)據(jù)一致性，多服務(wù)運(yùn)維難度增加，http傳輸效率不如rpc

eureka自我保護(hù)機(jī)制

• eur不移除長時間沒收到心跳而應(yīng)該過期的服務(wù)
• 仍然接受新服務(wù)注冊和查詢請求，但是不會同步到其它節(jié)點(diǎn)（高可用）
• 當(dāng)網(wǎng)絡(luò)穩(wěn)定后，當(dāng)前實(shí)例新注冊信息會同步到其它節(jié)點(diǎn)（最終一致性）

MQ對比

ActiveMQ：Apache出品，最早使用的消息隊(duì)列產(chǎn)品，時間比較長了，最近版本更新比較緩慢。RabbitMQ：erlang語言開發(fā)，支持很多的協(xié)議，非常重量級，更適合于企業(yè)級的開發(fā)。性能較好，但是不利于做二次開發(fā)和維護(hù)。RocketMQ：阿里開源的消息中間件，純Java開發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)，分布式事務(wù)。ZeroMQ：號稱最快的消息隊(duì)列系統(tǒng)，尤其針對大吞吐量的需求場景，采用 C 語言實(shí)現(xiàn)。消息隊(duì)列的選型需要根據(jù)具體應(yīng)用需求而定，ZeroMQ 小而美，RabbitMQ 大而穩(wěn)，Kakfa 和 RocketMQ 快而強(qiáng)勁

JAVA基礎(chǔ)

AVL樹與紅黑樹（R-B樹）的區(qū)別與聯(lián)系

• AVL是嚴(yán)格的平衡樹，因此在增加或者刪除節(jié)點(diǎn)的時候，根據(jù)不同情況，旋轉(zhuǎn)的次數(shù)比紅黑樹要多；
• 紅黑樹是用非嚴(yán)格的平衡來換取增刪節(jié)點(diǎn)時候旋轉(zhuǎn)次數(shù)的降低開銷；
• 所以簡單說，查詢多選擇AVL樹，查詢更新次數(shù)差不多選紅黑樹
• AVL樹順序插入和刪除時有20%左右的性能優(yōu)勢，紅黑樹隨機(jī)操作15%左右優(yōu)勢，現(xiàn)實(shí)應(yīng)用當(dāng)然一般都是隨機(jī)情況，所以紅黑樹得到了更廣泛的應(yīng)用索引為B+樹Hashmap為紅黑樹

為啥redis zset使用跳躍鏈表而不用紅黑樹實(shí)現(xiàn)

• skiplist的復(fù)雜度和紅黑樹一樣，而且實(shí)現(xiàn)起來更簡單。
• 在并發(fā)環(huán)境下紅黑樹在插入和刪除時需要rebalance，性能不如跳表。

JAVA基本數(shù)據(jù)類型

（1個字節(jié)是8個bit）整數(shù)型：byte（1字節(jié)）、short（2字節(jié)）、int（4字節(jié)）、long（8字節(jié)）浮點(diǎn)型：float（4字節(jié)）、double（8字節(jié)）布爾型：boolean（1字節(jié)）字符型：char（2字節(jié)）

IO與NIO

包括 類File，outputStream，inputStream，writer，readerseralizable（5類1接口）

NIO三大核心內(nèi)容 selector（選擇器，用于監(jiān)聽channel），channel（通道），buffer（緩沖區(qū)）

NIO與IO區(qū)別，IO面向流，NIO面向緩沖區(qū)；io阻塞，nio非阻塞

異常類

throwable為父類，子為error跟exception，exception分runtime（空指針，越界等）跟checkexception（sql，io，找不到類等異常）

LVS（4層與7層）原理

• 由前端虛擬負(fù)載均衡器和后端真實(shí)服務(wù)器群組成；
• 請求發(fā)送給虛擬服務(wù)器后其根據(jù)包轉(zhuǎn)發(fā)策略以及負(fù)載均衡調(diào)度算法轉(zhuǎn)發(fā)給真實(shí)服務(wù)器
• 所謂四層（lvs，f5）就是基于IP+端口的負(fù)載均衡；七層（nginx）就是基于URL等應(yīng)用層信息的負(fù)載均衡

StringBuilder與StringBuffer

• StringBuilder 更快；
• StringBuffer是線程安全的

interrupt/isInterrupted/interrupt區(qū)別

• interrupt（） 調(diào)用該方法的線程的狀態(tài)為將被置為'中斷'狀態(tài)（set操作）
• isinterrupted（） 是作用于調(diào)用該方法的線程對象所對應(yīng)的線程的中斷信號是true還是false（get操作）。例如我們可以在A線程中去調(diào)用B線程對象的isInterrupted方法，查看的是A
• interrupted（）是靜態(tài)方法：內(nèi)部實(shí)現(xiàn)是調(diào)用的當(dāng)前線程的isInterrupted（），并且會重置當(dāng)前線程的中斷狀態(tài)（getandset）

sleep與wait區(qū)別

sleep屬于線程類，wait屬于object類；sleep不釋放鎖

CountDownLatch和CyclicBarrier區(qū)別

• con用于主線程等待其他子線程任務(wù)都執(zhí)行完畢后再執(zhí)行，cyc用于一組線程相互等待大家都達(dá)到某個狀態(tài)后，再同時執(zhí)行；
• CountDownLatch是不可重用的，CyclicBarrier可重用

終止線程方法

• 使用退出標(biāo)志，說線程正常退出；
• 通過判斷this.interrupted（） throw new InterruptedException（）來停止使用String常量池作為鎖對象會導(dǎo)致兩個線程持有相同的鎖，另一個線程不執(zhí)行，改用其他如new Object（）

ThreadLocal的原理和應(yīng)用

原理：

線程中創(chuàng)建副本，訪問自己內(nèi)部的副本變量，內(nèi)部實(shí)現(xiàn)是其內(nèi)部類名叫ThreadLocalMap的成員變量threadLocals，key為本身，value為實(shí)際存值的變量副本

應(yīng)用：

• 用來解決數(shù)據(jù)庫連接，存放connection對象，不同線程存放各自session；
• 解決simpleDateFormat線程安全問題；
• 會出現(xiàn)內(nèi)存泄漏，顯式remove..不要與線程池配合，因?yàn)閣orker往往是不會退出的；

threadLocal 內(nèi)存泄漏問題

如果是強(qiáng)引用，設(shè)置tl=null，但是key的引用依然指向ThreadLocal對象，所以會有內(nèi)存泄漏，而使用弱引用則不會；但是還是會有內(nèi)存泄漏存在，ThreadLocal被回收，key的值變成null，導(dǎo)致整個value再也無法被訪問到；解決辦法：在使用結(jié)束時，調(diào)用ThreadLocal.remove來釋放其value的引用；

如果我們要獲取父線程的ThreadLocal值呢

ThreadLocal是不具備繼承性的，所以是無法獲取到的，但是我們可以用InteritableThreadLocal來實(shí)現(xiàn)這個功能。InteritableThreadLocal繼承來ThreadLocal，重寫了createdMap方法，已經(jīng)對應(yīng)的get和set方法，不是在利用了threadLocals，而是interitableThreadLocals變量。

這個變量會在線程初始化的時候（調(diào)用init方法），會判斷父線程的interitableThreadLocals變量是否為空，如果不為空，則把放入子線程中，但是其實(shí)這玩意沒啥鳥用，當(dāng)父線程創(chuàng)建完子線程后，如果改變父線程內(nèi)容是同步不到子線程的。。。同樣，如果在子線程創(chuàng)建完后，再去賦值，也是沒啥鳥用的

線程狀態(tài)

線程池有5種狀態(tài)：running，showdown，stop，Tidying，TERMINATED。

• running：線程池處于運(yùn)行狀態(tài)，可以接受任務(wù)，執(zhí)行任務(wù)，創(chuàng)建線程默認(rèn)就是這個狀態(tài)了

• showdown：調(diào)用showdown（）函數(shù)，不會接受新任務(wù)，但是會慢慢處理完堆積的任務(wù)。

• stop：調(diào)用showdownnow（）函數(shù)，不會接受新任務(wù)，不處理已有的任務(wù)，會中斷現(xiàn)有的任務(wù)。

• Tidying：當(dāng)線程池狀態(tài)為showdown或者stop，任務(wù)數(shù)量為0，就會變?yōu)閠idying。這個時候會調(diào)用鉤子函數(shù)terminated（）。

• TERMINATED：terminated（）執(zhí)行完成。

在線程池中，用了一個原子類來記錄線程池的信息，用了int的高3位表示狀態(tài)，后面的29位表示線程池中線程的個數(shù)。

Java中的線程池是如何實(shí)現(xiàn)的？

• 線程中線程被抽象為靜態(tài)內(nèi)部類Worker，是基于AQS實(shí)現(xiàn)的存放在HashSet中；
• 要被執(zhí)行的線程存放在BlockingQueue中；
• 基本思想就是從workQueue中取出要執(zhí)行的任務(wù)，放在worker中處理；

如果線程池中的一個線程運(yùn)行時出現(xiàn)了異常，會發(fā)生什么

如果提交任務(wù)的時候使用了submit，則返回的feature里會存有異常信息，但是如果數(shù)execute則會打印出異常棧。但是不會給其他線程造成影響。之后線程池會刪除該線程，會新增加一個worker。

線程池原理

• 提交一個任務(wù)，線程池里存活的核心線程數(shù)小于corePoolSize時，線程池會創(chuàng)建一個核心線程去處理提交的任務(wù)
• 如果線程池核心線程數(shù)已滿，即線程數(shù)已經(jīng)等于corePoolSize，一個新提交的任務(wù)，會被放進(jìn)任務(wù)隊(duì)列workQueue排隊(duì)等待執(zhí)行。
• 當(dāng)線程池里面存活的線程數(shù)已經(jīng)等于corePoolSize了，并且任務(wù)隊(duì)列workQueue也滿，判斷線程數(shù)是否達(dá)到maximumPoolSize，即最大線程數(shù)是否已滿，如果沒到達(dá)，創(chuàng)建非核心線程執(zhí)行提交的任務(wù)。
• 如果當(dāng)前的線程數(shù)達(dá)到了maximumPoolSize，還有新的任務(wù)過來的話，直接采用拒絕策略處理。

拒絕策略

• AbortPolicy直接拋出異常阻止線程運(yùn)行；
• CallerRunsPolicy如果被丟棄的線程任務(wù)未關(guān)閉，則執(zhí)行該線程；
• DiscardOldestPolicy移除隊(duì)列最早線程嘗試提交當(dāng)前任務(wù)
• DiscardPolicy丟棄當(dāng)前任務(wù)，不做處理

newFixedThreadPool （固定數(shù)目線程的線程池）

• 阻塞隊(duì)列為無界隊(duì)列LinkedBlockingQueue
• 適用于處理CPU密集型的任務(wù)，適用執(zhí)行長期的任務(wù)

newCachedThreadPool（可緩存線程的線程池）

• 阻塞隊(duì)列是SynchronousQueue
• 適用于并發(fā)執(zhí)行大量短期的小任務(wù)

newSingleThreadExecutor（單線程的線程池）

• 阻塞隊(duì)列是LinkedBlockingQueue
• 適用于串行執(zhí)行任務(wù)的場景，一個任務(wù)一個任務(wù)地執(zhí)行

newScheduledThreadPool（定時及周期執(zhí)行的線程池）

• 阻塞隊(duì)列是DelayedWorkQueue
• 周期性執(zhí)行任務(wù)的場景，需要限制線程數(shù)量的場景

java鎖相關(guān)

synchronized實(shí)現(xiàn)原理

contentionList（請求鎖線程隊(duì)列）entryList（有資格的候選者隊(duì)列）waitSet（wait方法后阻塞隊(duì)列）onDeck（競爭候選者）ower（競爭到鎖線程）!ower（執(zhí)行成功釋放鎖后狀態(tài)）；Synchronized 是非公平鎖。

Synchronized 在線程進(jìn)入 ContentionList 時，等待的線程會先嘗試自旋獲取鎖，如果獲取不到就進(jìn)入 ContentionList，這明顯對于已經(jīng)進(jìn)入隊(duì)列的線程是不公平的，還有一個不公平的事情就是自旋獲取鎖的線程還可能直接搶占 OnDeck 線程的鎖資源。

底層是由一對monitorenter和monitorexit指令實(shí)現(xiàn)的（監(jiān)視器鎖）

每個對象有一個監(jiān)視器鎖（monitor）。當(dāng)monitor被占用時就會處于鎖定狀態(tài)，線程執(zhí)行monitorenter指令時嘗試獲取monitor的所有權(quán)，過程：

• 如果monitor的進(jìn)入數(shù)為0，則該線程進(jìn)入monitor，然后將進(jìn)入數(shù)設(shè)置為1，該線程即為monitor的所有者。
• 如果線程已經(jīng)占有該monitor，只是重新進(jìn)入，則進(jìn)入monitor的進(jìn)入數(shù)加1.
• 如果其他線程已經(jīng)占用了monitor，則該線程進(jìn)入阻塞狀態(tài)，直到monitor的進(jìn)入數(shù)為0，再重新嘗試獲取monitor的所有權(quán)。

ReentrantLock 是如何實(shí)現(xiàn)可重入性的 ？

內(nèi)部自定義了同步器 Sync，加鎖的時候通過CAS 算法 ，將線程對象放到一個雙向鏈表 中，每次獲取鎖的時候 ，看下當(dāng)前維 護(hù)的那個線程ID和當(dāng)前請求的線程ID是否一樣，一樣就可重入了；

ReentrantLock如何避免死鎖?

• 響應(yīng)中斷l(xiāng)ockInterruptibly（）
• 可輪詢鎖tryLock（）
• 定時鎖tryLock（long time）

tryLock 和 lock 和 lockInterruptibly 的區(qū)別

（1）：tryLock 能獲得鎖就返回 true，不能就立即返回 false，

（2）：tryLock（long timeout，TimeUnit unit），可以增加時間限制，如果超過該時間段還沒獲得鎖，返回 false

（3）：lock 能獲得鎖就返回 true，不能的話一直等待獲得鎖

（4）：lock 和 lockInterruptibly，如果兩個線程分別執(zhí)行這兩個方法，但此時中斷這兩個線程， lock 不會拋出異常，而 lockInterruptibly 會拋出異常。

CountDownLatch和CyclicBarrier的區(qū)別是什么

CountDownLatch是等待其他線程執(zhí)行到某一個點(diǎn)的時候，在繼續(xù)執(zhí)行邏輯（子線程不會被阻塞，會繼續(xù)執(zhí)行），只能被使用一次。最常見的就是join形式，主線程等待子線程執(zhí)行完任務(wù)，在用主線程去獲取結(jié)果的方式（當(dāng)然不一定），內(nèi)部是用計(jì)數(shù)器相減實(shí)現(xiàn)的（沒錯，又特么是AQS），AQS的state承擔(dān)了計(jì)數(shù)器的作用，初始化的時候，使用CAS賦值，主線程調(diào)用await（）則被加入共享線程等待隊(duì)列里面，子線程調(diào)用countDown的時候，使用自旋的方式，減1，知道為0，就觸發(fā)喚醒。

CyclicBarrier回環(huán)屏障，主要是等待一組線程到底同一個狀態(tài)的時候，放閘。CyclicBarrier還可以傳遞一個Runnable對象，可以到放閘的時候，執(zhí)行這個任務(wù)。CyclicBarrier是可循環(huán)的，當(dāng)調(diào)用await的時候如果count變成0了則會重置狀態(tài)，如何重置呢，CyclicBarrier新增了一個字段parties，用來保存初始值，當(dāng)count變?yōu)?的時候，就重新賦值。還有一個不同點(diǎn)，CyclicBarrier不是基于AQS的，而是基于RentrantLock實(shí)現(xiàn)的。存放的等待隊(duì)列是用了條件變量的方式。

synchronized與ReentrantLock區(qū)別

• 都是可重入鎖；R是顯示獲取和釋放鎖，s是隱式；
• R更靈活可以知道有沒有成功獲取鎖，可以定義讀寫鎖，是api級別，s是JVM級別；
• R可以定義公平鎖；Lock是接口，s是java中的關(guān)鍵字

什么是信號量Semaphore

信號量是一種固定資源的限制的一種并發(fā)工具包，基于AQS實(shí)現(xiàn)的，在構(gòu)造的時候會設(shè)置一個值，代表著資源數(shù)量。信號量主要是應(yīng)用于是用于多個共享資源的互斥使用，和用于并發(fā)線程數(shù)的控制（druid的數(shù)據(jù)庫連接數(shù)，就是用這個實(shí)現(xiàn)的），信號量也分公平和非公平的情況，基本方式和reentrantLock差不多，在請求資源調(diào)用task時，會用自旋的方式減1，如果成功，則獲取成功了，如果失敗，導(dǎo)致資源數(shù)變?yōu)榱?，就會加入隊(duì)列里面去等待。調(diào)用release的時候會加一，補(bǔ)充資源,并喚醒等待隊(duì)列。

Semaphore 應(yīng)用

• acquire（） release（） 可用于對象池，資源池的構(gòu)建，比如靜態(tài)全局對象池，數(shù)據(jù)庫連接池；
• 可創(chuàng)建計(jì)數(shù)為1的S，作為互斥鎖（二元信號量）

可重入鎖概念

（1）：可重入鎖是指同一個線程可以多次獲取同一把鎖，不會因?yàn)橹耙呀?jīng)獲取過還沒釋放而阻塞；

（2）：reentrantLock和synchronized都是可重入鎖

（3）：可重入鎖的一個優(yōu)點(diǎn)是可一定程度避免死鎖

ReentrantLock原理（CAS+AQS）

CAS+AQS隊(duì)列來實(shí)現(xiàn)

（1）：先通過CAS嘗試獲取鎖， 如果此時已經(jīng)有線程占據(jù)了鎖，那就加入AQS隊(duì)列并且被掛起；

（2）：當(dāng)鎖被釋放之后， 排在隊(duì)首的線程會被喚醒CAS再次嘗試獲取鎖，

（3）：如果是非公平鎖， 同時還有另一個線程進(jìn)來嘗試獲取可能會讓這個線程搶到鎖；

（4）：如果是公平鎖， 會排到隊(duì)尾，由隊(duì)首的線程獲取到鎖。

AQS 原理

Node內(nèi)部類構(gòu)成的一個雙向鏈表結(jié)構(gòu)的同步隊(duì)列，通過控制（volatile的int類型）state狀態(tài)來判斷鎖的狀態(tài)，對于非可重入鎖狀態(tài)不是0則去阻塞；

對于可重入鎖如果是0則執(zhí)行，非0則判斷當(dāng)前線程是否是獲取到這個鎖的線程，是的話把state狀態(tài)＋1，比如重入5次，那么state=5。而在釋放鎖的時候，同樣需要釋放5次直到state=0其他線程才有資格獲得鎖

AQS兩種資源共享方式

• Exclusive：獨(dú)占，只有一個線程能執(zhí)行，如ReentrantLock
• Share：共享，多個線程可以同時執(zhí)行，如Semaphore、CountDownLatch、ReadWriteLock，CyclicBarrier

CAS原理

內(nèi)存值V，舊的預(yù)期值A(chǔ)，要修改的新值B，當(dāng)A=V時，將內(nèi)存值修改為B，否則什么都不做；

CAS的缺點(diǎn)：

（1）：ABA問題；（2）：如果CAS失敗，自旋會給CPU帶來壓力；（3）：只能保證對一個變量的原子性操作，i++這種是不能保證的

CAS在java中的應(yīng)用：

（1）：Atomic系列

公平鎖與分公平鎖

（1）：公平鎖指在分配鎖前檢查是否有線程在排隊(duì)等待獲取該鎖，優(yōu)先分配排隊(duì)時間最長的線程，非公平直接嘗試獲取鎖（2）：公平鎖需多維護(hù)一個鎖線程隊(duì)列，效率低；默認(rèn)非公平

獨(dú)占鎖與共享鎖

（1）：ReentrantLock為獨(dú)占鎖（悲觀加鎖策略）（2）：ReentrantReadWriteLock中讀鎖為共享鎖（3）：JDK1.8 郵戳鎖（StampedLock）， 不可重入鎖讀的過程中也允許獲取寫鎖后寫入！這樣一來，我們讀的數(shù)據(jù)就可能不一致，所以，需要一點(diǎn)額外的代碼來判斷讀的過程中是否有寫入，這種讀鎖是一種樂觀鎖， 樂觀鎖的并發(fā)效率更高，但一旦有小概率的寫入導(dǎo)致讀取的數(shù)據(jù)不一致，需要能檢測出來，再讀一遍就行

4種鎖狀態(tài)

• 無鎖

• 偏向鎖會偏向第一個訪問鎖的線程，當(dāng)一個線程訪問同步代碼塊獲得鎖時，會在對象頭和棧幀記錄里存儲鎖偏向的線程ID，當(dāng)這個線程再次進(jìn)入同步代碼塊時，就不需要CAS操作來加鎖了，只要測試一下對象頭里是否存儲著指向當(dāng)前線程的偏向鎖如果偏向鎖未啟動，new出的對象是普通對象（即無鎖，有稍微競爭會成輕量級鎖），如果啟動，new出的對象是匿名偏向（偏向鎖）對象頭主要包括兩部分?jǐn)?shù)據(jù)：Mark Word（標(biāo)記字段， 存儲對象自身的運(yùn)行時數(shù)據(jù)）、class Pointer（類型指針， 是對象指向它的類元數(shù)據(jù)的指針）

• 輕量級鎖（自旋鎖）（1）：在把線程進(jìn)行阻塞操作之前先讓線程自旋等待一段時間，可能在等待期間其他線程已經(jīng) 解鎖，這時就無需再讓線程執(zhí)行阻塞操作，避免了用戶態(tài)到內(nèi)核態(tài)的切換。（自適應(yīng)自旋時間為一個線程上下文切換的時間）

• （2）：在用自旋鎖時有可能造成死鎖，當(dāng)遞歸調(diào)用時有可能造成死鎖

• （3）：自旋鎖底層是通過指向線程棧中Lock Record的指針來實(shí)現(xiàn)的

• 重量級鎖

輕量級鎖與偏向鎖的區(qū)別

（1）：輕量級鎖是通過CAS來避免進(jìn)入開銷較大的互斥操作

（2）：偏向鎖是在無競爭場景下完全消除同步，連CAS也不執(zhí)行

自旋鎖升級到重量級鎖條件

（1）：某線程自旋次數(shù)超過10次；

（2）：等待的自旋線程超過了系統(tǒng)core數(shù)的一半；

讀寫鎖了解嘛，知道讀寫鎖的實(shí)現(xiàn)方式嘛

常用的讀寫鎖ReentrantReanWritelock，這個其實(shí)和reentrantLock相似，也是基于AQS的，但是這個是基于共享資源的，不是互斥，關(guān)鍵在于state的處理，讀寫鎖把高16為記為讀狀態(tài)，低16位記為寫狀態(tài)，就分開了，讀讀情況其實(shí)就是讀鎖重入，讀寫/寫讀/寫寫都是互斥的，只要判斷低16位就好了。

zookeeper實(shí)現(xiàn)分布式鎖

（1）：利用節(jié)點(diǎn)名稱唯一性來實(shí)現(xiàn)，加鎖時所有客戶端一起創(chuàng)建節(jié)點(diǎn)，只有一個創(chuàng)建成功者獲得鎖，解鎖時刪除節(jié)點(diǎn)。

（2）：利用臨時順序節(jié)點(diǎn)實(shí)現(xiàn)，加鎖時所有客戶端都創(chuàng)建臨時順序節(jié)點(diǎn)，創(chuàng)建節(jié)點(diǎn)序列號最小的獲得鎖，否則監(jiān)視比自己序列號次小的節(jié)點(diǎn)進(jìn)行等待

（3）：方案2比1好處是當(dāng)zookeeper宕機(jī)后，臨時順序節(jié)點(diǎn)會自動刪除釋放鎖，不會造成鎖等待；

（4）：方案1會產(chǎn)生驚群效應(yīng)（當(dāng)有很多進(jìn)程在等待鎖的時候，在釋放鎖的時候會有很多進(jìn)程就過來爭奪鎖）。

（5）：由于需要頻繁創(chuàng)建和刪除節(jié)點(diǎn)，性能上不如redis鎖

volatile變量

（1）：變量可見性

（2）：防止指令重排序

（3）：保障變量單次讀，寫操作的原子性，但不能保證i++這種操作的原子性，因?yàn)楸举|(zhì)是讀，寫兩次操作

volatile如何保證線程間可見和避免指令重排

volatile可見性是有指令原子性保證的，在jmm中定義了8類原子性指令，比如write，store，read，load。而volatile就要求write-store，load-read成為一個原子性操作，這樣子可以確保在讀取的時候都是從主內(nèi)存讀入，寫入的時候會同步到主內(nèi)存中（準(zhǔn)確來說也是內(nèi)存屏障），指令重排則是由內(nèi)存屏障來保證的，由兩個內(nèi)存屏障:

• 一個是編譯器屏障：阻止編譯器重排，保證編譯程序時在優(yōu)化屏障之前的指令不會在優(yōu)化屏障之后執(zhí)行。
• 第二個是cpu屏障：sfence保證寫入，lfence保證讀取，lock類似于鎖的方式。java多執(zhí)行了一個“l(fā)oad addl $0x0, (%esp)”操作，這個操作相當(dāng)于一個lock指令，就是增加一個完全的內(nèi)存屏障指令。

JVM

jre、jdk、jvm的關(guān)系：

jdk是最小的開發(fā)環(huán)境，由jre++java工具組成。

jre是java運(yùn)行的最小環(huán)境，由jvm+核心類庫組成。

jvm是虛擬機(jī)，是java字節(jié)碼運(yùn)行的容器，如果只有jvm是無法運(yùn)行java的，因?yàn)槿鄙倭撕诵念悗臁?/p>

JVM內(nèi)存模型

（1）：堆<對象，靜態(tài)變量，共享

（2）：方法區(qū)<存放類信息，常量池，共享>（java8移除了永久代（PermGen），替換為元空間（Metaspace））

（3）：虛擬機(jī)棧<線程執(zhí)行方法的時候內(nèi)部存局部變量會存堆中對象的地址等等數(shù)據(jù)>

（4）：本地方法棧<存放各種native方法的局部變量表之類的信息>

（5）：程序計(jì)數(shù)器<記錄當(dāng)前線程執(zhí)行到哪一條字節(jié)碼指令位置>

對象4種引用

（1）：強(qiáng)（內(nèi)存泄露主因）

（2）：軟（只有軟引用的話，空間不足將被回收），適合緩存用

（3）：弱（只，GC會回收）

（4）：虛引用（用于跟蹤GC狀態(tài)）用于管理堆外內(nèi)存

對象的構(gòu)成：

一個對象分為3個區(qū)域：對象頭、實(shí)例數(shù)據(jù)、對齊填充

對象頭：主要是包括兩部分，1.存儲自身的運(yùn)行時數(shù)據(jù)比如hash碼，分代年齡，鎖標(biāo)記等（但是不是絕對哦，鎖狀態(tài)如果是偏向鎖，輕量級鎖，是沒有hash碼的。。。是不固定的）2.指向類的元數(shù)據(jù)指針。還有可能存在第三部分，那就是數(shù)組類型，會多一塊記錄數(shù)組的長度（因?yàn)閿?shù)組的長度是jvm判斷不出來的，jvm只有元數(shù)據(jù)信息）

實(shí)例數(shù)據(jù)：會根據(jù)虛擬機(jī)分配策略來定，分配策略中，會把相同大小的類型放在一起，并按照定義順序排列（父類的變量也會在哦）

對齊填充：這個意義不是很大，主要在虛擬機(jī)規(guī)范中對象必須是8字節(jié)的整數(shù)，所以當(dāng)對象不滿足這個情況時，就會用占位符填充

如果判斷一個對象是否存活：

一般判斷對象是否存活有兩種算法，一種是引用計(jì)數(shù)，另外一種是可達(dá)性分析。在java中主要是第二種

java是根據(jù)什么來執(zhí)行可達(dá)性分析的：

根據(jù)GC ROOTS。GC ROOTS可以的對象有：虛擬機(jī)棧中的引用對象，方法區(qū)的類變量的引用，方法區(qū)中的常量引用，本地方法棧中的對象引用。

JVM 類加載順序

（1）：加載獲取類的二進(jìn)制字節(jié)流，將其靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)的運(yùn)行時數(shù)據(jù)結(jié)構(gòu)

（2）：校驗(yàn)文件格式驗(yàn)證，元數(shù)據(jù)驗(yàn)證，字節(jié)碼驗(yàn)證，符號引用驗(yàn)證

（3）：準(zhǔn)備在方法區(qū)中對類的static變量分配內(nèi)存并設(shè)置類變量數(shù)據(jù)類型默認(rèn)的初始值，不包括實(shí)例變量，實(shí)例變量將會在對象實(shí)例化的時候隨著對象一起分配在Java堆中

（4）：解析將常量池內(nèi)的符號引用替換為直接引用的過程

（5）：初始化為類的靜態(tài)變量賦予正確的初始值（Java代碼中被顯式地賦予的值）

JVM三種類加載器

（1）：啟動類加載器（home）加載jvm核心類庫，如java.lang.*等

（2）：擴(kuò)展類加載器（ext），父加載器為啟動類加載器，從jre/lib/ext下加載類庫

（3）：應(yīng)用程序類加載器（用戶classpath路徑）父加載器為擴(kuò)展類加載器，從環(huán)境變量中加載類

雙親委派機(jī)制

（1）：類加載器收到類加載的請求

（2）：把這個請求委托給父加載器去完成，一直向上委托，直到啟動類加載器

（3）：啟動器加載器檢查能不能加載，能就加載（結(jié)束）；否則，拋出異常，通知子加載器進(jìn)行加載

（4）：保障類的唯一性和安全性以及保證JDK核心類的優(yōu)先加載

雙親委派模型有啥作用：

保證java基礎(chǔ)類在不同的環(huán)境還是同一個Class對象，避免出現(xiàn)了自定義類覆蓋基礎(chǔ)類的情況，導(dǎo)致出現(xiàn)安全問題。還可以避免類的重復(fù)加載。

如何打破雙親委派模型？

（1）：自定義類加載器，繼承ClassLoader類重寫loadClass方法；

（2）：SPI

tomcat是如何打破雙親委派模型：

tomcat有著特殊性，它需要容納多個應(yīng)用，需要做到應(yīng)用級別的隔離，而且需要減少重復(fù)性加載，所以劃分為：/common 容器和應(yīng)用共享的類信息，/server容器本身的類信息，/share應(yīng)用通用的類信息,/WEB-INF/lib應(yīng)用級別的類信息。整體可以分為：boostrapClassLoader->ExtensionClassLoader->ApplicationClassLoader->CommonClassLoader->CatalinaClassLoader（容器本身的加載器）/ShareClassLoader（共享的）->WebAppClassLoader。雖然第一眼是滿足雙親委派模型的，但是不是的，因?yàn)殡p親委派模型是要先提交給父類裝載，而tomcat是優(yōu)先判斷是否是自己負(fù)責(zé)的文件位置，進(jìn)行加載的。

SPI：（Service Provider interface）

（1）：服務(wù)提供接口（服務(wù)發(fā)現(xiàn)機(jī)制）：

（2）：通過加載ClassPath下META_INF/services，自動加載文件里所定義的類

（3）：通過ServiceLoader.load/Service.providers方法通過反射拿到實(shí)現(xiàn)類的實(shí)例

SPI應(yīng)用?

（1）：應(yīng)用于JDBC獲取數(shù)據(jù)庫驅(qū)動連接過程就是應(yīng)用這一機(jī)制

（2）：apache最早提供的common-logging只有接口.沒有實(shí)現(xiàn)..發(fā)現(xiàn)日志的提供商通過SPI來具體找到日志提供商實(shí)現(xiàn)類

雙親委派機(jī)制缺陷?

（1）：雙親委派核心是越基礎(chǔ)的類由越上層的加載器進(jìn)行加載， 基礎(chǔ)的類總是作為被調(diào)用代碼調(diào)用的API，無法實(shí)現(xiàn)基礎(chǔ)類調(diào)用用戶的代碼….

（2）：JNDI服務(wù)它的代碼由啟動類加載器去加載，但是他需要調(diào)獨(dú)立廠商實(shí)現(xiàn)的應(yīng)用程序，如何解決?線程上下文件類加載器（Thread Context ClassLoader）， JNDI服務(wù)使用這個線程上下文類加載器去加載所需要的SPI代碼，也就是父類加載器請求子類加載器去完成類加載動作Java中所有涉及SPI的加載動作基本上都采用這種方式，例如JNDI，JDBC

導(dǎo)致fullGC的原因

（1）：老年代空間不足

（2）：永久代（方法區(qū)）空間不足

（3）：顯式調(diào)用system.gc（）

堆外內(nèi)存的優(yōu)缺點(diǎn)

Ehcache中的一些版本，各種 NIO 框架，Dubbo，Memcache 等中會用到，NIO包下ByteBuffer來創(chuàng)建堆外內(nèi)存堆外內(nèi)存，其實(shí)就是不受JVM控制的內(nèi)存。

相比于堆內(nèi)內(nèi)存有幾個優(yōu)勢：

減少了垃圾回收的工作，因?yàn)槔厥諘和Ｆ渌墓ぷ?。加快了?fù)制的速度。因?yàn)槎褍?nèi)在 flush 到遠(yuǎn)程時，會先復(fù)制到直接內(nèi)存（非堆內(nèi)存），然后在發(fā)送；而堆外內(nèi)存相當(dāng)于省略掉了復(fù)制這項(xiàng)工作?？梢詳U(kuò)展至更大的內(nèi)存空間。比如超過 1TB 甚至比主存還大的空間。

缺點(diǎn)總結(jié)如下：

堆外內(nèi)存難以控制，如果內(nèi)存泄漏，那么很難排查，通過-XX：MaxDirectMemerySize來指定，當(dāng)達(dá)到閾值的時候，調(diào)用system.gc來進(jìn)行一次full gc堆外內(nèi)存相對來說，不適合存儲很復(fù)雜的對象。一般簡單的對象或者扁平化的比較適合jstat查看內(nèi)存回收概況，實(shí)時查看各個分區(qū)的分配回收情況，jmap查看內(nèi)存棧，查看內(nèi)存中對象占用大小，jstack查看線程棧，死鎖，性能瓶頸

JVM七種垃圾收集器

（1）：Serial 收集器 復(fù)制算法，單線程，新生代）

（2）：ParNew 收集器（復(fù)制算法，多線程，新生代）

（3）：Parallel Scavenge 收集器（多線程，復(fù)制算法，新生代，高吞吐量）

（4）：Serial Old 收集器（標(biāo)記-整理算法，老年代）

（5）：Parallel Old 收集器（標(biāo)記-整理算法，老年代，注重吞吐量的場景下，jdk8默認(rèn)采用 Parallel Scavenge + Parallel Old 的組合）

（6）：CMS 收集器（標(biāo)記-清除算法，老年代，垃圾回收線程幾乎能做到與用戶線程同時工作，吞吐量低，內(nèi)存碎片）以犧牲吞吐量為代價來獲得最短回收停頓時間-XX：+UseConcMarkSweepGCjdk1.8 默認(rèn)垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）jdk1.9 默認(rèn)垃圾收集器G1

使用場景：

（1）：應(yīng)用程序?qū)νｎD比較敏感

（2）：在JVM中，有相對較多存活時間較長的對象（老年代比較大）會更適合使用CMS

cms垃圾回收過程：

（1）：初始標(biāo)識<找到gcroot（stw）>

GC Roots有以下幾種：

1：系統(tǒng)類加載器加載的對象

2：處于激活狀態(tài)的線程

3：JNI棧中的對象

4：正在被用于同步的各種鎖對象

5：JVM自身持有的對象，比如系統(tǒng)類加載器等。

（2）：并發(fā)標(biāo)記（三色標(biāo)記算法）三色標(biāo)記算法處理并發(fā)標(biāo)記出現(xiàn)對象引用變化情況：黑：自己+子對象標(biāo)記完成灰：自己完成，子對象未完成白：未標(biāo)記；并發(fā)標(biāo)記 黑->灰->白重新標(biāo)記 灰->白引用消失，黑引用指向->白，導(dǎo)致白漏標(biāo)cms處理辦法是incremental update方案 （增量更新）把黑色變成灰色多線程下并發(fā)標(biāo)記依舊會產(chǎn)生漏標(biāo)問題，所以cms必須remark一遍（jdk1.9以后不用cms了）

G1 處理方案：

SATB（snapshot at the begining）把白放入棧中，標(biāo)記過程是和應(yīng)用程序并發(fā)運(yùn)行的（不需要Stop-The-World）這種方式會造成某些是垃圾的對象也被當(dāng)做是存活的，所以G1會使得占用的內(nèi)存被實(shí)際需要的內(nèi)存大。不過下一次就回收了ZGC 處理方案：顏色指針（color pointers） 2*42方=4T

（3）：重新標(biāo)記（stw）

（4）并發(fā)清理

備注：重新標(biāo)記是防止標(biāo)記成垃圾之后，對象被引用

（5）：G1 收集器（新生代 + 老年代，在多 CPU 和大內(nèi)存的場景下有很好的性能）G1在java9 便是默認(rèn)的垃圾收集器，是cms 的替代者邏輯分代，用分區(qū)（region）的思想（默認(rèn)分2048份） 還是有stw為解決CMS算法產(chǎn)生空間碎片HotSpot提供垃圾收集器，通過-XX：+UseG1GC來啟用

G1中提供了三種模式垃圾回收模式

（1）：young gc（eden region被耗盡無法申請內(nèi)存時，就會觸發(fā)）

（2）：mixed gc（當(dāng)老年代大小占整個堆大小百分比達(dá)到該閾值時，會觸發(fā)）

（3）：full gc（對象內(nèi)存分配速度過快，mixed gc來不及回收，導(dǎo)致老年代被填滿，就會觸發(fā)）

（8）：ZGC和shenandoah （oracle產(chǎn)收費(fèi)） no stw

arthas 監(jiān)控工具

（1）：dashboard命令查看總體jvm運(yùn)行情況

（2）：jvm顯示jvm詳細(xì)信息

（3）：thread 顯示jvm里面所有線程信息（類似于jstack）  查看死鎖線程命令thread -b

（4）：sc * 顯示所有類（search class）

（5）：trace 跟蹤方法

定位頻繁full GC，堆內(nèi)存滿 oom

第一步：jps獲取進(jìn)程號第二步：jmap -histo pid | head -20 得知有個對象在不斷創(chuàng)建備注：jmap如果線上服務(wù)器堆內(nèi)存特別大，，會卡死需堆轉(zhuǎn)存（一般會說在測試環(huán)境壓測，導(dǎo)出轉(zhuǎn)存）-XX：+HeapDumpOnOutOfMemoryError或jmap -dumpLformat=b，file=xxx pid 轉(zhuǎn)出文件進(jìn)行分析（arthas沒有實(shí)現(xiàn)jmap命令）heapdump --live /xxx/xx.hprof導(dǎo)出文件

G1垃圾回收器（重點(diǎn)）

回收過程（1）：young gc（年輕代回收）--當(dāng)年輕代的Eden區(qū)用盡時--stw第一階段，掃描根。根是指static變量指向的對象，正在執(zhí)行的方法調(diào)用鏈條上的局部變量等第二階段，更新RS（Remembered Sets）。處理dirty card queue中的card，更新RS。此階段完成后，RS可以準(zhǔn)確的反映老年代對所在的內(nèi)存分段中對象的引用第三階段，處理RS。識別被老年代對象指向的Eden中的對象，這些被指向的Eden中的對象被認(rèn)為是存活的對象。第四階段，復(fù)制對象。此階段，對象樹被遍歷，Eden區(qū)內(nèi)存段中存活的對象會被復(fù)制到Survivor區(qū)中空的內(nèi)存分段第五階段，處理引用。處理Soft，Weak，Phantom，F(xiàn)inal，JNI Weak 等引用。

（2）：concrruent marking（老年代并發(fā)標(biāo)記）當(dāng)堆內(nèi)存使用達(dá)到一定值（默認(rèn)45%）時，不需要Stop-The-World，在并發(fā)標(biāo)記前先進(jìn)行一次young gc

（3）：混合回收（mixed gc）并發(fā)標(biāo)記過程結(jié)束以后，緊跟著就會開始混合回收過程?；旌匣厥盏囊馑际悄贻p代和老年代會同時被回收

（4）：Full GC?Full GC是指上述方式不能正常工作，G1會停止應(yīng)用程序的執(zhí)行，使用單線程的內(nèi)存回收算法進(jìn)行垃圾回收，性能會非常差，應(yīng)用程序停頓時間會很長。要避免Full GC的發(fā)生，一旦發(fā)生需要進(jìn)行調(diào)整。

什么時候發(fā)生Full GC呢？

比如堆內(nèi)存太小，當(dāng)G1在復(fù)制存活對象的時候沒有空的內(nèi)存分段可用，則會回退到full gc，這種情況可以通過增大內(nèi)存解決

盡管G1堆內(nèi)存仍然是分代的，但是同一個代的內(nèi)存不再采用連續(xù)的內(nèi)存結(jié)構(gòu)

年輕代分為Eden和Survivor兩個區(qū)，老年代分為Old和Humongous兩個區(qū)

新分配的對象會被分配到Eden區(qū)的內(nèi)存分段上

Humongous區(qū)用于保存大對象，如果一個對象占用的空間超過內(nèi)存分段Region的一半；

如果對象的大小超過一個甚至幾個分段的大小，則對象會分配在物理連續(xù)的多個Humongous分段上。

Humongous對象因?yàn)檎加脙?nèi)存較大并且連續(xù)會被優(yōu)先回收

為了在回收單個內(nèi)存分段的時候不必對整個堆內(nèi)存的對象進(jìn)行掃描（單個內(nèi)存分段中的對象可能被其他內(nèi)存分段中的對象引用）引入了RS數(shù)據(jù)結(jié)構(gòu)。RS使得G1可以在年輕代回收的時候不必去掃描老年代的對象，從而提高了性能。每一個內(nèi)存分段都對應(yīng)一個RS，RS保存了來自其他分段內(nèi)的對象對于此分段的引用

JVM會對應(yīng)用程序的每一個引用賦值語句object.field=object進(jìn)行記錄和處理，把引用關(guān)系更新到RS中。但是這個RS的更新并不是實(shí)時的。G1維護(hù)了一個Dirty Card Queue

那為什么不在引用賦值語句處直接更新RS呢？

這是為了性能的需要，使用隊(duì)列性能會好很多。

線程本地分配緩沖區(qū)（TLAB：Thread Local Allocation Buffer）?

棧上分配->tlab->堆上分配由于堆內(nèi)存是應(yīng)用程序共享的，應(yīng)用程序的多個線程在分配內(nèi)存的時候需要加鎖以進(jìn)行同步。為了避免加鎖，提高性能每一個應(yīng)用程序的線程會被分配一個TLAB。TLAB中的內(nèi)存來自于G1年輕代中的內(nèi)存分段。當(dāng)對象不是Humongous對象，TLAB也能裝的下的時候，對象會被優(yōu)先分配于創(chuàng)建此對象的線程的TLAB中。這樣分配會很快，因?yàn)門LAB隸屬于線程，所以不需要加鎖

PLAB：Promotion Thread Local Allocation Buffer

G1會在年輕代回收過程中把Eden區(qū)中的對象復(fù)制（“提升”）到Survivor區(qū)中，Survivor區(qū)中的對象復(fù)制到Old區(qū)中。G1的回收過程是多線程執(zhí)行的，為了避免多個線程往同一個內(nèi)存分段進(jìn)行復(fù)制，那么復(fù)制的過程也需要加鎖。為了避免加鎖，G1的每個線程都關(guān)聯(lián)了一個PLAB，這樣就不需要進(jìn)行加鎖了

OOM問題定位方法

（1）：jmap -heap 10765如上圖，可以查看新生代，老生代堆內(nèi)存的分配大小以及使用情況；

（2）：jstat 查看GC收集情況

（3）：jmap -dump：live，format=b，file=到本地

（4）：通過MAT工具打開分析

DUBBO

dubbo流程

（1）：生產(chǎn)者（Provider）啟動，向注冊中心（Register）注冊

（2）：消費(fèi)者（Consumer）訂閱，而后注冊中心通知消費(fèi)者

（3）：消費(fèi)者從生產(chǎn)者進(jìn)行消費(fèi)

（4）：監(jiān)控中心（Monitor）統(tǒng)計(jì)生產(chǎn)者和消費(fèi)者

Dubbo推薦使用什么序列化框架，還有哪些？

推薦使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化

Dubbo默認(rèn)使用的是什么通信框架，還有哪些？

默認(rèn)使用 Netty 框架，也是推薦的選擇，另外內(nèi)容還集成有Mina、Grizzly。

Dubbo有哪幾種負(fù)載均衡策略，默認(rèn)是哪種?

（1）：隨機(jī)調(diào)用<默認(rèn)>

（2）：權(quán)重輪詢

（3）：最少活躍數(shù)

（4）：一致性Hash

RPC流程

（1）消費(fèi)者調(diào)用需要消費(fèi)的服務(wù)，

（2）：客戶端存根將方法、入?yún)⒌刃畔⑿蛄谢l(fā)送給服務(wù)端存根

（3）：服務(wù)端存根反序列化操作根據(jù)解碼結(jié)果調(diào)用本地的服務(wù)進(jìn)行相關(guān)處理

（4）：本地服務(wù)執(zhí)行具體業(yè)務(wù)邏輯并將處理結(jié)果返回給服務(wù)端存根

（5）：服務(wù)端存根序列化

（6）：客戶端存根反序列化

（7）：服務(wù)消費(fèi)方得到最終結(jié)果

RPC框架的實(shí)現(xiàn)目標(biāo)PC框架的實(shí)現(xiàn)目標(biāo)是把調(diào)用、編碼/解碼的過程給封裝起來，讓用戶感覺上像調(diào)用本地服務(wù)一樣的調(diào)用遠(yuǎn)程服務(wù)

服務(wù)暴露、服務(wù)引用、服務(wù)調(diào)用（TODO）

Redis

redis單線程為什么執(zhí)行速度這么快?

（1）：純內(nèi)存操作，避免大量訪問數(shù)據(jù)庫，減少直接讀取磁盤數(shù)據(jù)，redis將數(shù)據(jù)儲存在內(nèi)存里面，讀寫數(shù)據(jù)的時候都不會受到硬盤 I/O 速度的限制，所以速度快

（2）：單線程操作，避免了不必要的上下文切換和競爭條件，也不存在多進(jìn)程或者多線程導(dǎo)致的切換而消耗CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因?yàn)榭赡艹霈F(xiàn)死鎖而導(dǎo)致的性能消耗

（3）：采用了非阻塞I/O多路復(fù)用機(jī)制

Redis數(shù)據(jù)結(jié)構(gòu)底層實(shí)現(xiàn)

String：

（1）Simple dynamic string（SDS）的數(shù)據(jù)結(jié)構(gòu)

它的優(yōu)點(diǎn)：（1）不會出現(xiàn)字符串變更造成的內(nèi)存溢出問題

（2）獲取字符串長度時間復(fù)雜度為1

（3）空間預(yù)分配， 惰性空間釋放free字段，會默認(rèn)留夠一定的空間防止多次重分配內(nèi)存

應(yīng)用場景：String 緩存結(jié)構(gòu)體用戶信息，計(jì)數(shù)

Hash：

數(shù)組+鏈表的基礎(chǔ)上，進(jìn)行了一些rehash優(yōu)化；1.Reids的Hash采用鏈地址法來處理沖突，然后它沒有使用紅黑樹優(yōu)化。

2.哈希表節(jié)點(diǎn)采用單鏈表結(jié)構(gòu)。

3.rehash優(yōu)化 （采用分而治之的思想，將龐大的遷移工作量劃分到每一次CURD中，避免了服務(wù)繁忙）

應(yīng)用場景：保存結(jié)構(gòu)體信息可部分獲取不用序列化所有字段

List：

應(yīng)用場景：（1）：比如twitter的關(guān)注列表，粉絲列表等都可以用Redis的list結(jié)構(gòu)來實(shí)現(xiàn)

（2）：list的實(shí)現(xiàn)為一個雙向鏈表，即可以支持反向查找和遍歷

Set：

內(nèi)部實(shí)現(xiàn)是一個 value為null的HashMap，實(shí)際就是通過計(jì)算hash的方式來快速排重的，這也是set能提供判斷一個成員 是否在集合內(nèi)的原因。應(yīng)用場景：去重的場景，交集（sinter）、并集（sunion）、差集（sdiff），實(shí)現(xiàn)如共同關(guān)注、共同喜好、二度好友等功能

Zset：

內(nèi)部使用HashMap和跳躍表（SkipList）來保證數(shù)據(jù)的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表里存放的是所有的成員，排序依據(jù)是HashMap里存的score，使用跳躍表的結(jié)構(gòu)可以獲得比較高的查找效率，并且在實(shí)現(xiàn)上比較簡單。跳表：每個節(jié)點(diǎn)中維持多個指向其他節(jié)點(diǎn)的指針，從而達(dá)到快速訪問節(jié)點(diǎn)的目的應(yīng)用場景：實(shí)現(xiàn)延時隊(duì)列

redis事務(wù)

（1）：Multi開啟事務(wù)

（2）：Exec執(zhí)行事務(wù)塊內(nèi)命令

（3）：Discard 取消事務(wù)

（4）：Watch 監(jiān)視一個或多個key，如果事務(wù)執(zhí)行前key被改動，事務(wù)將打斷

redis事務(wù)的實(shí)現(xiàn)特征

（1）：所有命令都將會被串行化的順序執(zhí)行，事務(wù)執(zhí)行期間，Redis不會再為其它客戶端的請求提供任何服務(wù)，從而保證了事物中的所有命令被原子的執(zhí)行

（2）：Redis事務(wù)中如果有某一條命令執(zhí)行失敗，其后的命令仍然會被繼續(xù)執(zhí)行

（3）：在事務(wù)開啟之前，如果客戶端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開，其后所有待執(zhí)行的語句都將不會被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶端執(zhí)行EXEC命令之后，那么該事務(wù)中的所有命令都會被服務(wù)器執(zhí)行

（4）：當(dāng)使用Append-Only模式時，Redis會通過調(diào)用系統(tǒng)函數(shù)write將該事務(wù)內(nèi)的所有寫操作在本次調(diào)用中全部寫入磁盤。

然而如果在寫入的過程中出現(xiàn)系統(tǒng)崩潰，如電源故障導(dǎo)致的宕機(jī)，那么此時也許只有部分?jǐn)?shù)據(jù)被寫入到磁盤，而另外一部分?jǐn)?shù)據(jù)卻已經(jīng)丟失。

Redis服務(wù)器會在重新啟動時執(zhí)行一系列必要的一致性檢測，一旦發(fā)現(xiàn)類似問題，就會立即退出并給出相應(yīng)的錯誤提示。此時，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到數(shù)據(jù)不一致的錯誤，并將已經(jīng)寫入的部分?jǐn)?shù)據(jù)進(jìn)行回滾。修復(fù)之后我們就可以再次重新啟動Redis服務(wù)器了

Redis的同步機(jī)制？

（1）：全量拷貝，1.slave第一次啟動時，連接Master，發(fā)送PSYNC命令，

2.master會執(zhí)行bgsave命令來生成rdb文件，期間的所有寫命令將被寫入緩沖區(qū)。

3. master bgsave執(zhí)行完畢，向slave發(fā)送rdb文件

4. slave收到rdb文件，丟棄所有舊數(shù)據(jù)，開始載入rdb文件

5. rdb文件同步結(jié)束之后，slave執(zhí)行從master緩沖區(qū)發(fā)送過來的所以寫命令。

6. 此后 master 每執(zhí)行一個寫命令，就向slave發(fā)送相同的寫命令。

   （2）：增量拷貝如果出現(xiàn)網(wǎng)絡(luò)閃斷或者命令丟失等異常情況，從節(jié)點(diǎn)之前保存了自身已復(fù)制的偏移量和主節(jié)點(diǎn)的運(yùn)行ID

7. 主節(jié)點(diǎn)根據(jù)偏移量把復(fù)制積壓緩沖區(qū)里的數(shù)據(jù)發(fā)送給從節(jié)點(diǎn)，保證主從復(fù)制進(jìn)入正常狀態(tài)。

   redis集群模式性能優(yōu)化

   （1） Master最好不要做任何持久化工作，如RDB內(nèi)存快照和AOF日志文件

   （2） 如果數(shù)據(jù)比較重要，某個Slave開啟AOF備份數(shù)據(jù)，策略設(shè)置為每秒同步一次

   （3） 為了主從復(fù)制的速度和連接的穩(wěn)定性，Master和Slave最好在同一個局域網(wǎng)內(nèi)

   （4） 盡量避免在壓力很大的主庫上增加從庫

   （5） 主從復(fù)制不要用圖狀結(jié)構(gòu)，用單向鏈表結(jié)構(gòu)更為穩(wěn)定，即：Master <- Slave1 <- Slave2 <- Slave3…這樣的結(jié)構(gòu)方便解決單點(diǎn)故障問題，實(shí)現(xiàn)Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。

   Redis集群方案

   （1）：官方cluster方案

   （2）：twemproxy

   代理方案twemproxy是一個單點(diǎn)，很容易對其造成很大的壓力，所以通常會結(jié)合keepalived來實(shí)twemproy的高可用

   （3）：codis基于客戶端來進(jìn)行分片

集群不可用場景

（1）：master掛掉，且當(dāng)前master沒有slave

（2）：集群超過半數(shù)以上master掛掉，無論是否有slave集群進(jìn)入fail狀態(tài)

redis 最適合的場景

（1）：會話緩存session cache

（2）：排行榜/計(jì)數(shù)器ZRANGE

（3）：發(fā)布/訂閱

緩存淘汰策略

（1）：先進(jìn)先出算法（FIFO）

（2）：最近使用最少Least Frequently Used（LFU）

（3）：最長時間未被使用的Least Recently Used（LRU）

當(dāng)存在熱點(diǎn)數(shù)據(jù)時，LRU的效率很好，但偶發(fā)性的、周期性的批量操作會導(dǎo)致LRU命中率急劇下降，緩存污染情況比較嚴(yán)重

redis過期key刪除策略

（1）：惰性刪除，cpu友好，但是浪費(fèi)cpu資源

（2）：定時刪除（不常用）

（3）：定期刪除，cpu友好，節(jié)省空間

緩存雪崩以及處理辦法

同一時刻大量緩存失效；

處理方法：

（1）：緩存數(shù)據(jù)增加過期標(biāo)記

（2）：設(shè)置不同的緩存失效時間

（3）：雙層緩存策略C1為短期，C2為長期

（4）：定時更新策略

緩存擊穿原因以及處理辦法

頻繁請求查詢系統(tǒng)中不存在的數(shù)據(jù)導(dǎo)致；

處理方法：

（1）：cache null策略，查詢反饋結(jié)果為null仍然緩存這個null結(jié)果，設(shè)置不超過5分鐘過期時間

（2）：布隆過濾器，所有可能存在的數(shù)據(jù)映射到足夠大的bitmap中g(shù)oogle布隆過濾器：基于內(nèi)存，重啟失效不支持大數(shù)據(jù)量，無法在分布式場景redis布隆過濾器：可擴(kuò)展性，不存在重啟失效問題，需要網(wǎng)絡(luò)io，性能低于google

redis阻塞原因

（1）：數(shù)據(jù)結(jié)構(gòu)使用不合理bigkey

（2）：CPU飽和

（3）：持久化阻塞，rdb fork子線程，aof每秒刷盤等

hot key出現(xiàn)造成集群訪問量傾斜解決辦法

（1）：使用本地緩存

（2）：利用分片算法的特性，對key進(jìn)行打散處理（給hot key加上前綴或者后綴，把一個hotkey 的數(shù)量變成 redis 實(shí)例個數(shù)N的倍數(shù)M，從而由訪問一個 redis key 變成訪問 N * M 個redis key）

Redis分布式鎖

2.6版本以后lua腳本保證setnx跟setex進(jìn)行原子性（setnx之后，未setex，服務(wù)掛了，鎖不釋放）a獲取鎖，超過過期時間，自動釋放鎖，b獲取到鎖執(zhí)行，a代碼執(zhí)行完remove鎖，a和b是一樣的key，導(dǎo)致a釋放了b的鎖。解決辦法：remove之前判斷value（高并發(fā)下value可能被修改，應(yīng)該用lua來保證原子性）

Redis如何做持久化

bgsave做鏡像全量持久化，aof做增量持久化。因?yàn)閎gsave會耗費(fèi)較長時間，不夠?qū)崟r，在停機(jī)的時候會導(dǎo)致大量丟失數(shù)據(jù) ，所以需要aof來配合使用。在redis實(shí)例重啟時，會使用bgsave持久化文件重新構(gòu)建內(nèi)存，再使用aof重放近期的操作指令來 實(shí) 現(xiàn)完整恢復(fù)重啟之前的狀態(tài)。

對方追問那如果突然機(jī)器掉電會怎樣？

取決于aof日志sync屬性的配置，如果不要求性能，在每條寫指令時都sync一下磁盤，就不會丟失數(shù)據(jù)。但是在高性能的要求下每次都sync是不現(xiàn)實(shí)的，一般都使用定時sync，比如1s1次，這個時候最多就會丟失1s的數(shù)據(jù).

redis鎖續(xù)租問題?

（1）：基于redis的redission分布式可重入鎖RLock，以及配合java集合中l(wèi)ock；

（2）：Redission 內(nèi)部提供了一個監(jiān)控鎖的看門狗，不斷延長鎖的有效期，默認(rèn)檢查鎖的超時時間是30秒

（3）：此方案的問題：如果你對某個redis master實(shí)例，寫入了myLock這種鎖key的value，此時會異步復(fù)制給對應(yīng)的master ，slave實(shí)例。但是這個過程中一旦發(fā)生redis master宕機(jī)，主備切換，redis slave變?yōu)榱藃edis master。

接著就會導(dǎo)致，客戶端2來嘗試加鎖的時候，在新的redis master上完成了加鎖，而客戶端1也以為自己成功加了鎖。此時就會導(dǎo)致多個客戶端對一個分布式鎖完成了加鎖解決辦法：只需要將新的redis實(shí)例，在一個TTL時間內(nèi)，對客戶端不可用即可，在這個時間內(nèi)，所有客戶端鎖將被失效或者自動釋放.

bgsave的原理是什么？

fork和cow。fork是指redis通過創(chuàng)建子進(jìn)程來進(jìn)行bgsave操作，cow指的是copy on write，子進(jìn)程創(chuàng)建后，父子進(jìn)程共享數(shù)據(jù)段，父進(jìn)程繼續(xù)提供讀寫服務(wù)，寫進(jìn)的頁面數(shù)據(jù)會逐漸和子進(jìn)程分離開來。

RDB與AOF區(qū)別

（1）：R文件格式緊湊，方便數(shù)據(jù)恢復(fù)，保存rdb文件時父進(jìn)程會fork出子進(jìn)程由其完成具體持久化工作，最大化redis性能，恢復(fù)大數(shù)據(jù)集速度更快，只有手動提交save命令或關(guān)閉命令時才觸發(fā)備份操作；

（2）：A記錄對服務(wù)器的每次寫操作（默認(rèn)1s寫入一次），保存數(shù)據(jù)更完整，在redis重啟是會重放這些命令來恢復(fù)數(shù)據(jù)，操作效率高，故障丟失數(shù)據(jù)更少，但是文件體積更大；

1億個key，其中有10w個key是以某個固定的已知的前綴開頭的，如果將它們?nèi)空页鰜恚?/span>

使用keys指令可以掃出指定模式的key列表。如果這個redis正在給線上的業(yè)務(wù)提供服務(wù)，那使用keys指令會有什么問題？redis的單線程的。keys指令會導(dǎo)致線程阻塞一段時間，線上服務(wù)會停頓，直到指令執(zhí)行完畢，服務(wù)才能恢復(fù)。這個時候可以使用scan指令，scan指令可以無阻塞的提取出指定模式的key列表，但是會有一定的重復(fù)概率，在客戶端做一次去重就可以了 ，但是整體所花費(fèi)的時間會比直接用keys指令長。

如何使用Redis做異步隊(duì)列?

一般使用list結(jié)構(gòu)作為隊(duì)列，rpush生產(chǎn)消息，lpop消費(fèi)消息。當(dāng)lpop沒有消息的時候，要適當(dāng)sleep一會再重試。

可不可以不用sleep呢？

list還有個指令叫blpop，在沒有消息的時候，它會阻塞住直到消息到來。

能不能生產(chǎn)一次消費(fèi)多次呢？

使用pub/sub主題訂閱者模式，可以實(shí)現(xiàn)1：N的消息隊(duì)列。

pub/sub有什么缺點(diǎn)？

在消費(fèi)者下線的情況下，生產(chǎn)的消息會丟失，得使用專業(yè)的消息隊(duì)列如rabbitmq等。

redis如何實(shí)現(xiàn)延時隊(duì)列？

使用sortedset，想要執(zhí)行時間的時間戳作為score，消息內(nèi)容作為key調(diào)用zadd來生產(chǎn)消息，消費(fèi)者用zrangebyscore指令獲取N秒之前的數(shù)據(jù)輪詢進(jìn)行處理。

為啥redis zset使用跳躍鏈表而不用紅黑樹實(shí)現(xiàn)?

（1）：skiplist的復(fù)雜度和紅黑樹一樣，而且實(shí)現(xiàn)起來更簡單。

（2）：在并發(fā)環(huán)境下紅黑樹在插入和刪除時需要rebalance，性能不如跳表。

MYSQL

數(shù)據(jù)庫三范式

一：確保每列的原子性

二：非主鍵列不存在對主鍵的部分依賴 （要求每個表只描述一件事情）

三：滿足第二范式，并且表中的列不存在對非主鍵列的傳遞依賴

數(shù)據(jù)庫主從復(fù)制原理

（1）：主庫db的更新事件（update、insert、delete）被寫到binlog

（2）：主庫創(chuàng)建一個binlog dump thread線程，把binlog的內(nèi)容發(fā)送到從庫

（3）：從庫創(chuàng)建一個I/O線程，讀取主庫傳過來的binlog內(nèi)容并寫入到relay log.

（4）：從庫還會創(chuàng)建一個SQL線程，從relay log里面讀取內(nèi)容寫入到slave的db.

復(fù)制方式分類

（1）：異步復(fù)制（默認(rèn)）主庫寫入binlog日志后即可成功返回客戶端，無須等待binlog日志傳遞給從庫的過程，但是一旦主庫宕機(jī)，就有可能出現(xiàn)丟失數(shù)據(jù)的情況。

（2）半同步復(fù)制：（ 5.5版本之后）（安裝半同步復(fù)制插件）確保從庫接收完成主庫傳遞過來的binlog內(nèi)容已經(jīng)寫入到自己的relay log（傳送log）后才會通知主庫上面的等待線程。如果等待超時，則關(guān)閉半同步復(fù)制，并自動轉(zhuǎn)換為異步復(fù)制模式，直到至少有一臺從庫通知主庫已經(jīng)接收到binlog信息為止

存儲引擎

（1）：Myiasm是mysql默認(rèn)的存儲引擎，不支持?jǐn)?shù)據(jù)庫事務(wù)，行級鎖，外鍵；插入更新需鎖表，效率低，查詢速度快，Myisam使用的是非聚集索引

（2）：innodb 支持事務(wù)，底層為B+樹實(shí)現(xiàn)，適合處理多重并發(fā)更新操作，普通select都是快照讀，快照讀不加鎖。InnoDb使用的是聚集索引

聚集索引

（1）：聚集索引就是以主鍵創(chuàng)建的索引

（2）：每個表只能有一個聚簇索引，因?yàn)橐粋€表中的記錄只能以一種物理順序存放，實(shí)際的數(shù)據(jù)頁只能按照一顆 B+ 樹進(jìn)行排序

（3）：表記錄的排列順序和與索引的排列順序一致

（4）：聚集索引存儲記錄是物理上連續(xù)存在

（5）：聚簇索引主鍵的插入速度要比非聚簇索引主鍵的插入速度慢很多

（6）：聚簇索引適合排序，非聚簇索引不適合用在排序的場合，因?yàn)榫鄞厮饕~節(jié)點(diǎn)本身就是索引和數(shù)據(jù)按相同順序放置在一起，索引序即是數(shù)據(jù)序，數(shù)據(jù)序即是索引序，所以很快。非聚簇索引葉節(jié)點(diǎn)是保留了一個指向數(shù)據(jù)的指針，索引本身當(dāng)然是排序的，但是數(shù)據(jù)并未排序，數(shù)據(jù)查詢的時候需要消耗額外更多的I/O，所以較慢

（7）：更新聚集索引列的代價很高，因?yàn)闀?qiáng)制innodb將每個被更新的行移動到新的位置

非聚集索引

（1）：除了主鍵以外的索引

（2）：聚集索引的葉節(jié)點(diǎn)就是數(shù)據(jù)節(jié)點(diǎn)，而非聚簇索引的葉節(jié)點(diǎn)仍然是索引節(jié)點(diǎn)，并保留一個鏈接指向?qū)?yīng)數(shù)據(jù)塊

（3）：聚簇索引適合排序，非聚簇索引不適合用在排序的場合

（4）：聚集索引存儲記錄是物理上連續(xù)存在，非聚集索引是邏輯上的連續(xù)。

使用聚集索引為什么查詢速度會變快？

使用聚簇索引找到包含第一個值的行后，便可以確保包含后續(xù)索引值的行在物理相鄰

建立聚集索引有什么需要注意的地方嗎？

在聚簇索引中不要包含經(jīng)常修改的列，因?yàn)榇a值修改后，數(shù)據(jù)行必須移動到新的位置，索引此時會重排，會造成很大的資源浪費(fèi)

InnoDB 表對主鍵生成策略是什么樣的？

優(yōu)先使用用戶自定義主鍵作為主鍵，如果用戶沒有定義主鍵，則選取一個Unique鍵作為主鍵，如果表中連Unique鍵都沒有定義的話，則InnoDB會為表默認(rèn)添加一個名為row_id隱藏列作為主鍵。

非聚集索引最多可以有多少個？

每個表你最多可以建立249個非聚簇索引。非聚簇索引需要大量的硬盤空間和內(nèi)存

BTree 與 Hash 索引有什么區(qū)別？

（1）：BTree索引可能需要多次運(yùn)用折半查找來找到對應(yīng)的數(shù)據(jù)塊（2）：HASH索引是通過HASH函數(shù)，計(jì)算出HASH值，在表中找出對應(yīng)的數(shù)據(jù)（3）：大量不同數(shù)據(jù)等值精確查詢，HASH索引效率通常比B+TREE高（4）：HASH索引不支持模糊查詢、范圍查詢和聯(lián)合索引中的最左匹配規(guī)則，而這些Btree索引都支持

數(shù)據(jù)庫索引優(yōu)缺點(diǎn)

（1）：需要查詢，排序，分組和聯(lián)合操作的字段適合建立索引

（2）：索引多，數(shù)據(jù)更新表越慢，盡量使用字段值不重復(fù)比例大的字段作為索引，聯(lián)合索引比多個獨(dú)立索引效率高

（3）：對數(shù)據(jù)進(jìn)行頻繁查詢進(jìn)建立索引，如果要頻繁更改數(shù)據(jù)不建議使用索引

（4）：當(dāng)對表中的數(shù)據(jù)進(jìn)行增加、刪除和修改的時候，索引也要動態(tài)的維護(hù)，降低了數(shù)據(jù)的維護(hù)速度。

索引的底層實(shí)現(xiàn)是B+樹，為何不采用紅黑樹，B樹?

（1）：B+Tree非葉子節(jié)點(diǎn)只存儲鍵值信息，降低B+Tree的高度，所有葉子節(jié)點(diǎn)之間都有一個鏈指針，數(shù)據(jù)記錄都存放在葉子節(jié)點(diǎn)中

（2）：紅黑樹這種結(jié)構(gòu)，h明顯要深的多，效率明顯比B-Tree差很多

（3）：B+樹也存在劣勢，由于鍵會重復(fù)出現(xiàn)，因此會占用更多的空間。但是與帶來的性能優(yōu)勢相比，空間劣勢往往可以接受，因此B+樹的在數(shù)據(jù)庫中的使用比B樹更加廣泛

索引失效條件

（1）：條件是or，如果還想讓or條件生效，給or每個字段加個索引

（2）：like開頭%

（3）：如果列類型是字符串，那一定要在條件中將數(shù)據(jù)使用引號引用起來，否則不會使用索引

（4）：where中索引列使用了函數(shù)或有運(yùn)算

數(shù)據(jù)庫事務(wù)特點(diǎn)

ACID 原子性，一致性，隔離性，永久性

數(shù)據(jù)庫事務(wù)說是如何實(shí)現(xiàn)的?

（1）：通過預(yù)寫日志方式實(shí)現(xiàn)的，redo和undo機(jī)制是數(shù)據(jù)庫實(shí)現(xiàn)事務(wù)的基礎(chǔ)

（2）：redo日志用來在斷電/數(shù)據(jù)庫崩潰等狀況發(fā)生時重演一次刷數(shù)據(jù)的過程，把redo日志里的數(shù)據(jù)刷到數(shù)據(jù)庫里，保證了事務(wù) 的持久性（Durability）

（3）：undo日志是在事務(wù)執(zhí)行失敗的時候撤銷對數(shù)據(jù)庫的操作，保證了事務(wù)的原子性

數(shù)據(jù)庫事務(wù)隔離級別

（1）：讀未提交read-uncommitted-- 臟，不可重復(fù)讀--幻讀A讀取了B未提交的事務(wù)，B回滾，A 出現(xiàn)臟讀；

（2）：不可重復(fù)讀read-committed-- 不可重復(fù)讀--幻讀A只能讀B已提交的事務(wù)，但是A還沒結(jié)束，B又更新數(shù)據(jù)隱式提交，然后A又讀了一次出現(xiàn)不可重復(fù)讀；

（3）：可重復(fù)讀repeatable-read<默認(rèn)>-- 幻讀事務(wù)開啟，不允許其他事務(wù)的UPDATE修改操作A讀取B已提交的事務(wù)，然而B在該表插入新的行，之后A在讀取的時候多出一行，出現(xiàn)幻讀；

（4）：串行化serializable--

七種事務(wù)傳播行為

（1）Propagation.REQUIRED<默認(rèn)>如果當(dāng)前存在事務(wù)，則加入該事務(wù)，如果當(dāng)前不存在事務(wù)，則創(chuàng)建一個新的事務(wù)。

（2）Propagation.SUPPORTS如果當(dāng)前存在事務(wù)，則加入該事務(wù)；如果當(dāng)前不存在事務(wù)，則以非事務(wù)的方式繼續(xù)運(yùn)行。

（3）Propagation.MANDATORY如果當(dāng)前存在事務(wù)，則加入該事務(wù)；如果當(dāng)前不存在事務(wù)，則拋出異常。

（4）Propagation.REQUIRES_NEW重新創(chuàng)建一個新的事務(wù)，如果當(dāng)前存在事務(wù)，延緩當(dāng)前的事務(wù)。

（5）Propagation.NOT_SUPPORTED以非事務(wù)的方式運(yùn)行，如果當(dāng)前存在事務(wù)，暫停當(dāng)前的事務(wù)。

（6）Propagation.NEVER以非事務(wù)的方式運(yùn)行，如果當(dāng)前存在事務(wù)，則拋出異常。

（7）Propagation.NESTED如果沒有，就新建一個事務(wù)；如果有，就在當(dāng)前事務(wù)中嵌套其他事務(wù)。

產(chǎn)生死鎖的四個必要條件

（1）：互斥：資源x的任意一個時刻只能被一個線程持有（2）：占有且等待：線程1占有資源x的同時等待資源y，并不釋放x（3）：不可搶占：資源x一旦被線程1占有，其他線程不能搶占x（4）：循環(huán)等待：線程1持有x，等待y，線程2持有y，等待x當(dāng)全部滿足時才會死鎖

@Transaction

底層實(shí)現(xiàn)是AOP，動態(tài)代理（1）：實(shí)現(xiàn)是通過Spring代理來實(shí)現(xiàn)的。生成當(dāng)前類的代理類，調(diào)用代理類的invoke（）方法，在invoke（）方法中調(diào)用 TransactionInterceptor攔截器的invoke（）方法；

（2）：非public方式其事務(wù)是失效的；

（3）：自調(diào)用也會失效，因?yàn)閯討B(tài)代理機(jī)制導(dǎo)致

（4）多個方法外層加入try...catch，解決辦法是可以在catch里 throw new RuntimeException（）來處理

分布式事務(wù)

XA方案

有一個事務(wù)管理器的概念，負(fù)責(zé)協(xié)調(diào)多個數(shù)據(jù)庫（資源管理器）的事務(wù)不適合高并發(fā)場景，嚴(yán)重依賴數(shù)據(jù)庫層面，同步阻塞問題；協(xié)調(diào)者故障則所有參與者會阻塞

TCC方案

嚴(yán)重依賴代碼補(bǔ)償和回滾，一般銀行用，和錢相關(guān)的支付、交易等相關(guān)的場景，我們會用TCCTry，對各個服務(wù)的資源做檢測，對資源進(jìn)行鎖定或者預(yù)留Confirm，在各個服務(wù)中執(zhí)行實(shí)際的操作Cancel，如果任何一個服務(wù)的業(yè)務(wù)方法執(zhí)行出錯，那么這里就需要進(jìn)行補(bǔ)償，即執(zhí)行已操作成功的業(yè)務(wù)邏輯的回滾操作

可靠消息最終一致性方案

1）：本地消息服務(wù)本地消息表其實(shí)是國外的 ebay 搞出來的這么一套思想。主動方是認(rèn)證服務(wù)，有個消息異常處理系統(tǒng)，mq，還有消息消費(fèi)端應(yīng)用系統(tǒng)，還有采集服務(wù)；

• 在我認(rèn)證返回數(shù)據(jù)中如果有發(fā)票是已經(jīng)認(rèn)證的，在處理認(rèn)證數(shù)據(jù)的操作與發(fā)送消息在同一個本地事務(wù)中，業(yè)務(wù)執(zhí)行完，消息數(shù)據(jù)也同時存在一條待確認(rèn)的數(shù)據(jù)；
• 發(fā)送消息給mq，，mq發(fā)送消息給消息消費(fèi)端服務(wù)，同時存一份消息數(shù)據(jù)，然后發(fā)送給采集服務(wù)，進(jìn)行抵賬表更新操作；
• 采集服務(wù)邏輯處理完以后反饋給消息消費(fèi)端服務(wù)，其服務(wù)刪除消息數(shù)據(jù)，同時通知認(rèn)證服務(wù)，把消息記錄改為已確認(rèn)成功費(fèi)狀態(tài)；
• 對于異常流程，消息異常處理系統(tǒng)會查詢認(rèn)證服務(wù)中過期未確認(rèn)的消息發(fā)送給mq，相當(dāng)于重試

2）：獨(dú)立消息最終一致性方案：A 主動方應(yīng)用系統(tǒng)，B消息服務(wù)子系統(tǒng)，C消息狀態(tài)確認(rèn)子系統(tǒng)，C2消息管理子系統(tǒng)D 消息恢復(fù)子系統(tǒng)，mq ，消息消費(fèi)端E ，被動系統(tǒng)F

 流程：
A預(yù)發(fā)送消息給B，然后執(zhí)行A業(yè)務(wù)邏輯，B存儲預(yù)發(fā)送消息，A執(zhí)行完業(yè)務(wù)邏輯發(fā)送業(yè)務(wù)操作結(jié)果給B，B更新預(yù)發(fā)送消息為確認(rèn)并發(fā)送消息狀態(tài)同時發(fā)送消息給mq，然后被E監(jiān)聽然后發(fā)送給F消費(fèi)掉
C：對預(yù)發(fā)送消息異常的處理，去查詢待確認(rèn)狀態(tài)超時的消息，去A中查詢進(jìn)行數(shù)據(jù)處理，如果A中業(yè)務(wù)處理成功了，那么C需改消息狀態(tài)為確認(rèn)并發(fā)送狀態(tài)，然后發(fā)送消息給mq；如果A中業(yè)務(wù)處理失敗了..那么C直接把消息刪除即可.
C2 ： 查詢消息的頁面，對消息的可視化，以及批量處理死亡消息；
D：B給mq放入數(shù)據(jù)如果失敗，，通過D去重試，多次重試失敗，消息設(shè)置為死亡 
E：確保F執(zhí)行完成，發(fā)送消息給B刪除消息
優(yōu)化建議： 
 （1）數(shù)據(jù)庫：如果用redis，持久化要配置成appendfsync always，確保每次新添加消息都能持久化進(jìn)磁盤
 （2）在被動方應(yīng)用業(yè)務(wù)冪等性判斷比較麻煩或者比較耗性能情況下，增加消息日志記錄表.用于判斷之前有無發(fā)送過；

最大努力通知性（定期校對）

（1）業(yè)務(wù)主動方完成業(yè)務(wù)處理之后，設(shè)置時間階梯型通知規(guī)則向業(yè)務(wù)活動的被動方發(fā)送消息，允許消息丟失.

（2）被動方根據(jù)定時策略，向主動方查詢，恢復(fù)丟失的業(yè)務(wù)消息

（3）被動方的處理結(jié)果不影響主動方的處理結(jié)果

（4）需增加業(yè)務(wù)查詢，通知服務(wù)，校對系統(tǒng)服務(wù)的建設(shè)成本

（5）適用于對業(yè)務(wù)最終一致性的時間敏感度低，跨企業(yè)的業(yè)務(wù)通知活動

（6）比如銀行通知，商戶通知，交易業(yè)務(wù)平臺間商戶通知，多次通知，查詢校對等

Seata（阿里）

應(yīng)用層基于SQL解析實(shí)現(xiàn)了自動補(bǔ)償，從而最大程度的降低業(yè)務(wù)侵入性；將分布式事務(wù)中TC（事務(wù)協(xié)調(diào)者）獨(dú)立部署，負(fù)責(zé)事務(wù)的注冊、回滾；通過全局鎖實(shí)現(xiàn)了寫隔離與讀隔離。

網(wǎng)絡(luò)

TCP和UDP的比較

TCP向上層提供面向連接的可靠服務(wù) ，UDP向上層提供無連接不可靠服務(wù)。雖然 UDP 并沒有 TCP 傳輸來的準(zhǔn)確，但是也能在很多實(shí)時性要求高的地方有所作為對數(shù)據(jù)準(zhǔn)確性要求高，速度可以相對較慢的，可以選用TCP

TCP三次握手

TCP四次揮手

（1）：客戶端發(fā)送終止命令FIN

（2）：服務(wù)端收到后回復(fù)ACK，處于close_wait狀態(tài)

（3）：服務(wù)器將關(guān)閉前需要發(fā)送信息發(fā)送給客戶端后處于last_ack狀態(tài)

（4）：客戶端收到FIN后發(fā)送ack后處于tim-wait而后進(jìn)入close狀態(tài)

為什么要進(jìn)行第三次握手

為了防止服務(wù)器端開啟一些無用的連接增加服務(wù)器開銷以及防止已失效的連接請求報文段突然又傳送到了服務(wù)端

JDK1.8新特性

Lambda表達(dá)式

java也開始承認(rèn)了函數(shù)式編程， 就是說函數(shù)既可以作為參數(shù)，也可以作為返回值，大大的簡化了代碼的開發(fā)

default關(guān)鍵字

打破接口里面是只能有抽象方法，不能有任何方法的實(shí)現(xiàn)，接口里面也可以有方法的實(shí)現(xiàn)了

新時間日期APILocalDate | LocalTime | LocalDateTime

之前使用的java.util.Date月份從0開始，我們一般會+1使用，很不方便，java.time.LocalDate月份和星期都改成了enumjava.util.Date和SimpleDateFormat都不是線程安全的，而LocalDate和LocalTime和最基本的String一樣，是不變類型，不但線程安全，而且不能修改。新接口更好用的原因是考慮到了日期時間的操作，經(jīng)常發(fā)生往前推或往后推幾天的情況。用java.util.Date配合Calendar要寫好多代碼，而且一般的開發(fā)人員還不一定能寫對。

JDK1.7與JDK1.8 ConcurrentHashMap對比

（1）：JDK1.7版本的ReentrantLock+Segment+HashEntry（數(shù)組）

（2）：JDK1.7采用segment的分段鎖機(jī)制實(shí)現(xiàn)線程安全

（3）：JDK1.8版本中synchronized+CAS+HashEntry（數(shù)組）+紅黑樹

（4）：JDK1.8采用CAS+Synchronized保證線程安全

（5）：查詢時間復(fù)雜度從原來的遍歷鏈表O（n），變成遍歷紅黑樹O（logN）

1.8 HashMap數(shù)組+鏈表+紅黑樹來實(shí)現(xiàn)hashmap，當(dāng)碰撞的元素個數(shù)大于8時 & 總?cè)萘看笥?4，會有紅黑樹的引入除了添加之后，效率都比鏈表高，1.8之后鏈表新進(jìn)元素加到末尾

JDK1.8使用synchronized來代替重入鎖ReentrantLock?

（1）：因?yàn)榱６冉档土耍谙鄬Χ缘牡土６燃渔i方式，synchronized并不比ReentrantLock差

（2）：基于JVM的synchronized優(yōu)化空間更大

（3）：在大數(shù)據(jù)量下，基于API的ReentrantLock會比基于JVM的內(nèi)存壓力開銷更多的內(nèi)存

JDK1.9新特性

模塊系統(tǒng)：

模塊是一個包的容器，Java 9 最大的變化之一是引入了模塊系統(tǒng)（Jigsaw 項(xiàng)目）。

集合工廠方法

通常，您希望在代碼中創(chuàng)建一個集合（例如，List 或 Set ），并直接用一些元素填充它。實(shí)例化集合，幾個 “add” 調(diào)用，使得代碼重復(fù)。Java 9，添加了幾種集合工廠方法：

改進(jìn)的 Stream API

Stream 接口中添加了 4 個新的方法：dropWhile， takeWhile， ofNullable。還有個 iterate 方法的新重載方法

改進(jìn)的 Javadoc：

Javadoc 現(xiàn)在支持在 API 文檔中的進(jìn)行搜索。另外，Javadoc 的輸出現(xiàn)在符合兼容 HTML5 標(biāo)準(zhǔn)。

redis代理集群模式，spring有哪些注解，b+b 紅黑樹區(qū)別，三次握手，valitile重排序底層代碼，cas 事務(wù)的4個特性，java8 java11 特性， filter和interceptor的區(qū)別 @autowired原理，dispatcherservlet，分布式事務(wù)解決方案spring都有哪些模塊，fork join隊(duì)列，排序算法，

集合

java的集合框架有哪幾種：

兩種：collection和map，其中collection分為set和List。

List你使用過哪些

ArrayList和linkedList使用的最多，也最具代表性。

你知道vector和ArrayList和linkedList的區(qū)別嘛

ArrayList實(shí)現(xiàn)是一個數(shù)組，可變數(shù)組，默認(rèn)初始化長度為10，也可以我們設(shè)置容量，但是沒有設(shè)置的時候是默認(rèn)的空數(shù)組，只有在第一步add的時候會進(jìn)行擴(kuò)容至10（重新創(chuàng)建了數(shù)組），后續(xù)擴(kuò)容按照3/2的大小進(jìn)行擴(kuò)容，是線程不安全的，適用多讀取，少插入的情況

linkedList是基于雙向鏈表的實(shí)現(xiàn)，使用了尾插法的方式，內(nèi)部維護(hù)了鏈表的長度，以及頭節(jié)點(diǎn)和尾節(jié)點(diǎn)，所以獲取長度不需要遍歷。適合一些插入/刪除頻繁的情況。

Vector是線程安全的，實(shí)現(xiàn)方式和ArrayList相似，也是基于數(shù)組，但是方法上面都有synchronized關(guān)鍵詞修飾。其擴(kuò)容方式是原來的兩倍。

hashMap和hashTable和ConcurrentHashMap的區(qū)別

hashMap是map類型的一種最常用的數(shù)據(jù)結(jié)構(gòu)，其底部實(shí)現(xiàn)是數(shù)組+鏈表（在1.8版本后變?yōu)榱藬?shù)組+鏈表/紅黑樹的方式），其key是可以為null的，默認(rèn)hash值為0。擴(kuò)容以2的冪等次（為什么。。。因?yàn)橹挥惺?的冪等次的時候（n-1）&x==x%n，當(dāng)然不一定只有一個原因）。是線程不安全的

hashTable的實(shí)現(xiàn)形式和hashMap差不多，它是線程安全的，是繼承了Dictionary，也是key-value的模式，但是其key不能為null。

ConcurrentHashMap是JUC并發(fā)包的一種，在hashMap的基礎(chǔ)上做了修改，因?yàn)閔ashmap其實(shí)是線程不安全的，那在并發(fā)情況下使用hashTable嘛，但是hashTable是全程加鎖的，性能不好，所以采用分段的思想，把原本的一個數(shù)組分成默認(rèn)16段，就可以最多容納16個線程并發(fā)操作，16個段叫做Segment，是基于ReetrantLock來實(shí)現(xiàn)的

說說你了解的hashmap吧

hashMap是Map的結(jié)構(gòu)，內(nèi)部用了數(shù)組+鏈表的方式，在1.8后，當(dāng)鏈表長度達(dá)到8的時候，會變成紅黑樹，這樣子就可以把查詢的復(fù)雜度變成O（nlogn）了，默認(rèn)負(fù)載因子是0.75，為什么是0.75呢？

我們知道當(dāng)負(fù)載因子太小，就很容易觸發(fā)擴(kuò)容，如果負(fù)載因子太大就容易出現(xiàn)碰撞。所以這個是空間和時間的一個均衡點(diǎn)，在1.8的hashmap介紹中，就有描述了，貌似是0.75的負(fù)載因子中，能讓隨機(jī)hash更加滿足0.5的泊松分布。

除此之外，1.7的時候是頭插法，1.8后就變成了尾插法，主要是為了解決rehash出現(xiàn)的死循環(huán)問題，而且1.7的時候是先擴(kuò)容后插入，1.8則是先插入后擴(kuò)容(為什么？正常來說，如果先插入，就有可能節(jié)點(diǎn)變?yōu)闃浠敲词遣皇嵌嘧鲆淮螛滢D(zhuǎn)化，比1.7要多損耗，個人猜測，因?yàn)樽x寫問題，因?yàn)閔ashmap并不是線程安全的，如果說是先擴(kuò)容，后寫入，那么在擴(kuò)容期間，是訪問不到新放入的值的，是不是不太合適，所以會先放入值，這樣子在擴(kuò)容期間，那個值是在的）。

1.7版本的時候用了9次擾動，5次異或，4次位移，減少hash沖突，但是1.8就只用了兩次，覺得就足夠了一次異或，一次位移。

concurrentHashMap呢

concurrentHashMap是線程安全的map結(jié)構(gòu)，它的核心思想是分段鎖。在1.7版本的時候，內(nèi)部維護(hù)了segment數(shù)組，默認(rèn)是16個，segment中有一個table數(shù)組（相當(dāng)于一個segmeng存放著一個hashmap。。。），segment繼承了reentrantlock，使用了互斥鎖，map的size其實(shí)就是segment數(shù)組的count和。而在1.8的時候做了一個大改版，廢除了segment，采用了cas加synchronize方式來進(jìn)行分段鎖（還有自旋鎖的保證），而且節(jié)點(diǎn)對象改用了Node不是之前的HashEntity。

Node可以支持鏈表和紅黑樹的轉(zhuǎn)化，比如TreeBin就是繼承了Node，這樣子可以直接用instanceof來區(qū)分。1.8的put就很復(fù)雜來，會先計(jì)算出hash值，然后根據(jù)hash值選出Node數(shù)組的下標(biāo)（默認(rèn)數(shù)組是空的，所以一開始put的時候會初始化，指定負(fù)載因子是0.75，不可變），判斷是否為空，如果為空，則用cas的操作來賦值首節(jié)點(diǎn)，如果失敗，則因?yàn)樽孕瑫M(jìn)入非空節(jié)點(diǎn)的邏輯，這個時候會用synchronize加鎖頭節(jié)點(diǎn)（保證整條鏈路鎖定）這個時候還會進(jìn)行二次判斷，是否是同一個首節(jié)點(diǎn)，在分首節(jié)點(diǎn)到底是鏈表還是樹結(jié)構(gòu)，進(jìn)行遍歷判斷。

concurrentHashMap的擴(kuò)容方式

1.7版本的concurrentHashMap是基于了segment的，segment內(nèi)部維護(hù)了HashEntity數(shù)組，所以擴(kuò)容是在這個基礎(chǔ)上的，類比hashmap的擴(kuò)容，

1.8版本的concurrentHashMap擴(kuò)容方式比較復(fù)雜，利用了ForwardingNode,先會根據(jù)機(jī)器內(nèi)核數(shù)來分配每個線程能分到的busket數(shù)，（最小是16），這樣子可以做到多線程協(xié)助遷移，提升速度。然后根據(jù)自己分配的busket數(shù)來進(jìn)行節(jié)點(diǎn)轉(zhuǎn)移，如果為空，就放置ForwardingNode，代表已經(jīng)遷移完成，如果是非空節(jié)點(diǎn)（判斷是不是ForwardingNode，是就結(jié)束了），加鎖，鏈路循環(huán),進(jìn)行遷移。

hashMap的put方法的過程

判斷key是否是null，如果是null對應(yīng)的hash值就是0，獲得hash值過后則進(jìn)行擾動，（1.7是9次，5次異或，4次位移，1.8是2次），獲取到的新hash值找出所在的index，（n-1）&hash，根據(jù)下標(biāo)找到對應(yīng)的Node/entity，然后遍歷鏈表/紅黑樹，如果遇到hash值相同且equals相同，則覆蓋值，如果不是則新增。如果節(jié)點(diǎn)數(shù)大于8了，則進(jìn)行樹化（1.8）。完成后，判斷當(dāng)前的長度是否大于閥值，是就擴(kuò)容（1.7是先擴(kuò)容在put）。

為什么修改hashcode方法要修改equals

都是map惹的禍，我們知道在map中判斷是否是同一個對象的時候，會先判斷hash值，在判斷equals的，如果我們只是重寫了hashcode，沒有順便修改equals，比如Intger，hashcode就是value值，如果我們不改寫equals，而是用了Object的equals，那么就是判斷兩者指針是否一致了，那就會出現(xiàn)valueOf和new出來的對象會對于map而言是兩個對象，那就是個問題了

TreeMap了解嘛

TreeMap是Map中的一種很特殊的map，我們知道Map基本是無序的，但是TreeMap是會自動進(jìn)行排序的，也就是一個有序Map(使用了紅黑樹來實(shí)現(xiàn)），如果設(shè)置了Comparator比較器，則會根據(jù)比較器來對比兩者的大小，如果沒有則key需要是Comparable的子類（代碼中沒有事先check，會直接拋出轉(zhuǎn)化異常，有點(diǎn)坑啊）。

LinkedHashMap了解嘛

LinkedHashMap是HashMap的一種特殊分支，是某種有序的hashMap，和TreeMap是不一樣的概念，是用了HashMap+鏈表的方式來構(gòu)造的，有兩者有序模式：訪問有序，插入順序，插入順序是一直存在的，因?yàn)槭钦{(diào)用了hashMap的put方法，并沒有重載，但是重載了newNode方法，在這個方法中，會把節(jié)點(diǎn)插入鏈表中，訪問有序默認(rèn)是關(guān)閉的，如果打開，則在每次get的時候都會把鏈表的節(jié)點(diǎn)移除掉，放到鏈表的最后面。這樣子就是一個LRU的一種實(shí)現(xiàn)方式。

數(shù)據(jù)結(jié)構(gòu)+算法

TODO（未完待續(xù)）

總結(jié)

內(nèi)容過于硬核了，導(dǎo)致很多排版細(xì)節(jié)，我沒辦法做得像其他期一樣精致了，大家見諒。

涉及的內(nèi)容和東西太多了，可能很多都是點(diǎn)到為止，也有很多不全的，也有很多錯誤的點(diǎn)，已經(jīng)快3W字了，我校驗(yàn)實(shí)在困難，我會放在GitHub上面，大家可以跟我一起更新這個文章，造福后人吧。

搞不好下次我需要看的時候，我都得看著這個復(fù)習(xí)了。

我是敖丙，一個在互聯(lián)網(wǎng)茍且偷生的工具人。

你知道的越多，你不知道的越多，人才們的  【三連】 就是丙丙創(chuàng)作的最大動力，我們下期見！