java中static關(guān)鍵字的作用

在Java中static表示“全局”或者“靜態(tài)”的意思生蚁，用來修飾成員變量和成員方法，當(dāng)然也可以修飾代碼塊巡球。
Java把內(nèi)存分為棧內(nèi)存和堆內(nèi)存言沐，其中棧內(nèi)存用來存放一些基本類型的變量、數(shù)組和對象的引用酣栈，堆內(nèi)存主要存放一些對象险胰。在JVM加載一個類的時候，若該類存在static修飾的成員變量和成員方法矿筝，則會為這些成員變量和成員方法在固定的位置開辟一個固定大小的內(nèi)存區(qū)域（只要這個類被加載起便，Java虛擬機(jī)就能根據(jù)類名在運行時數(shù)據(jù)區(qū)的方法區(qū)內(nèi)定找到他們），有了這些“固定”的特性，那么JVM就可以非常方便地訪問他們缨睡。
1鸟悴、static變量
static修飾的變量我們稱之為靜態(tài)變量，沒有用static修飾的變量稱之為實例變量奖年，他們兩者的區(qū)別是：靜態(tài)變量是隨著類加載時被完成初始化的细诸，它在內(nèi)存中僅有一個，且JVM也只會為它分配一次內(nèi)存陋守，同時類所有的實例都共享靜態(tài)變量震贵，可以直接通過類名來訪問它。但是實例變量則不同水评，它是伴隨著實例的猩系，每創(chuàng)建一個實例就會產(chǎn)生一個實例變量，它與該實例同生共死中燥。所以我們一般在這兩種情況下使用靜態(tài)變量：對象之間共享數(shù)據(jù)寇甸、訪問方便。
2疗涉、static方法
static方法一般稱作靜態(tài)方法拿霉，由于靜態(tài)方法不依賴于任何對象就可以進(jìn)行訪問，因此對于靜態(tài)方法來說咱扣，是沒有this的绽淘，因為它不依附于任何對象，既然都沒有對象闹伪，就談不上this了沪铭。并且由于這個特性，在靜態(tài)方法中不能訪問類的非靜態(tài)成員變量和非靜態(tài)成員方法偏瓤，因為非靜態(tài)成員方法/變量都是必須依賴具體的對象才能夠被調(diào)用杀怠。但是要注意的是，雖然在靜態(tài)方法中不能訪問非靜態(tài)成員方法和非靜態(tài)成員變量硼补，但是在非靜態(tài)成員方法中是可以訪問靜態(tài)成員方法/變量的驮肉。因為static方法獨立于任何實例，因此static方法必須被實現(xiàn)已骇，而不能是抽象的abstract。

Java中的內(nèi)存分配：

Java程序在運行時票编，需要在內(nèi)存中的分配空間褪储。為了提高運算效率，就對數(shù)據(jù)進(jìn)行了不同空間的劃分慧域，因為每一片區(qū)域都有特定的處理數(shù)據(jù)方式和內(nèi)存管理方式鲤竹。
具體劃分為如下5個內(nèi)存空間：（非常重要）
棧：存放局部變量
堆：存放所有new出來的東西
方法區(qū)：被虛擬機(jī)加載的類信息、常量、靜態(tài)常量等辛藻。
程序計數(shù)器(和系統(tǒng)相關(guān))
本地方法棧

Java反射機(jī)制的作用：

1）在運行時判斷任意一個對象所屬的類碘橘。
2）在運行時判斷任意一個類所具有的成員變量和方法。
3）在運行時任意調(diào)用一個對象的方法
4）在運行時構(gòu)造任意一個類的對象

什么是反射機(jī)制吱肌？

簡單說痘拆，反射機(jī)制值得是程序在運行時能夠獲取自身的信息。在java中氮墨，只要給定類的名字纺蛆，那么就可以通過反射機(jī)制來獲得類的所有信息。

java反射機(jī)制提供了什么功能规揪？

在運行時能夠判斷任意一個對象所屬的類
在運行時構(gòu)造任意一個類的對象
在運行時判斷任意一個類所具有的成員變量和方法
在運行時調(diào)用任一對象的方法
在運行時創(chuàng)建新類對象

哪里用到反射機(jī)制桥氏？

jdbc中有一行代碼：Class.forName('com.mysql.jdbc.Driver.class').newInstance();

spring的理解

是一個開源框架讓java開發(fā)模塊化，并且全面猛铅。貫穿邏輯層字支，表現(xiàn)層，持久層奸忽。讓每一個功能模塊都可以獨立分開堕伪，降低耦合，提高代碼復(fù)用率月杉！spring通過控制反轉(zhuǎn)降低耦合性刃跛，一個對象的依賴通過被動注入的方式而非主動new還包括面向切面， mvc的整合等等苛萎，以上僅僅是個人對Spring的淺顯認(rèn)識桨昙。

spring IOC 和AOP

