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

在Java中static表示“全局”或者“靜態(tài)”的意思，用來修飾成員變量和成員方法，當(dāng)然也可以修飾代碼塊。
Java把內(nèi)存分為棧內(nèi)存和堆內(nèi)存，其中棧內(nèi)存用來存放一些基本類型的變量、數(shù)組和對象的引用，堆內(nèi)存主要存放一些對象。在JVM加載一個(gè)類的時(shí)候，若該類存在static修飾的成員變量和成員方法，則會(huì)為這些成員變量和成員方法在固定的位置開辟一個(gè)固定大小的內(nèi)存區(qū)域（只要這個(gè)類被加載，Java虛擬機(jī)就能根據(jù)類名在運(yùn)行時(shí)數(shù)據(jù)區(qū)的方法區(qū)內(nèi)定找到他們），有了這些“固定”的特性，那么JVM就可以非常方便地訪問他們。
1、static變量
static修飾的變量我們稱之為靜態(tài)變量，沒有用static修飾的變量稱之為實(shí)例變量，他們兩者的區(qū)別是：靜態(tài)變量是隨著類加載時(shí)被完成初始化的，它在內(nèi)存中僅有一個(gè)，且JVM也只會(huì)為它分配一次內(nèi)存，同時(shí)類所有的實(shí)例都共享靜態(tài)變量，可以直接通過類名來訪問它。但是實(shí)例變量則不同，它是伴隨著實(shí)例的，每創(chuàng)建一個(gè)實(shí)例就會(huì)產(chǎn)生一個(gè)實(shí)例變量，它與該實(shí)例同生共死。所以我們一般在這兩種情況下使用靜態(tài)變量：對象之間共享數(shù)據(jù)、訪問方便。
2、static方法
static方法一般稱作靜態(tài)方法，由于靜態(tài)方法不依賴于任何對象就可以進(jìn)行訪問，因此對于靜態(tài)方法來說，是沒有this的，因?yàn)樗灰栏接谌魏螌ο螅热欢紱]有對象，就談不上this了。并且由于這個(gè)特性，在靜態(tài)方法中不能訪問類的非靜態(tài)成員變量和非靜態(tài)成員方法，因?yàn)榉庆o態(tài)成員方法/變量都是必須依賴具體的對象才能夠被調(diào)用。但是要注意的是，雖然在靜態(tài)方法中不能訪問非靜態(tài)成員方法和非靜態(tài)成員變量，但是在非靜態(tài)成員方法中是可以訪問靜態(tài)成員方法/變量的。因?yàn)閟tatic方法獨(dú)立于任何實(shí)例，因此static方法必須被實(shí)現(xiàn)，而不能是抽象的abstract。

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

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

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

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

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

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

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

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

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

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

spring的理解

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

spring IOC 和AOP

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

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

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

spring aop的底層原理

spring兩種代理方式
若目標(biāo)對象實(shí)現(xiàn)了若干接口，spring使用JDK的java.lang.reflect.Proxy類代理。
優(yōu)點(diǎn)：因?yàn)橛薪涌?，所以使系統(tǒng)更加松耦合
缺點(diǎn)：為每一個(gè)目標(biāo)類創(chuàng)建接口
若目標(biāo)對象沒有實(shí)現(xiàn)任何接口，spring使用CGLIB庫生成目標(biāo)對象的子類。
優(yōu)點(diǎn)：因?yàn)榇眍惻c目標(biāo)類是繼承關(guān)系，所以不需要有接口的存在。
缺點(diǎn)：因?yàn)闆]有使用接口，所以系統(tǒng)的耦合性沒有使用JDK的動(dòng)態(tài)代理好。

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