IOC:控制反轉(zhuǎn)也叫依賴注入，IOC利用java反射機(jī)制腌歉，AOP利用代理模式蛙酪。所謂控制反轉(zhuǎn)是指，本來被調(diào)用者的實例是有調(diào)用者來創(chuàng)建的翘盖，這樣的缺點是耦合性太強(qiáng)桂塞，IOC則是統(tǒng)一交給spring來管理創(chuàng)建，將對象交給容器管理馍驯，你只需要在spring配置文件總配置相應(yīng)的bean阁危，以及設(shè)置相關(guān)的屬性，讓spring容器來生成類的實例對象以及管理對象汰瘫。在spring容器啟動的時候狂打，spring會把你在配置文件中配置的bean都初始化好，然后在你需要調(diào)用的時候混弥，就把它已經(jīng)初始化好的那些bean分配給你需要調(diào)用這些bean的類趴乡。
AOP：面向切面編程。（Aspect-Oriented Programming）
AOP可以說是對OOP的補充和完善。OOP引入封裝晾捏、繼承和多態(tài)性等概念來建立一種對象層次結(jié)構(gòu)蒿涎，用以模擬公共行為的一個集合。實現(xiàn)AOP的技術(shù)惦辛，主要分為兩大類：一是采用動態(tài)代理技術(shù)劳秋，利用截取消息的方式，對該消息進(jìn)行裝飾裙品，以取代原有對象行為的執(zhí)行俗批；二是采用靜態(tài)織入的方式，引入特定的語法創(chuàng)建“方面”市怎，從而使得編譯器可以在編譯期間織入有關(guān)“方面”的代碼岁忘，屬于靜態(tài)代理

spring中的bean對象生命周期有多長

如果在配置文件中聲明一個bean對象，這個web程序一直運行区匠，那這個bean對象會不會一直存在
默認(rèn)的bean是單例的干像，也就是說只有spring 容器關(guān)閉的時候才會銷毀這些bean對象，如果聲明的bean對象是prototype類型的話驰弄，就非單例了麻汰， 那么這些對象將不由spring容器維護(hù)，該對象沒有引用的時候jvm會適時垃圾回收

spring aop的底層原理

spring兩種代理方式
若目標(biāo)對象實現(xiàn)了若干接口戚篙，spring使用JDK的java.lang.reflect.Proxy類代理五鲫。
優(yōu)點：因為有接口，所以使系統(tǒng)更加松耦合
缺點：為每一個目標(biāo)類創(chuàng)建接口
若目標(biāo)對象沒有實現(xiàn)任何接口岔擂，spring使用CGLIB庫生成目標(biāo)對象的子類位喂。
優(yōu)點：因為代理類與目標(biāo)類是繼承關(guān)系，所以不需要有接口的存在乱灵。
缺點：因為沒有使用接口塑崖，所以系統(tǒng)的耦合性沒有使用JDK的動態(tài)代理好。

JDK動態(tài)代理
1.創(chuàng)建一個實現(xiàn)接口InvocationHandler的類痛倚，它必須實現(xiàn)invoke方法
2.創(chuàng)建被代理的類以及接口
3.通過Proxy的靜態(tài)方法
newProxyInstance(ClassLoaderloader, Class[] interfaces, InvocationHandler h)創(chuàng)建一個代理
4.通過代理調(diào)用方法
JDK的動態(tài)代理是靠多態(tài)和反射來實現(xiàn)的规婆，它生成的代理類需要實現(xiàn)你傳入的接口，并通過反射來得到接口的方法對象

CGLib采用了非常底層的字節(jié)碼技術(shù)蝉稳，其原理是通過字節(jié)碼技術(shù)為一個類創(chuàng)建子類抒蚜，并在子類中采用方法攔截的技術(shù)攔截所有父類方法的調(diào)用，順勢織入橫切邏輯耘戚。
1削锰、生成代理類Class的二進(jìn)制字節(jié)碼；
2毕莱、通過Class.forName加載二進(jìn)制字節(jié)碼，生成Class對象；
3朋截、通過反射機(jī)制獲取實例構(gòu)造蛹稍，并初始化代理類對象。

spring ioc相關(guān)

原理是反射+工廠模式

springmvc重要的類

https://blog.csdn.net/scholar_man/article/details/48052407

spring的bean的作用域

Spring 3中為Bean定義了5中作用域部服，分別為singleton（單例）唆姐、prototype（原型）、request廓八、session和global session奉芦，5種作用域說明如下：