CGLib采用了非常底層的字節(jié)碼技術(shù)，其原理是通過字節(jié)碼技術(shù)為一個(gè)類創(chuàng)建子類，并在子類中采用方法攔截的技術(shù)攔截所有父類方法的調(diào)用，順勢織入橫切邏輯。
1、生成代理類Class的二進(jìn)制字節(jié)碼；
2、通過Class.forName加載二進(jìn)制字節(jié)碼，生成Class對象；
3、通過反射機(jī)制獲取實(shí)例構(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容器中只會(huì)存在一個(gè)共享的Bean實(shí)例，無論有多少個(gè)Bean引用它，始終指向同一對象。Singleton作用域是Spring中的缺省作用域，也可以顯示的將Bean定義為singleton模式，配置為：
<bean id="userDao" class="com.ioc.UserDaoImpl" scope="singleton"/>
2.prototype:原型模式，每次通過Spring容器獲取prototype定義的bean時(shí)，容器都將創(chuàng)建一個(gè)新的Bean實(shí)例，每個(gè)Bean實(shí)例都有自己的屬性和狀態(tài)，而singleton全局只有一個(gè)對象。根據(jù)經(jīng)驗(yàn)，對有狀態(tài)的bean使用prototype作用域，而對無狀態(tài)的bean使用singleton作用域。
3.request：在一次Http請求中，容器會(huì)返回該Bean的同一實(shí)例。而對不同的Http請求則會(huì)產(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)建一個(gè)全新的實(shí)例，且該實(shí)例僅在當(dāng)前Http請求內(nèi)有效，而其它請求無法看到當(dāng)前請求中狀態(tài)的變化，當(dāng)當(dāng)前Http請求結(jié)束，該bean實(shí)例也將會(huì)被銷毀。
4.session：在一次Http Session中，容器會(huì)返回該Bean的同一實(shí)例。而對不同的Session請求則會(huì)創(chuàng)建新的實(shí)例，該bean實(shí)例僅在當(dāng)前Session內(nèi)有效。
<bean id="userPreference" class="com.ioc.UserPreference" scope="session"/>,同Http請求相同，每一次session請求創(chuàng)建新的實(shí)例，而不同的實(shí)例之間不共享屬性，且實(shí)例僅在自己的session請求內(nèi)有效，請求結(jié)束，則實(shí)例將被銷毀。
5.global Session：在一個(gè)全局的Http Session中，容器會(huì)返回該Bean的同一個(gè)實(shí)例，僅在使用portlet context時(shí)有效。

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項(xiàng)目
mvn archetype:create -DgroupId= DartifactId= -DarchetypeArtifactId=maven-archetype-webapp 創(chuàng)建web項(xiàng)目
mvn compile 編譯項(xiàng)目代碼
mvn package 打包項(xiàng)目
mvn package -Dmaven.test.skip=true 打包項(xiàng)目時(shí)跳過單元測試
mvn test 運(yùn)行單元測試
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項(xiàng)目結(jié)構(gòu)
mvn eclipse:clean 清除maven項(xiàng)目中eclipse的項(xiàng)目結(jié)構(gòu)
mvn site 生成站點(diǎn)目錄
mvn dependency:list 顯示所有已經(jīng)解析的所有依賴
mvn dependency:tree 以樹的結(jié)構(gòu)展示項(xiàng)目中的依賴
mvn dependency:analyze 對項(xiàng)目中的依賴進(jìn)行分析，依賴未使用，使用單未引入
mvn tomcat:run 啟動(dòng)tomcat

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

？？？？

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

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

char[] value;

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

public StringBuilder() {
    super(16);
}

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

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

分布式和集群

分布式：一個(gè)業(yè)務(wù)分拆多個(gè)子業(yè)務(wù)，部署在不同的服務(wù)器上，(我的補(bǔ)充：)具有處理高并發(fā)的能力，但一個(gè)子業(yè)務(wù)系統(tǒng)宕機(jī)，該子業(yè)務(wù)功能將無法實(shí)現(xiàn)。
集群：同一個(gè)業(yè)務(wù)，部署在多個(gè)服務(wù)器上，(我的補(bǔ)充：)具有高可用的能力，一個(gè)系統(tǒng)宕機(jī)，不影響業(yè)務(wù)實(shí)現(xiàn)。

分布式事物

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

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

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

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

在分布式系統(tǒng)里面有一個(gè)CAP定律，這個(gè)定理的內(nèi)容是指的是在一個(gè)分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可得兼
一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否同樣的值。（等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本）
可用性（A）：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）
分區(qū)容錯(cuò)性（P）：以實(shí)際效果而言，分區(qū)相當(dāng)于對通信的時(shí)限要求。系統(tǒng)如果不能在時(shí)限內(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)方法，實(shí)際上是對調(diào)用該方法的對象加鎖，俗稱“對象鎖”

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

情況2：不同對象在兩個(gè)線程中調(diào)用同一個(gè)同步方法
結(jié)果：不會(huì)產(chǎn)生互斥。
解釋：因?yàn)槭莾蓚€(gè)對象，鎖針對的是對象，并不是方法，所以可以并發(fā)執(zhí)行，不會(huì)互斥。形象的來說就是因?yàn)槲覀兠總€(gè)線程在調(diào)用方法的時(shí)候都是new 一個(gè)對象，那么就會(huì)出現(xiàn)兩個(gè)空間，兩把鑰匙

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

情況1：用類直接在兩個(gè)線程中調(diào)用兩個(gè)不同的同步方法
結(jié)果：會(huì)產(chǎn)生互斥。
解釋：因?yàn)閷o態(tài)對象加鎖實(shí)際上對類（.class）加鎖，類對象只有一個(gè)，可以理解為任何時(shí)候都只有一個(gè)空間，里面有N個(gè)房間，一把鎖，因此房間（同步方法）之間一定是互斥的。
注：上述情況和用單例模式聲明一個(gè)對象來調(diào)用非靜態(tài)方法的情況是一樣的，因?yàn)橛肋h(yuǎn)就只有這一個(gè)對象。所以訪問同步方法之間一定是互斥的。

情況2：用一個(gè)類的靜態(tài)對象在兩個(gè)線程中調(diào)用靜態(tài)方法或非靜態(tài)方法
結(jié)果：會(huì)產(chǎn)生互斥。
解釋：因?yàn)槭且粋€(gè)對象調(diào)用，同上。

情況3：一個(gè)對象在兩個(gè)線程中分別調(diào)用一個(gè)靜態(tài)同步方法和一個(gè)非靜態(tài)同步方法
結(jié)果：不會(huì)產(chǎn)生互斥。
解釋：因?yàn)殡m然是一個(gè)對象調(diào)用，但是兩個(gè)方法的鎖類型不同，調(diào)用的靜態(tài)方法實(shí)際上是類對象在調(diào)用，即這兩個(gè)方法產(chǎn)生的并不是同一個(gè)對象鎖，因此不會(huì)互斥，會(huì)并發(fā)執(zhí)行。

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

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

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

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

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

AQS相關(guān)

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

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

jdk1.8的新特性

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

lambda表達(dá)式的實(shí)現(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á)性分析算法的思想：從一個(gè)被稱為GC Roots的對象開始向下搜索，如果一個(gè)對象到GC Roots沒有任何引用鏈相連時(shí)，則說明此對象不可用。
在java中可以作為GC Roots的對象有以下幾種：
虛擬機(jī)棧中引用的對象、方法區(qū)類靜態(tài)屬性引用的對象、方法區(qū)常量池引用的對象、本地方法棧JNI引用的對象
雖然這些算法可以判定一個(gè)對象是否能被回收，但是當(dāng)滿足上述條件時(shí)，一個(gè)對象 不一定會(huì)被回收。當(dāng)一個(gè)對象不可達(dá)GC Roots時(shí)，這個(gè)對象并不會(huì)馬上被回收，而是處于一個(gè)死緩的階段，若要被真正的回收需要經(jīng)歷兩次標(biāo)記。如果對象在可達(dá)性分析中沒有與GC Roots的引用鏈，那么此時(shí)就會(huì)被第一次標(biāo)記并且進(jìn)行一次篩選，篩選的條件是是否有必要執(zhí)行finalize()方法。當(dāng)對象沒有覆蓋finalize()方法或者已經(jīng)被虛擬機(jī)調(diào)用過，那么就認(rèn)為是沒必要的。
如果該對象有必要執(zhí)行finalize()方法，那么這個(gè)對象將會(huì)放在一個(gè)稱為F-Queue的隊(duì)列中，虛擬機(jī)會(huì)觸發(fā)一個(gè)finalize()線程去執(zhí)行，此線程是低優(yōu)先級的，并且虛擬機(jī)不會(huì)承諾一直等待它運(yùn)行完，這還是因?yàn)槿绻鹒inalize()執(zhí)行緩慢或者發(fā)生了死鎖，那么就會(huì)造成F-Queue隊(duì)列一直等待，造成了內(nèi)存回收系統(tǒng)的崩潰。GC對處于F-Queue中的對象進(jìn)行第二次被標(biāo)記，這時(shí)，該對象將被移除“即將回收”集合，等待回收。

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