1.singleton：單例模式，Spring IoC容器中只會存在一個共享的Bean實例剧蹂，無論有多少個Bean引用它声功，始終指向同一對象。Singleton作用域是Spring中的缺省作用域宠叼，也可以顯示的將Bean定義為singleton模式先巴，配置為：
<bean id="userDao" class="com.ioc.UserDaoImpl" scope="singleton"/>
2.prototype:原型模式，每次通過Spring容器獲取prototype定義的bean時冒冬，容器都將創(chuàng)建一個新的Bean實例伸蚯，每個Bean實例都有自己的屬性和狀態(tài)，而singleton全局只有一個對象简烤。根據(jù)經(jīng)驗剂邮，對有狀態(tài)的bean使用prototype作用域，而對無狀態(tài)的bean使用singleton作用域横侦。
3.request：在一次Http請求中挥萌，容器會返回該Bean的同一實例。而對不同的Http請求則會產(chǎn)生新的Bean丈咐，而且該bean僅在當(dāng)前Http Request內(nèi)有效瑞眼。
<bean id="loginAction" class="com.cnblogs.Login" scope="request"/>,針對每一次Http請求，Spring容器根據(jù)該bean的定義創(chuàng)建一個全新的實例棵逊，且該實例僅在當(dāng)前Http請求內(nèi)有效伤疙，而其它請求無法看到當(dāng)前請求中狀態(tài)的變化，當(dāng)當(dāng)前Http請求結(jié)束辆影，該bean實例也將會被銷毀徒像。
4.session：在一次Http Session中，容器會返回該Bean的同一實例蛙讥。而對不同的Session請求則會創(chuàng)建新的實例锯蛀，該bean實例僅在當(dāng)前Session內(nèi)有效。
<bean id="userPreference" class="com.ioc.UserPreference" scope="session"/>,同Http請求相同次慢，每一次session請求創(chuàng)建新的實例旁涤，而不同的實例之間不共享屬性翔曲，且實例僅在自己的session請求內(nèi)有效，請求結(jié)束劈愚，則實例將被銷毀瞳遍。
5.global Session：在一個全局的Http Session中，容器會返回該Bean的同一個實例菌羽，僅在使用portlet context時有效掠械。

autowired 和 resource注解的區(qū)別

https://www.cnblogs.com/think-in-java/p/5474740.html

spring mvc

spring 相關(guān)問題

https://www.cnblogs.com/liangyihui/p/5917773.html

redis 的數(shù)據(jù)類型

五種數(shù)據(jù)類型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)

mvn的指令的區(qū)別

mvn -version 查看maven的版本及配置信息
mvn archetype:create -DgroupId= DartifactId= 構(gòu)建java項目
mvn archetype:create -DgroupId= DartifactId= -DarchetypeArtifactId=maven-archetype-webapp 創(chuàng)建web項目
mvn compile 編譯項目代碼
mvn package 打包項目
mvn package -Dmaven.test.skip=true 打包項目時跳過單元測試
mvn test 運行單元測試
mvn clean 清除編譯產(chǎn)生的target文件夾內(nèi)容，可以配合相應(yīng)命令一起使用注祖，如mvn clean package猾蒂， mvn clean test
mvn install 打包后將其安裝在本地倉庫
mvn deploy 打包后將其安裝到pom文件中配置的遠(yuǎn)程倉庫
mvn eclipse:eclipse 將maven生成eclipse項目結(jié)構(gòu)
mvn eclipse:clean 清除maven項目中eclipse的項目結(jié)構(gòu)
mvn site 生成站點目錄
mvn dependency:list 顯示所有已經(jīng)解析的所有依賴
mvn dependency:tree 以樹的結(jié)構(gòu)展示項目中的依賴
mvn dependency:analyze 對項目中的依賴進(jìn)行分析，依賴未使用是晨，使用單未引入
mvn tomcat:run 啟動tomcat

java的內(nèi)部匿名類

肚菠？？署鸡？案糙？

stringbuffer和stringbuilder的實現(xiàn)原理

StringBuilder繼承自AbstractStringBuilder,與String類似，StringBuilder類也封裝了一個字符數(shù)組靴庆，定義如下：

char[] value;

與String不同时捌，它不是final的，可以修改炉抒。
它的默認(rèn)構(gòu)造方法是：

public StringBuilder() {
    super(16);
}

new StringBuilder()這句代碼奢讨，內(nèi)部會創(chuàng)建一個長度為16的字符數(shù)組，count的默認(rèn)值為0
append會直接拷貝字符到內(nèi)部的字符數(shù)組中焰薄，如果字符數(shù)組長度不夠拿诸，會進(jìn)行擴(kuò)展，實際使用的長度用count體現(xiàn)塞茅。
擴(kuò)展的邏輯是亩码，分配一個足夠長度的新數(shù)組，然后將原內(nèi)容拷貝到這個新數(shù)組中野瘦，最后讓內(nèi)部的字符數(shù)組指向這個新數(shù)組

StringBuilder的大部分方法中都會調(diào)用父類方法或?qū)傩裕?足以見得該父類對其的影響還是很大的描沟，所以我們將從頭至尾簡單介紹下它的父類AbstractStringBuilder。該類中只有兩個屬性
value屬性表示的是一個字符數(shù)組鞭光，該數(shù)組的作用和String中的字符數(shù)組的作用是一樣的吏廉，只是此value數(shù)組并沒有被final修飾，也就是說該數(shù)組內(nèi)部的值是可以動態(tài)修改的惰许，這也是StringBuilder存在的意義席覆。count屬性表示的不是value數(shù)組的長度，它代表的是value數(shù)組中實際上存放的字符數(shù)目汹买，例如：value長度為10佩伤，我存放8個字符聊倔，剩下位置為空，此時count的值就為8畦戒，而value.length()為10方库。
對于一個StringBuilder對象，我們可以不斷的追加字符串到其中障斋，這樣就會遇到value數(shù)組長度不夠的時候，該方法就是用于處理這種情況徐鹤，在我們實際操作value數(shù)組之前垃环，大多會調(diào)用該方法判斷此次操作之后是否會導(dǎo)致數(shù)組溢出，如果是則會將原數(shù)組長度擴(kuò)大兩倍加上2并拷貝原數(shù)組中的內(nèi)容到新數(shù)組中返敬，然后才實際操作value數(shù)組遂庄。（此時的value數(shù)組已經(jīng)被擴(kuò)容了）。

分布式和集群

分布式：一個業(yè)務(wù)分拆多個子業(yè)務(wù)劲赠，部署在不同的服務(wù)器上涛目，(我的補充：)具有處理高并發(fā)的能力，但一個子業(yè)務(wù)系統(tǒng)宕機(jī)凛澎，該子業(yè)務(wù)功能將無法實現(xiàn)霹肝。
集群：同一個業(yè)務(wù)，部署在多個服務(wù)器上塑煎，(我的補充：)具有高可用的能力沫换，一個系統(tǒng)宕機(jī)，不影響業(yè)務(wù)實現(xiàn)最铁。

分布式事物

RocketMQ第一階段發(fā)送Prepared消息時讯赏，會拿到消息的地址，第二階段執(zhí)行本地事物冷尉，第三階段通過第一階段拿到的地址去訪問消息漱挎，并修改狀態(tài)。細(xì)心的讀者可能又發(fā)現(xiàn)問題了雀哨，如果確認(rèn)消息發(fā)送失敗了怎么辦磕谅？
RocketMQ會定期掃描消息集群中的事物消息，這時候發(fā)現(xiàn)了Prepared消息震束，它會向消息發(fā)送者確認(rèn)怜庸，Bob的錢到底是減了還是沒減呢？如果減了是回滾還是繼續(xù)發(fā)送確認(rèn)消息呢垢村？RocketMQ會根據(jù)發(fā)送端設(shè)置的策略來決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息割疾。這樣就保證了消息發(fā)送與本地事務(wù)同時成功或同時失敗。如下圖：

為了能解決該問題嘉栓，同時又不和業(yè)務(wù)耦合宏榕，RocketMQ提出了“事務(wù)消息”的概念拓诸。
具體來說，就是把消息的發(fā)送分成了2個階段：Prepare階段和確認(rèn)階段麻昼。
具體來說奠支，上面的2個步驟，被分解成3個步驟：
(1) 發(fā)送Prepared消息
(2) update DB
(3) 根據(jù)update DB結(jié)果成功或失敗抚芦，Confirm或者取消Prepared消息倍谜。
可能有人會問了，前2步執(zhí)行成功了叉抡，最后1步失敗了怎么辦尔崔？這里就涉及到了RocketMQ的關(guān)鍵點：RocketMQ會定期（默認(rèn)是1分鐘）掃描所有的Prepared消息，詢問發(fā)送方褥民，到底是要確認(rèn)這條消息發(fā)出去季春？還是取消此條消息

分布式事務(wù)（Distributed Transaction DT ）
分布式事務(wù)顧名思義就是在分布式環(huán)境下運行的事務(wù)，對于分布式事務(wù)來說消返，事務(wù)的每個操作步驟是運行在不同機(jī)器上的服務(wù)的载弄。分布式事務(wù)處理的關(guān)鍵是必須有一種方法可以知道事務(wù)在任何地方所做的所有動作，提交或回滾事務(wù)的決定必須產(chǎn)生統(tǒng)一的結(jié)果（全部提交或全部回滾）

在現(xiàn)如今的大型互聯(lián)網(wǎng)平臺中撵颊，基本上都是采用分布式的SOA架構(gòu)宇攻，所以分布式事務(wù)是非常常見的。比如一個電商平臺的下單場景秦驯，一般對于用戶下單會有兩個步驟尺碰，一是訂單業(yè)務(wù)采取下訂單操作，二是庫存業(yè)務(wù)采取減庫存操作译隘，但在大型電子商務(wù)平臺上這兩個業(yè)務(wù)一般會運行在不同的機(jī)器上亲桥，這就是一個典型的分布式事務(wù)場景。還有一個常見的場景就是支付寶向余額寶轉(zhuǎn)賬固耘，而支付寶和余額寶不是一個系統(tǒng)题篷，怎么保證這兩個系統(tǒng)之間的一致性就是分布式事務(wù)所關(guān)注的問題。