https://blog.csdn.net/u013777351/article/details/49226101
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2、TCP提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付
Tcp通過校驗(yàn)和，重傳控制，序號標(biāo)識，滑動(dòng)窗口、確認(rèn)應(yīng)答實(shí)現(xiàn)可靠傳輸。如丟包時(shí)的重發(fā)控制，還可以對次序亂掉的分包進(jìn)行順序控制。
3、UDP具有較好的實(shí)時(shí)性，工作效率比TCP高，適用于對高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。
4.每一條TCP連接只能是點(diǎn)到點(diǎn)的;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ā)生的四個(gè)條件：

1、互斥條件：一份資源每次只能被一個(gè)進(jìn)程或線程使用（在Java中一般體現(xiàn)為，一個(gè)對象鎖只能被一個(gè)線程持有）
2、請求與保持條件：一個(gè)進(jìn)程或線程在等待請求資源被釋放時(shí)，不釋放已占有資源
3、不可剝奪條件：一個(gè)進(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)同時(shí)進(jìn)行

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

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

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

索引分單列索引和組合索引。單列索引，即一個(gè)索引只包含單個(gè)列，一個(gè)表可以有多個(gè)單列索引，但這不是組合索引。組合索引，即一個(gè)索引包含多個(gè)列。索引可以大大提高M(jìn)ySQL的檢索速度。索引也會(huì)有它的缺點(diǎn)：雖然索引大大提高了查詢速度，同時(shí)卻會(huì)降低更新表的速度，如對表進(jìn)行INSERT、UPDATE和DELETE。因?yàn)楦卤頃r(shí)，MySQL不僅要保存數(shù)據(jù)，還要保存一下索引文件。

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

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

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

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

1.主鍵約束（Primay Key Coustraint） 唯一性，非空性；
2.唯一約束 （Unique Counstraint）唯一性，可以空，但只能有一個(gè)；
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'兩個(gè)字段

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

第三范式（3NF）：
第三范式(3NF)：滿足2NF后，要求：表中的每一列都要與主鍵直接相關(guān)，而不是間接相關(guān)（表中的每一列只能依賴于主鍵）
例如：訂單表中需要有客戶相關(guān)信息，在分離出客戶表之后，訂單表中只需要有一個(gè)用戶ID即可，而不能有其他的客戶信息，因?yàn)槠渌挠脩粜畔⑹侵苯雨P(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ù)，自動(dòng)提交，這樣會(huì)影響速度，所以最好把多條SQL語言放在begin和commit之間，組成一個(gè)事務(wù)； 2. InnoDB支持外鍵，而MyISAM不支持。對一個(gè)包含外鍵的InnoDB表轉(zhuǎn)為MYISAM會(huì)失?。? 3. InnoDB是聚集索引，數(shù)據(jù)文件是和索引綁在一起的，必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然后再通過主鍵查詢到數(shù)據(jù)。因此，主鍵不應(yīng)該過大，因?yàn)橹麈I太大，其他索引也都會(huì)很大。而MyISAM是非聚集索引，數(shù)據(jù)文件是分離的，索引保存的是數(shù)據(jù)文件的指針。主鍵索引和輔助索引是獨(dú)立的。 4. InnoDB不保存表的具體行數(shù)，執(zhí)行select count(*) from table時(shí)需要全表掃描。而MyISAM用一個(gè)變量保存了整個(gè)表的行數(shù)，執(zhí)行上述語句時(shí)只需要讀出該變量即可，速度很快； 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，至少不會(huì)差。

如何定位慢sql

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

如何分析慢sql

explain

如何解決慢sql

加索引，in優(yōu)化、分頁優(yōu)化、分庫分表等等。。。

面向事件編程

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

mybatis的源碼分析

hashmap的原理、concurrentHashmap、hashtable

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

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

tomcat下的文件夾

堆、棧溢出的問題

spring的bean的生命周期