在分布式系統(tǒng)里面有一個CAP定律厅目，這個定理的內(nèi)容是指的是在一個分布式系統(tǒng)中番枚， Consistency（一致性）、 Availability（可用性）损敷、Partition tolerance（分區(qū)容錯性）葫笼，三者不可得兼
一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值拗馒。（等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）
可用性（A）：在集群中一部分節(jié)點故障后路星，集群整體是否還能響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）
分區(qū)容錯性（P）：以實際效果而言诱桂，分區(qū)相當(dāng)于對通信的時限要求洋丐。系統(tǒng)如果不能在時限內(nèi)達(dá)成數(shù)據(jù)一致性呈昔，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇友绝。
解決分布式事務(wù)問題還有一種方案堤尾，也是現(xiàn)在大型互聯(lián)網(wǎng)平臺普遍采用的方案，就是利用消息中間件

分布式session -- 基于redis的session共享

將Session數(shù)據(jù)集中存儲迁客，然后不同Web服務(wù)器從同樣的地方獲取Session郭宝，如下圖：

Synchronized（對象鎖）和Static Synchronized（類鎖）的區(qū)別

https://blog.csdn.net/cs408/article/details/48930803

synchronized修飾

1.Synchronized修飾非靜態(tài)方法，實際上是對調(diào)用該方法的對象加鎖哲泊，俗稱“對象鎖”

情況1：同一個對象在兩個線程中分別訪問該對象的兩個同步方法
結(jié)果：會產(chǎn)生互斥剩蟀。
解釋：因為鎖針對的是對象，當(dāng)對象調(diào)用一個synchronized方法時切威，其他同步方法需要等待其執(zhí)行結(jié)束并釋放鎖后才能執(zhí)行。

情況2：不同對象在兩個線程中調(diào)用同一個同步方法
結(jié)果：不會產(chǎn)生互斥丙号。
解釋：因為是兩個對象先朦，鎖針對的是對象，并不是方法犬缨，所以可以并發(fā)執(zhí)行喳魏，不會互斥。形象的來說就是因為我們每個線程在調(diào)用方法的時候都是new 一個對象怀薛，那么就會出現(xiàn)兩個空間刺彩，兩把鑰匙

2.Synchronized修飾靜態(tài)方法，實際上是對該類對象加鎖枝恋，俗稱“類鎖”创倔。

情況1：用類直接在兩個線程中調(diào)用兩個不同的同步方法
結(jié)果：會產(chǎn)生互斥。
解釋：因為對靜態(tài)對象加鎖實際上對類（.class）加鎖焚碌，類對象只有一個畦攘，可以理解為任何時候都只有一個空間，里面有N個房間十电，一把鎖知押，因此房間（同步方法）之間一定是互斥的。
注：上述情況和用單例模式聲明一個對象來調(diào)用非靜態(tài)方法的情況是一樣的鹃骂，因為永遠(yuǎn)就只有這一個對象台盯。所以訪問同步方法之間一定是互斥的。

情況2：用一個類的靜態(tài)對象在兩個線程中調(diào)用靜態(tài)方法或非靜態(tài)方法
結(jié)果：會產(chǎn)生互斥畏线。
解釋：因為是一個對象調(diào)用静盅，同上。

情況3：一個對象在兩個線程中分別調(diào)用一個靜態(tài)同步方法和一個非靜態(tài)同步方法
結(jié)果：不會產(chǎn)生互斥象踊。
解釋：因為雖然是一個對象調(diào)用温亲，但是兩個方法的鎖類型不同棚壁，調(diào)用的靜態(tài)方法實際上是類對象在調(diào)用，即這兩個方法產(chǎn)生的并不是同一個對象鎖栈虚，因此不會互斥袖外，會并發(fā)執(zhí)行。

volatile關(guān)鍵字魂务、可見性具體的理解

volatile不具備原子性曼验，使用條件：
對變量的寫操作不依賴于當(dāng)前值
該變量沒有包含在具有其他變量的不變式子中
適合作為狀態(tài)標(biāo)記量

當(dāng)多個線程進(jìn)行操作共享數(shù)據(jù)時，可以保證內(nèi)存中的數(shù)據(jù)可見粘姜。底層原理：內(nèi)存柵欄鬓照。使用volatile關(guān)鍵字修飾時，可理解為對數(shù)據(jù)的操作都在主存中進(jìn)行孤紧。
設(shè)計模式的理解和應(yīng)用

volatile關(guān)鍵字為什么不是線程安全的

這一些操作并不是原子性豺裆，也就是 在read load之后，如果主內(nèi)存count變量發(fā)生修改之后号显，線程工作內(nèi)存中的值由于已經(jīng)加載臭猜，不會產(chǎn)生對應(yīng)的變化，所以計算出來的結(jié)果會和預(yù)期不一樣
對于volatile修飾的變量押蚤，jvm虛擬機(jī)只是保證從主內(nèi)存加載到線程工作內(nèi)存的值是最新的
例如假如線程1蔑歌，線程2 在進(jìn)行read,load 操作中，發(fā)現(xiàn)主內(nèi)存中count的值都是5揽碘，那么都會加載這個最新的值
在線程1堆count進(jìn)行修改之后次屠，會write到主內(nèi)存中，主內(nèi)存中的count變量就會變?yōu)?
線程2由于已經(jīng)進(jìn)行read,load操作雳刺，在進(jìn)行運算之后劫灶，也會更新主內(nèi)存count的變量值為6

AQS相關(guān)

它維護(hù)了一個volatile int state（代表共享資源）和一個FIFO線程等待隊列（多線程爭用資源被阻塞時會進(jìn)入此隊列）。這里volatile是核心關(guān)鍵詞
AQS定義兩種資源共享方式：Exclusive（獨占煞烫，只有一個線程能執(zhí)行浑此，如ReentrantLock）和Share（共享，多個線程可同時執(zhí)行滞详，如Semaphore/CountDownLatch）

https://www.cnblogs.com/daydaynobug/p/6752837.html

jdk1.8的新特性

https://www.cnblogs.com/snowInPluto/p/5981400.html

lambda表達(dá)式的實現(xiàn)原理

jvm 內(nèi)存模型 JMM

描述多線程環(huán)境中線程與內(nèi)存的關(guān)系
https://blog.csdn.net/suifeng3051/article/details/52611310
https://blog.csdn.net/zjf280441589/article/details/53437703

GC用的引用可達(dá)性分析算法中凛俱，哪些對象可作為GC Roots對象(https://blog.csdn.net/ma345787383/article/details/77099522)

先說一下可達(dá)性分析算法的思想：從一個被稱為GC Roots的對象開始向下搜索，如果一個對象到GC Roots沒有任何引用鏈相連時料饥，則說明此對象不可用蒲犬。
在java中可以作為GC Roots的對象有以下幾種：
虛擬機(jī)棧中引用的對象、方法區(qū)類靜態(tài)屬性引用的對象岸啡、方法區(qū)常量池引用的對象原叮、本地方法棧JNI引用的對象
雖然這些算法可以判定一個對象是否能被回收，但是當(dāng)滿足上述條件時，一個對象 不一定會被回收奋隶。當(dāng)一個對象不可達(dá)GC Roots時擂送，這個對象并不會馬上被回收，而是處于一個死緩的階段唯欣，若要被真正的回收需要經(jīng)歷兩次標(biāo)記嘹吨。如果對象在可達(dá)性分析中沒有與GC Roots的引用鏈，那么此時就會被第一次標(biāo)記并且進(jìn)行一次篩選境氢，篩選的條件是是否有必要執(zhí)行finalize()方法蟀拷。當(dāng)對象沒有覆蓋finalize()方法或者已經(jīng)被虛擬機(jī)調(diào)用過，那么就認(rèn)為是沒必要的萍聊。
如果該對象有必要執(zhí)行finalize()方法问芬，那么這個對象將會放在一個稱為F-Queue的隊列中，虛擬機(jī)會觸發(fā)一個finalize()線程去執(zhí)行寿桨，此線程是低優(yōu)先級的此衅，并且虛擬機(jī)不會承諾一直等待它運行完，這還是因為如果finalize()執(zhí)行緩慢或者發(fā)生了死鎖亭螟，那么就會造成F-Queue隊列一直等待炕柔，造成了內(nèi)存回收系統(tǒng)的崩潰。GC對處于F-Queue中的對象進(jìn)行第二次被標(biāo)記媒佣，這時，該對象將被移除“即將回收”集合陵刹，等待回收默伍。

TCP與UDP區(qū)別總結(jié)：

https://blog.csdn.net/u013777351/article/details/49226101
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的衰琐，即發(fā)送數(shù)據(jù)之前不需要建立連接
2、TCP提供可靠的服務(wù)。也就是說颓遏，通過TCP連接傳送的數(shù)據(jù)付枫，無差錯，不丟失狗热，不重復(fù)钞馁，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付
Tcp通過校驗和匿刮，重傳控制僧凰，序號標(biāo)識，滑動窗口熟丸、確認(rèn)應(yīng)答實現(xiàn)可靠傳輸训措。如丟包時的重發(fā)控制，還可以對次序亂掉的分包進(jìn)行順序控制。
3绩鸣、UDP具有較好的實時性怀大，工作效率比TCP高，適用于對高速傳輸和實時性有較高的通信或廣播通信呀闻。
4.每一條TCP連接只能是點到點的;UDP支持一對一化借，一對多，多對一和多對多的交互通信
5总珠、TCP對系統(tǒng)資源要求較多屏鳍，UDP對系統(tǒng)資源要求較少。

網(wǎng)絡(luò)方面局服、簡要表述http協(xié)議钓瞭、抓包什么的

https://blog.csdn.net/done58/article/details/50996680
https://www.cnblogs.com/ranyonsue/p/5984001.html
https://www.cnblogs.com/qdhxhz/p/8468913.html

死鎖發(fā)生的原因：

1、系統(tǒng)資源有限
2淫奔、進(jìn)程或線程推進(jìn)順序不恰當(dāng)
3山涡、資源分配不當(dāng)

死鎖發(fā)生的四個條件：

1、互斥條件：一份資源每次只能被一個進(jìn)程或線程使用（在Java中一般體現(xiàn)為唆迁，一個對象鎖只能被一個線程持有）
2鸭丛、請求與保持條件：一個進(jìn)程或線程在等待請求資源被釋放時，不釋放已占有資源
3唐责、不可剝奪條件：一個進(jìn)程或線程已經(jīng)獲得的資源不能被其他進(jìn)程或線程強(qiáng)行剝奪
4鳞溉、循環(huán)等待條件：形成一種循環(huán)等待的場景

死鎖代碼示例：

void transfer(Account from,Account to,int amount){
        synchronized(from){
              synchronized(to){
                  from.setAmount(from.getAmount()-amount);
                  to.setAmount(to.getAmount()+amount)
              }
        }
}
//transfer(a,b,100)和transfer(b,a,100)同時進(jìn)行

解決思路：
1.一次性獲取全部鎖
2.按一定順序獲得鎖
3.加入超時判定
ReentrantLock提供了tryLock()、tryLock(long timeout, TimeUnit unit)鼠哥、lock.lockInterruptibly()
tryLock() 方法試圖申請一個鎖熟菲，在成功獲得鎖后返回true，否則朴恳，立即返回false,而且線程可以立即離開去做其他的事情抄罕。
tryLock(long timeout, TimeUnit unit) 是一個具有超時參數(shù)的嘗試申請鎖的方法，阻塞時間不會超過給定的值于颖；如果成功則返回true
lockInterruptibly() 獲得鎖呆贿，但是會不確定地發(fā)生阻塞。如果線程被中斷森渐，拋出一個InterruptedException異常做入。

死鎖的解決方案：
盡可能不死鎖
碰撞檢測
等鎖超時

數(shù)據(jù)庫索引方面的問題

索引分單列索引和組合索引。單列索引章母，即一個索引只包含單個列母蛛，一個表可以有多個單列索引，但這不是組合索引乳怎。組合索引彩郊，即一個索引包含多個列前弯。索引可以大大提高M(jìn)ySQL的檢索速度。索引也會有它的缺點：雖然索引大大提高了查詢速度秫逝，同時卻會降低更新表的速度恕出，如對表進(jìn)行INSERT、UPDATE和DELETE违帆。因為更新表時浙巫，MySQL不僅要保存數(shù)據(jù)，還要保存一下索引文件刷后。

索引種類
普通索引：僅加速查詢
唯一索引：加速查詢 + 列值唯一（可以有null）
主鍵索引：加速查詢 + 列值唯一（不可以有null）+ 表中只有一個
組合索引：多列值組成一個索引的畴，專門用于組合搜索，其效率大于索引合并
全文索引：對文本的內(nèi)容進(jìn)行分詞尝胆，進(jìn)行搜索

innodb存儲引擎索引概述：
innodb存儲引擎支持兩種常見的索引：B+樹索引和哈希索引丧裁。

數(shù)據(jù)庫中B+樹索引分為聚集索引（clustered index）和非聚集索引（secondary index）.這兩種索引的共同點是內(nèi)部都是B+樹，高度都是平衡的含衔，葉節(jié)點存放著所有數(shù)據(jù)煎娇。不同點是葉節(jié)點是否存放著一整行數(shù)據(jù)。
(1) 聚集索引
Innodb存儲引擎表是索引組織表贪染，即表中數(shù)據(jù)按主鍵順序存放缓呛。而聚集索引就是按每張表的主鍵構(gòu)造一顆B+樹。并且葉節(jié)點存放整張表的行記錄數(shù)據(jù)杭隙。每張表只能有一個聚集索引（一個主鍵）哟绊。
聚集索引的另一個好處是它對于主鍵的排序查找和范圍的速度非常快痰憎。葉節(jié)點的數(shù)據(jù)就是我們要找的數(shù)據(jù)匿情。
(2) 非聚集索引
非聚集索引。葉級別不包含行的全部數(shù)據(jù)信殊，葉級別除了包含行的鍵值以外，每個索引行還包含了一個書簽（bookmark）汁果，該書簽告訴innodb存儲引擎涡拘，哪里可以找到與索引對應(yīng)的數(shù)據(jù)。
非聚集索引的存在并不影響數(shù)據(jù)再聚集索引中的組織据德，因此一個表可以有多個輔助索引鳄乏。當(dāng)通過輔助索引查找數(shù)據(jù)時，innodb會遍歷非聚集索引并通過葉級別的指針獲得指向主鍵索引的主鍵棘利。然后再通過主鍵索引找到一行完整的數(shù)據(jù)橱野。

數(shù)據(jù)庫數(shù)據(jù)庫中的五大約束包括：

1.主鍵約束（Primay Key Coustraint） 唯一性，非空性善玫；
2.唯一約束 （Unique Counstraint）唯一性水援，可以空，但只能有一個；
3.默認(rèn)約束 (Default Counstraint) 該數(shù)據(jù)的默認(rèn)值蜗元；
4.外鍵約束 (Foreign Key Counstraint) 需要建立兩表間的關(guān)系或渤；
5.非空約束（Not Null Counstraint）:設(shè)置非空約束，該字段不能為空奕扣。

數(shù)據(jù)庫中的范式：

第一范式（1NF）：
數(shù)據(jù)表中的每一列(字段)薪鹦，必須是不可拆分的最小單元，也就是確保每一列的原子性惯豆。
例如： userInfo: '山東省煙臺市 1318162008' 依照第一范式必須拆分成
userInfo: '山東省煙臺市'　　 userTel: '1318162008'兩個字段

第二范式（2NF）：
滿足1NF后要求表中的所有列池磁，都必需依賴于主鍵，而不能有 任何一列與主鍵沒有關(guān)系（一個表只描述一件事情）楷兽。
例如：訂單表只能描述訂單相關(guān)的信息地熄，所以所有的字段都必須與訂單ID相關(guān)。產(chǎn)品表只能描述產(chǎn)品相關(guān)的信息拄养，所以所有的字段都必須與產(chǎn)品ID相關(guān)离斩。因此在同一張表中不能同時出現(xiàn)訂單信息與產(chǎn)品信息。

第三范式（3NF）：
第三范式(3NF)：滿足2NF后瘪匿，要求：表中的每一列都要與主鍵直接相關(guān)跛梗，而不是間接相關(guān)（表中的每一列只能依賴于主鍵）
例如：訂單表中需要有客戶相關(guān)信息，在分離出客戶表之后棋弥，訂單表中只需要有一個用戶ID即可核偿，而不能有其他的客戶信息，因為其他的用戶信息是直接關(guān)聯(lián)于用戶ID顽染，而不是關(guān)聯(lián)于訂單ID漾岳。

SQL相關(guān)

https://blog.csdn.net/u011464124/article/details/54618616
https://blog.csdn.net/m13666368773/article/details/7612113

mysql 2種引擎的區(qū)別

區(qū)別：1. InnoDB支持事務(wù)，MyISAM不支持粉寞，對于InnoDB每一條SQL語言都默認(rèn)封裝成事務(wù)尼荆，自動提交，這樣會影響速度唧垦，所以最好把多條SQL語言放在begin和commit之間捅儒，組成一個事務(wù)； 2. InnoDB支持外鍵振亮，而MyISAM不支持巧还。對一個包含外鍵的InnoDB表轉(zhuǎn)為MYISAM會失敗坊秸； 3. InnoDB是聚集索引麸祷，數(shù)據(jù)文件是和索引綁在一起的，必須要有主鍵褒搔，通過主鍵索引效率很高阶牍。但是輔助索引需要兩次查詢喷面，先查詢到主鍵，然后再通過主鍵查詢到數(shù)據(jù)荸恕。因此乖酬，主鍵不應(yīng)該過大，因為主鍵太大融求，其他索引也都會很大咬像。而MyISAM是非聚集索引，數(shù)據(jù)文件是分離的生宛，索引保存的是數(shù)據(jù)文件的指針县昂。主鍵索引和輔助索引是獨立的。 4. InnoDB不保存表的具體行數(shù)陷舅，執(zhí)行select count(*) from table時需要全表掃描倒彰。而MyISAM用一個變量保存了整個表的行數(shù)，執(zhí)行上述語句時只需要讀出該變量即可莱睁，速度很快待讳； 5. Innodb不支持全文索引，而MyISAM支持全文索引仰剿，查詢效率上MyISAM要高创淡； 如何選擇：1. 是否要支持事務(wù)，如果要請選擇innodb南吮，如果不需要可以考慮MyISAM琳彩；2. 如果表中絕大多數(shù)都只是讀查詢，可以考慮MyISAM部凑，如果既有讀寫也挺頻繁露乏，請使用InnoDB。3. 系統(tǒng)奔潰后涂邀，MyISAM恢復(fù)起來更困難瘟仿，能否接受； 4. MySQL5.5版本開始Innodb已經(jīng)成為Mysql的默認(rèn)引擎(之前是MyISAM)比勉，說明其優(yōu)勢是有目共睹的猾骡，如果你不知道用什么，那就用InnoDB敷搪，至少不會差。

如何定位慢sql

服務(wù)端加慢sql日志
數(shù)據(jù)庫調(diào)優(yōu)我個人覺得必須要明白兩件事
1.定位問題（你得知道問題出在哪里幢哨，要不然從哪里調(diào)優(yōu)呢）
2.解決問題（這個沒有基本的方法來處理赡勘，因為不同的問題處理的方式方法不一樣
得從實踐中不斷的探索，如sql調(diào)優(yōu)捞镰，配置優(yōu)化闸与，硬件升級等等）

如何分析慢sql

explain

如何解決慢sql

加索引毙替，in優(yōu)化、分頁優(yōu)化践樱、分庫分表等等厂画。。拷邢。

面向事件編程

跨平臺語言的實現(xiàn)原理

mybatis的源碼分析

hashmap的原理袱院、concurrentHashmap、hashtable

同步鎖瞭稼、數(shù)據(jù)庫鎖 樂觀鎖 悲觀鎖

nginx 配置 轉(zhuǎn)發(fā)的類型

tomcat下的文件夾

堆忽洛、棧溢出的問題

spring的bean的生命周期