1-Java基礎(chǔ)
1.1-String和StringBuffer區(qū)別，為什么是可變的，不可變的
String 類中使用 final 關(guān)鍵字修飾字符數(shù)組來保存字符串，private final char value[]，所以 String 對(duì)象是不可變的，String 類中使用 final 關(guān)鍵字修飾字符數(shù)組來保存字符串，private final char value[]，所以 String 對(duì)象是不可變的
StringBuilder 與 StringBuffer 都繼承自 AbstractStringBuilder 類，在 AbstractStringBuilder 中也是使用字符數(shù)組保存字符串char[]value 但是沒有用 final 關(guān)鍵字修飾，所以這兩種對(duì)象都是可變的
1.2-ArrayList和LinkedList區(qū)別，LindkedList中的列表是單向鏈表還是雙向鏈表
1. 都不是線程安全的
2. ArrayList底層使用的是的Object數(shù)組，LinkedList底層使用的是雙向鏈表
3. ArrayList支持隨機(jī)訪問
1.3-HashMap實(shí)現(xiàn)原理，put過程，put過程中多線程情況下會(huì)出現(xiàn)什么問題（會(huì)出現(xiàn)死循環(huán)，為什么會(huì)出現(xiàn)死循環(huán)），鏈表什么時(shí)候及為什么要轉(zhuǎn)紅黑樹？為什么擴(kuò)容的時(shí)候必須是2的冪次方……
1. JDK1.8之前 HashMap 底層是 數(shù)組+鏈表 ,1.8之后數(shù)組+鏈表+紅黑樹
2. 默認(rèn)數(shù)組長(zhǎng)度是16，默認(rèn)擴(kuò)容加載因子是0.75，鏈表長(zhǎng)度大于8變?yōu)榧t黑樹，小于6變?yōu)閿?shù)組
3.當(dāng)多線程put時(shí)，當(dāng)數(shù)組需要擴(kuò)容時(shí)重新進(jìn)行rehash，transfer方法會(huì)修改鏈表中node的前后指針，有可能出現(xiàn)環(huán)鏈從而死鎖
4. 這個(gè)數(shù)組下標(biāo)的計(jì)算方法是 (n - 1) & hash , 另外擴(kuò)容為2的冪次方，數(shù)組擴(kuò)容時(shí)數(shù)據(jù)要么待在原來的下標(biāo)， 或者移動(dòng)到新數(shù)組的高位下標(biāo)
1.4-HashTable怎么保證線程安全的
HashTable 內(nèi)部的方法基本都經(jīng)過synchronized 修飾，效率太低，被拋棄的集合，建議使用concurrentHashMap
1.5-ConcurrentHashMap實(shí)現(xiàn)線程安全的原理
JDK 1.7 首先將數(shù)據(jù)分為一段一段的存儲(chǔ)，然后給每一段數(shù)據(jù)配一把鎖，當(dāng)一個(gè)線程占用鎖訪問其中一個(gè)段數(shù)據(jù)時(shí)，其他段的數(shù)據(jù)也能被其他線程訪問。
JDK 1.8 ConcurrentHashMap取消了Segment分段鎖，采用CAS和synchronized來保證并發(fā)安全。synchronized只鎖定當(dāng)前鏈表或紅黑二叉樹的首節(jié)點(diǎn)，這樣只要hash不沖突，就不會(huì)產(chǎn)生并發(fā)，效率又提升N倍。
1.6-LinkedHashMap怎么做到有序的
主要是基于 HashMap + 雙向鏈表
image.png
1.7-Java中線程的狀態(tài)
線程創(chuàng)建之后處于初始狀態(tài)，調(diào)用start之后處于ready狀態(tài)，得到cup時(shí)候處于running狀態(tài)，ready和running合稱運(yùn)行狀態(tài)，當(dāng)調(diào)用wait/join之后處于等待狀態(tài)，需要調(diào)用notify/notifyAll回到運(yùn)行狀態(tài)，當(dāng)調(diào)用sleep或者notify(long)處于超時(shí)等待狀態(tài)，當(dāng)超時(shí)時(shí)間執(zhí)行完畢就自動(dòng)恢復(fù)到運(yùn)行狀態(tài)，當(dāng)調(diào)用sysnchroinzed處于阻塞狀態(tài)，當(dāng)獲得鎖之后回到運(yùn)行狀態(tài)，運(yùn)行完成進(jìn)入終止?fàn)顟B(tài)
1.8-Synchronized鎖的實(shí)現(xiàn)原理，為什么monitorexit指令會(huì)出現(xiàn)兩次
monitorenter、monitorexit、monitorexit
monitorenter 鎖開始，monitorexit 鎖正常退出，monitorexit 拋出異常鎖退出
https://www.cnblogs.com/aspirant/p/11470858.html
1.9-RetrantLock實(shí)現(xiàn)原理，跟Synchronized的區(qū)別
ReentrantLock是基于AQS實(shí)現(xiàn)的,AQS核心思想是，如果被請(qǐng)求的共享資源空閑，則將當(dāng)前請(qǐng)求資源的線程設(shè)置為有效的工作線程，并且將共享資源設(shè)置為鎖定狀態(tài)。如果被請(qǐng)求的共享資源被占用，那么就需要一套線程阻塞等待以及被喚醒時(shí)鎖分配的機(jī)制，這個(gè)機(jī)制AQS是用CLH隊(duì)列鎖實(shí)現(xiàn)的，即將暫時(shí)獲取不到鎖的線程加入到隊(duì)列中。
- 兩者都是可重入鎖
- synchronized 依賴于 JVM 而 ReentrantLock 依賴于 API
- ReentrantLock 支持公平鎖，非公平鎖，中斷等待，通知等
- https://www.cnblogs.com/xrq730/p/4979021.html
1.10-如何讓線程A,B,C按照順序執(zhí)行（join，CountDownLatch）
join、CountDownLatch、單線程池
https://www.cnblogs.com/wenjunwei/p/10573289.html
1.11-Java中的幾種常用線程池及他們的特點(diǎn)
- FixedThreadPool ： 該方法返回一個(gè)固定線程數(shù)量的線程池。該線程池中的線程數(shù)量始終不變。當(dāng)有一個(gè)新的任務(wù)提交時(shí)，線程池中若有空閑線程，則立即執(zhí)行。若沒有，則新的任務(wù)會(huì)被暫存在一個(gè)任務(wù)隊(duì)列中，待有線程空閑時(shí)，便處理在任務(wù)隊(duì)列中的任務(wù)。
- SingleThreadExecutor： 方法返回一個(gè)只有一個(gè)線程的線程池。若多余一個(gè)任務(wù)被提交到該線程池，任務(wù)會(huì)被保存在一個(gè)任務(wù)隊(duì)列中，待線程空閑，按先入先出的順序執(zhí)行隊(duì)列中的任務(wù)。
- CachedThreadPool： 該方法返回一個(gè)可根據(jù)實(shí)際情況調(diào)整線程數(shù)量的線程池。線程池的線程數(shù)量不確定，但若有空閑線程可以復(fù)用，則會(huì)優(yōu)先使用可復(fù)用的線程。若所有線程均在工作，又有新的任務(wù)提交，則會(huì)創(chuàng)建新的線程處理任務(wù)。所有線程在當(dāng)前任務(wù)執(zhí)行完畢后，將返回線程池進(jìn)行復(fù)用。
- ScheduledThreadPool：這是個(gè)可重用固定個(gè)數(shù)的線程池，當(dāng)前線程數(shù)大于總數(shù)則會(huì)進(jìn)行等待，并且可以設(shè)置線程延遲執(zhí)行時(shí)間
1.12-線程池參數(shù)，工作過程，線程池拒絕策略，線程池中任務(wù)隊(duì)列的特點(diǎn)
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue) {
this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
Executors.defaultThreadFactory(), defaultHandler);
}
ThreadPoolExecutor 3 個(gè)最重要的參數(shù)：
-
corePoolSize: 核心線程數(shù)線程數(shù)定義了最小可以同時(shí)運(yùn)行的線程數(shù)量。 -
maximumPoolSize: 當(dāng)隊(duì)列中存放的任務(wù)達(dá)到隊(duì)列容量的時(shí)候，當(dāng)前可以同時(shí)運(yùn)行的線程數(shù)量變?yōu)樽畲缶€程數(shù)。 -
workQueue: 當(dāng)新任務(wù)來的時(shí)候會(huì)先判斷當(dāng)前運(yùn)行的線程數(shù)量是否達(dá)到核心線程數(shù)，如果達(dá)到的話，新任務(wù)就會(huì)被存放在隊(duì)列中。 -
handler:飽和(拒絕)策略。
ThreadPoolExecutor其他常見參數(shù):
-
keepAliveTime:當(dāng)線程池中的線程數(shù)量大于corePoolSize的時(shí)候，如果這時(shí)沒有新的任務(wù)提交，核心線程外的線程不會(huì)立即銷毀，而是會(huì)等待，直到等待的時(shí)間超過了keepAliveTime才會(huì)被回收銷毀； -
unit:keepAliveTime參數(shù)的時(shí)間單位。 -
threadFactory:executor 創(chuàng)建新線程的時(shí)候會(huì)用到。
拒絕策略：
-
ThreadPoolExecutor.AbortPolicy：拋出RejectedExecutionException來拒絕新任務(wù)的處理。 -
ThreadPoolExecutor.CallerRunsPolicy：調(diào)用執(zhí)行自己的線程運(yùn)行任務(wù)。您不會(huì)任務(wù)請(qǐng)求。但是這種策略會(huì)降低對(duì)于新任務(wù)提交速度，影響程序的整體性能。另外，這個(gè)策略喜歡增加隊(duì)列容量。如果您的應(yīng)用程序可以承受此延遲并且你不能任務(wù)丟棄任何一個(gè)任務(wù)請(qǐng)求的話，你可以選擇這個(gè)策略。 -
ThreadPoolExecutor.DiscardPolicy： 不處理新任務(wù)，直接丟棄掉。 -
ThreadPoolExecutor.DiscardOldestPolicy： 此策略將丟棄最早的未處理的任務(wù)請(qǐng)求。
workQueue:(阻塞隊(duì)列)
ArrayBlockingQueue:
一個(gè)對(duì)象數(shù)組+一把鎖+兩個(gè)條件
入隊(duì)與出隊(duì)都用同一把鎖
在只有入隊(duì)高并發(fā)或出隊(duì)高并發(fā)的情況下，因?yàn)椴僮鲾?shù)組，且不需要擴(kuò)容，性能很高
采用了數(shù)組，必須指定大小，即容量有限
LinkedBlockingQueue：
一個(gè)單向鏈表+兩把鎖+兩個(gè)條件
兩把鎖，一把用于入隊(duì)，一把用于出隊(duì)，有效的避免了入隊(duì)與出隊(duì)時(shí)使用一把鎖帶來的競(jìng)爭(zhēng)。
在入隊(duì)與出隊(duì)都高并發(fā)的情況下，性能比ArrayBlockingQueue高很多
采用了鏈表，最大容量為整數(shù)最大值，可看做容量無限
DelayQueue:
DelayQueue中的元素只有當(dāng)其指定的延遲時(shí)間到了，才能夠從隊(duì)列中獲取到該元素。DelayQueue是一個(gè)沒有大小限制的隊(duì)列，因此往隊(duì)列中插入數(shù)據(jù)的操作（生產(chǎn)者）永遠(yuǎn)不會(huì)被阻塞，而只有獲取數(shù)據(jù)的操作（消費(fèi)者）才會(huì)被阻塞。
1.13-樂觀鎖（CAS）和悲觀鎖（Synchronized，RetrantLock），CAS原理，ABA問題，CAS的優(yōu)缺點(diǎn)，CAS輪詢占用CPU為什么還有很多實(shí)現(xiàn)都是用的CAS
1.14-Volatile的作用
依靠?jī)?nèi)存屏障實(shí)現(xiàn)
1.可見性 讀取主內(nèi)存
2.有序性防止指令重排
1.15-內(nèi)存屏障
內(nèi)存屏障（Memory Barrier，或有時(shí)叫做內(nèi)存柵欄，Memory Fence）是一種CPU指令，用于控制特定條件下的重排序和內(nèi)存可見性問題。Java編譯器也會(huì)根據(jù)內(nèi)存屏障的規(guī)則禁止重排序。
https://www.cnblogs.com/snow-man/p/10876362.html
1.16-JMM內(nèi)存模型
我們常說的JVM內(nèi)存模式指的是JVM的內(nèi)存分區(qū)；而Java內(nèi)存模式是一種虛擬機(jī)規(guī)范。
Java虛擬機(jī)規(guī)范中定義了Java內(nèi)存模型（Java Memory Model，JMM），用于屏蔽掉各種硬件和操作系統(tǒng)的內(nèi)存訪問差異，以實(shí)現(xiàn)讓Java程序在各種平臺(tái)下都能達(dá)到一致的并發(fā)效果，JMM規(guī)范了Java虛擬機(jī)與計(jì)算機(jī)內(nèi)存是如何協(xié)同工作的：規(guī)定了一個(gè)線程如何和何時(shí)可以看到由其他線程修改過后的共享變量的值，以及在必須時(shí)如何同步的訪問共享變量。
https://zhuanlan.zhihu.com/p/29881777
1.17-Threadlocal原理
ThreadLocal 內(nèi)部維護(hù)的是一個(gè)類似 Map 的ThreadLocalMap 數(shù)據(jù)結(jié)構(gòu)，key 為當(dāng)前對(duì)象的 Thread 對(duì)象，值為 Object 對(duì)象。
如果你創(chuàng)建了一個(gè)ThreadLocal變量，那么訪問這個(gè)變量的每個(gè)線程都會(huì)有這個(gè)變量的本地副本，這也是ThreadLocal變量名的由來。他們可以使用 get（） 和 set（） 方法來獲取默認(rèn)值或?qū)⑵渲蹈臑楫?dāng)前線程所存的副本的值，從而避免了線程安全問題。
1.18-死鎖：產(chǎn)生死鎖必須具備以下四個(gè)條件，避免死鎖破壞四個(gè)條件其中的一個(gè)即可
- 互斥條件：該資源任意一個(gè)時(shí)刻只由一個(gè)線程占用。
- 請(qǐng)求與保持條件：一個(gè)進(jìn)程因請(qǐng)求資源而阻塞時(shí)，對(duì)已獲得的資源保持不放。
- 不剝奪條件:線程已獲得的資源在末使用完之前不能被其他線程強(qiáng)行剝奪，只有自己使用完畢后才釋放資源。
- 循環(huán)等待條件:若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。
2-JVM
2.1-JVM內(nèi)存結(jié)構(gòu)（運(yùn)行時(shí)數(shù)據(jù)區(qū)）
線程私有的：
1.程序計(jì)數(shù)器
2.虛擬機(jī)棧
3.本地方法棧
線程共享的：
1.堆
2.方法區(qū)
3.直接內(nèi)存(非運(yùn)行時(shí)數(shù)據(jù)區(qū)的一部分)
2.2-常用垃圾回收算法
1.標(biāo)記清除
2.標(biāo)記整理
3.復(fù)制算法
4.分代收集算法
2.3-常常用的垃圾收集器
1.Serial / Serial Old
Serial/SerialOld收集器是最基本最古老的收集器，它是一個(gè)單線程收集器，并在在它進(jìn)行垃圾收集時(shí)，必須暫停所有的用戶線程。Serial收集器是針對(duì)新生代的收集器，采用的是復(fù)制算法 Serial Old收集器是針對(duì)老年代的收集器，采用的是復(fù)制-整理算法。
2.ParNew
ParNew收集器是Serial收集器的多線程版本，使用多個(gè)線程進(jìn)行垃圾回收
3.Parallel Scavenge
Parallel Scavenge收集器是一個(gè)新生代的多線程收集器，使用復(fù)制算法，它在回收期間需要暫停其他的用戶線程。
4.Parallel Old
Parallel Old是Parallel Scavenge收集器的老年代版本，使用的是標(biāo)記-整理算法
5.CMS
CMS收集器是一種以獲取最短停頓時(shí)間為目標(biāo)的收集器，它是一種并發(fā)收集器，采用的是標(biāo)記-清除算法
6.G1
G1收集器是當(dāng)今收集器技術(shù)發(fā)展最前沿的成果，它是一款面向服務(wù)端應(yīng)用的收集器，它能充分利用多CPU，多核環(huán)境，因此它是一款并行與并發(fā)的收集器
2.3-垃圾回收過程
判斷哪些對(duì)象死亡，將死亡的對(duì)象進(jìn)行清除
分代收集詳述：
1、所有new出來的對(duì)象都會(huì)最先分配到新生代區(qū)域中，兩個(gè)survivor（S0和S1）區(qū)域初始化是為空的；
2、當(dāng)伊甸園區(qū)域滿了之后，就會(huì)引發(fā)一次minor garbage collection（小型垃圾回收）；
3、當(dāng)在minor garbage collection（小型垃圾回收），存活下來的對(duì)象就會(huì)被移到S0區(qū)域；
4、當(dāng)伊甸園區(qū)域再次填滿時(shí)，又會(huì)發(fā)生下一次垃圾回收，存活下來的對(duì)象會(huì)被移到survivor區(qū)域，而未存活的對(duì)象則被直接刪除，但是，不同的是，在這次垃圾回收中，存活對(duì)象和之前在S0區(qū)域中的對(duì)象都會(huì)移到S1區(qū)域中。一旦所有對(duì)象都被移到S1區(qū)域中，那么S0中的對(duì)象就會(huì)被清除；
5、下一次的垃圾回收的時(shí)候，又會(huì)重復(fù)上次的步驟，清除需要回收的對(duì)象，并且切換一次survivor區(qū)域，所有存活的對(duì)象都被移到S0，伊甸園區(qū)域和S1區(qū)域被清除；
6、重復(fù)以上步驟，并記錄對(duì)象的年齡（記錄垃圾回收的次數(shù)），當(dāng)有對(duì)象的年齡達(dá)到一定的閾值時(shí)，就將新生代中的對(duì)象移到到老年代
7、接下來垃圾回收就會(huì)重復(fù)以上步驟，不斷的進(jìn)行對(duì)象的清除和年代的移動(dòng)；
8、當(dāng)達(dá)到老年代回收條件時(shí)會(huì)觸發(fā)Major GC進(jìn)行老年代回收
2.4堆內(nèi)存的分代：Eden，from，to，Old
<img src="https://img-blog.csdn.net/20160330210437130" alt="分代算法" style="zoom:60%;" />
2.5-JVM1.7和1.8的區(qū)別，去掉了永久代，改成了Metaspace，為什么
JDK 1.8 的時(shí)候，方法區(qū)（HotSpot的永久代）被徹底移除了（JDK1.7就已經(jīng)開始了），取而代之是元空間，元空間使用的是直接內(nèi)存
1.整個(gè)永久代有一個(gè) JVM 本身設(shè)置固定大小上限，無法進(jìn)行調(diào)整和優(yōu)化
2.簡(jiǎn)化垃圾回收
3.虛擬機(jī)整合
2.6-CMS收集器工作過程及特點(diǎn)
工作過程： 初始標(biāo)記-->并發(fā)標(biāo)記-->重新標(biāo)記-->并發(fā)清除
CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時(shí)間為目標(biāo)的收集器。它而非常符合在注重用戶體驗(yàn)的應(yīng)用上使用。
CMS（Concurrent Mark Sweep）收集器是HotSpot虛擬機(jī)第一款真正意義上的并發(fā)收集器，它第一次實(shí)現(xiàn)了讓垃圾收集線程與用戶線程（基本上）同時(shí)工作。
2.7-G1收集器工作過程及特點(diǎn)
1.初始標(biāo)記
2.并發(fā)標(biāo)記
3.最終標(biāo)記
4.篩選回收
G1 (Garbage-First)是一款面向服務(wù)器的垃圾收集器,主要針對(duì)配備多顆處理器及大容量?jī)?nèi)存的機(jī)器. 以極高概率滿足GC停頓時(shí)間要求的同時(shí),還具備高吞吐量性能特征.
2.8-怎么進(jìn)行JVM調(diào)優(yōu)
https://www.iteye.com/blog/pengjiaheng-552456
2.9-用什么查看內(nèi)存映像，jmap+MAT
2.10-怎么排查CPU飆高，top+jstack
2.11 公司的jvm參數(shù)
-Xmn512m 年輕代大小(1.4or lator)
-Xms1024m 初始堆大小 物理內(nèi)存的1/64(<1GB)
-Xmx1024m 最大堆大小 物理內(nèi)存的1/4(<1GB)
-XX:+UseConcMarkSweepGC 使用CMS內(nèi)存收集
-XX:CMSInitiatingOccupancyFraction=70 使用cms作為垃圾回收使用70％后開始CMS收集
-XX:MaxDirectMemorySize=256m
-XX:+UseCMSInitiatingOccupancyOnly 使用手動(dòng)定義初始化定義開始CMS收集
-XX:SurvivorRatio=8 Eden區(qū)與Survivor區(qū)的大小比值
-XX:+ExplicitGCInvokesConcurrent
-XX:MetaspaceSize=128m 設(shè)置元數(shù)據(jù)空間初始大?。ㄈ〈?XX:PermSize）
-XX:MaxMetaspaceSize=256m 設(shè)置元數(shù)據(jù)空間最大值（取代之前-XX:MaxPermSize）
-XX:-OmitStackTraceInFastThrow
-XX:+PrintGCDetails 輸出格式
-XX:+PrintGCDateStamps 打印GC日期
-Xloggc:/var/www/logs/gc-%t.log 把相關(guān)日志信息記錄到文件以便分析.
-XX:+UseGCLogFileRotation 開啟滾動(dòng)日志記錄
-XX:NumberOfGCLogFiles=5 滾動(dòng)數(shù)量，命名為filename.0, ..... filename.n-1, 然后再?gòu)膄ilename.0 開始，并覆蓋已經(jīng)存在的文件
-XX:GCLogFileSize=10m 文件大小
-XX:+HeapDumpOnOutOfMemoryError 出現(xiàn)內(nèi)存溢出時(shí)存儲(chǔ)堆信息
-XX:HeapDumpPath=/var/www/logs 堆快照存儲(chǔ)位置
-Djava.io.tmpdir=/var/www/tmp
3-MySQL
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-1hWR8GzJ-1588925877291)(/Users/yqx/Desktop/數(shù)據(jù)庫(kù)索引總結(jié).png)]
3.1-Mysql的索引原理B+樹，聚簇索引，輔助索引的區(qū)別，為什么輔助索引不直接報(bào)存數(shù)據(jù)而是主鍵的值
聚簇索引：樹的葉節(jié)點(diǎn)data域保存了完整的數(shù)據(jù)記錄
輔助索引：輔助索引的葉節(jié)點(diǎn)data域存儲(chǔ)相應(yīng)記錄主鍵的值(不是地址)
回表：在根據(jù)輔助索引查找時(shí)，則需要先取出主鍵的值，再走一遍主索引
3.2-什么情況下索引會(huì)失效
- or
- like 以 % 開頭，以%結(jié)尾會(huì)命中索引，eg: '三%'
- 隱式轉(zhuǎn)換
- 不遵循最左原則
- MYSQL優(yōu)化器估計(jì)使用索引比全部掃描要慢
- !=或<>
- is null 、 is not null
3.3-聯(lián)合索引什么情況會(huì)失效
遵循最左原則，eg：聯(lián)合索引a,b,c
命中索引：a、a,b、a,b,c
https://zhuanlan.zhihu.com/p/108179618
https://zhuanlan.zhihu.com/p/108179618
https://zhuanlan.zhihu.com/p/108179618
3.4-怎么判斷對(duì)一個(gè)表的哪個(gè)字段建索引，建索引要注意什么
- 在經(jīng)常需要搜索查詢的列上創(chuàng)建索引，可以加快搜索的速度；
- 在作為主鍵的列上創(chuàng)建索引，強(qiáng)制該列的唯一性和組織表中數(shù)據(jù)的排列結(jié)構(gòu)；
- 在經(jīng)常用在連接的列上創(chuàng)建索引，這些列主要是一些外鍵，可以加快連接的速度；
- 在經(jīng)常需要根據(jù)范圍進(jìn)行搜索的列上創(chuàng)建索引，因?yàn)樗饕呀?jīng)排序，其指定的范圍是連續(xù)的；
- 在經(jīng)常需要排序的列上創(chuàng)建索引，因?yàn)樗饕呀?jīng)排序，這樣查詢可以利用索引的排序，加快排序查詢 時(shí)間；
- 在經(jīng)常使用在Where子句中的列上面創(chuàng)建索引，加快條件的判斷速度；
- 為經(jīng)常出現(xiàn)在關(guān)鍵字order by、group by、distinct后面的字段，建立索引。
1.盡量量選擇區(qū)分度?高的列列作為索引,區(qū)分度的公式是count(distinct col)/ count(*),表示字段不不重復(fù)的?比例例,?比例例越?大掃描的記錄數(shù)越少
2.單個(gè)索引中的字段數(shù)最好不不超過3個(gè)
3.對(duì)?長(zhǎng)度?大于100的字段建?立索引時(shí)，按需求恰當(dāng)?shù)氖?用前綴索引
3.5-InnoDB和MyISAM的區(qū)別
- InnoDB支持事務(wù)，MyISAM不支持，對(duì)于InnoDB每一條SQL語(yǔ)言都默認(rèn)封裝成事務(wù)，自動(dòng)提交，這樣會(huì)影響速度，所以最好把多條SQL語(yǔ)言放在begin和commit之間，組成一個(gè)事務(wù)；
- InnoDB支持外鍵，而MyISAM不支持。對(duì)一個(gè)包含外鍵的InnoDB表轉(zhuǎn)為MYISAM會(huì)失??；
- InnoDB：是聚集索引，數(shù)據(jù)文件是和（主鍵）索引綁在一起的，必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然后再通過主鍵查詢到數(shù)據(jù)。因此，主鍵不應(yīng)該過大，因?yàn)橹麈I太大，其他索引也都會(huì)很大。
MyISAM：是非聚集索引，索引和數(shù)據(jù)文件是分離的，索引保存的是數(shù)據(jù)文件的指針。主鍵索引和輔助索引是獨(dú)立的 - InnoDB支持表、行(默認(rèn))級(jí)鎖，而MyISAM支持表級(jí)鎖
3.6-MySQL的鎖，表鎖，行鎖
- 表級(jí)鎖： MySQL中鎖定 粒度最大 的一種鎖，對(duì)當(dāng)前操作的整張表加鎖，實(shí)現(xiàn)簡(jiǎn)單，資源消耗也比較少，加鎖快，不會(huì)出現(xiàn)死鎖。其鎖定粒度最大，觸發(fā)鎖沖突的概率最高，并發(fā)度最低，MyISAM和 InnoDB引擎都支持表級(jí)鎖。
- 行級(jí)鎖： MySQL中鎖定 粒度最小 的一種鎖，只針對(duì)當(dāng)前操作的行進(jìn)行加鎖。 行級(jí)鎖能大大減少數(shù)據(jù)庫(kù)操作的沖突。其加鎖粒度最小，并發(fā)度高，但加鎖的開銷也最大，加鎖慢，會(huì)出現(xiàn)死鎖。
3.7-Mysql的樂觀鎖
https://zhuanlan.zhihu.com/p/29150809
3.8-MySQL的MVCC
https://segmentfault.com/a/1190000012650596
3.9-Mysql的四種隔離級(jí)別分別解決了什么問題，怎么解決的，默認(rèn)哪種隔離級(jí)別，Mysql的臟讀，幻讀等
3.10-怎么進(jìn)行SQL優(yōu)化（慢查詢+explain執(zhí)行計(jì)劃）
http://blog.itpub.net/31555484/viewspace-2565387
3.11-Explain執(zhí)行計(jì)劃
http://m.itdecent.cn/p/fd781d6e1158
3.12-Mysql主從復(fù)制原理，怎么解決主從復(fù)制延遲問題
https://www.cnblogs.com/idoljames/p/11694039.html
3.13-Mysql的分庫(kù)分表弄過嗎，分表之后有什么問題，怎么解決（分頁(yè)查詢問題怎么解決？）
4-Redis
4.1-Redis常用的數(shù)據(jù)類型，有了解這些數(shù)據(jù)類型底層是怎么實(shí)現(xiàn)的嗎
string、list、hash、set、zset
4.2-Redis的緩存雪崩，緩存擊穿問題怎么解決，布隆過濾器原理
雪崩：緩存同一時(shí)間大面積的失效，所以，后面的請(qǐng)求都會(huì)落到數(shù)據(jù)庫(kù)上，造成數(shù)據(jù)庫(kù)短時(shí)間內(nèi)承受大量請(qǐng)求而崩掉。
擊穿：緩存穿透說簡(jiǎn)單點(diǎn)就是大量請(qǐng)求的 key 根本不存在于緩存中，導(dǎo)致請(qǐng)求直接到了數(shù)據(jù)庫(kù)上，根本沒有經(jīng)過緩存這一層
1.最基本的就是首先做好參數(shù)校驗(yàn)，一些不合法的參數(shù)請(qǐng)求直接拋出異常信息返回給客戶端。比如查詢的數(shù)據(jù)庫(kù) id 不能小于 0、傳入的郵箱格式不對(duì)的時(shí)候直接返回錯(cuò)誤消息給客戶端等等。
2.布隆過濾器
4.3-Redis的熱點(diǎn)key怎么發(fā)現(xiàn)，怎么解決
4.4-數(shù)據(jù)量很多的情況下，怎么用redis怎么統(tǒng)計(jì)日活，月活，bitmap，hyperLog……
https://www.cnblogs.com/yulibostu/articles/10337444.html
4.5-Redis的Master/slave和集群的區(qū)別，哨兵是干什么的
1.主從：一個(gè)Master可以有多個(gè)Slaves，寫主，讀從，master節(jié)點(diǎn)掛了以后，不會(huì)slave節(jié)點(diǎn)重新選一個(gè)master
2.集群：cluster的出現(xiàn)是為了解決單機(jī)Redis容量有限的問題，將Redis的數(shù)據(jù)根據(jù)一定的規(guī)則分配到多臺(tái)機(jī)器，通過cluster可以實(shí)現(xiàn)主從和master重選功能。多主多從，最小的是3主3從，必須是基數(shù)，涉及到master的選舉
3.哨兵：sentinel模式是建立在主從模式的基礎(chǔ)上，當(dāng)master節(jié)點(diǎn)掛了以后，sentinel會(huì)在slave中選擇一個(gè)做為master，并修改它們的配置文件，其他slave的配置文件也會(huì)被修改，比如slaveof屬性會(huì)指向新的master，sentinel可以理解為是主從的一個(gè)代理
4.6-你們的Redis用的哪種部署方式
cluster
4.7-Redis和memercached區(qū)別，哪個(gè)單線程，哪個(gè)多線程
4.8-Redis的持久化，aof，rdb
4.9-Redis的緩存淘汰策略
- volatile-lru：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
- volatile-ttl：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰
- volatile-random：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰
- allkeys-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，移除最近最少使用的key（這個(gè)是最常用的）
- allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰
- no-eviction：禁止驅(qū)逐數(shù)據(jù)，也就是說當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，新寫入操作會(huì)報(bào)錯(cuò)。這個(gè)應(yīng)該沒人使用吧！
4.0版本后增加以下兩種：
- volatile-lfu：從已設(shè)置過期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中挑選最不經(jīng)常使用的數(shù)據(jù)淘汰
- allkeys-lfu：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，移除最不經(jīng)常使用的key
4.10-用過哪些redis的數(shù)據(jù)類型
string、list、hash、set
4.11-Redis的發(fā)布訂閱
4.12-Redis怎么實(shí)現(xiàn)分布式鎖，redis分布式鎖當(dāng)前業(yè)務(wù)沒有執(zhí)行完但是鎖過期了怎么辦，鎖續(xù)期
加鎖
SET resource-name anystring NX EX max-lock-time
解鎖
if redis.call("get",KEYS[1]) == ARGV[1]
then
return redis.call("del",KEYS[1])
else
return 0
end
https://blog.csdn.net/lzhcoder/article/details/88387751
https://juejin.im/post/5d122f516fb9a07ed911d08c
4.13-數(shù)據(jù)庫(kù)與緩存雙寫不一致怎么解決
5-Zookeeper
zookeeper=文件系統(tǒng)+監(jiān)聽通知機(jī)制。
5.1-Zk有哪些節(jié)點(diǎn)類型
1.持久化目錄節(jié)點(diǎn)（PERSISTENT）
客戶端與zookeeper斷開連接后，該節(jié)點(diǎn)依舊存在
2.持久化順序編號(hào)目錄節(jié)點(diǎn)（PERSISTENT_SEQUENTIAL）
客戶端與zookeeper斷開連接后，該節(jié)點(diǎn)依舊存在，只是Zookeeper給該節(jié)點(diǎn)名稱進(jìn)行順序編號(hào)
3.臨時(shí)目錄節(jié)點(diǎn)（EPHEMERAL）
客戶端與zookeeper斷開連接后，該節(jié)點(diǎn)被刪除
4.臨時(shí)順序編號(hào)目錄節(jié)點(diǎn)（EPHEMERAL_SEQUENTIAL）
客戶端與zookeeper斷開連接后，該節(jié)點(diǎn)被刪除，只是Zookeeper給該節(jié)點(diǎn)名稱進(jìn)行順序編號(hào)
5.2-Zk的原理ZAB協(xié)議，master選舉過程，數(shù)據(jù)同步過程
http://www.jasongj.com/zookeeper/fastleaderelection/
https://www.cnblogs.com/hongdada/p/8145075.html
5.3-Zk如何實(shí)現(xiàn)分布式鎖，跟redis的分布式鎖有哪些區(qū)別
https://blog.csdn.net/sunfeizhi/article/details/51926396
Apache的開源庫(kù)Curator，它是一個(gè)ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實(shí)現(xiàn)，acquire方法用于獲取鎖，release方法用于釋放鎖。
https://www.cnblogs.com/mengchunchen/p/9647756.html
5.4-Zk跟eureka的區(qū)別
https://www.cnblogs.com/chihirotan/p/11366394.html
6-Dubbo
6.1-Dubbo的工作過程原理
1）第一步，provider向注冊(cè)中心去注冊(cè)
2）第二步，consumer從注冊(cè)中心訂閱服務(wù)，注冊(cè)中心會(huì)通知consumer注冊(cè)好的服務(wù)
3）第三步，consumer調(diào)用provider
4）第四步，consumer和provider都異步的通知監(jiān)控中心
-
Dubbo的負(fù)載均衡，集群容錯(cuò)策略
Random LoadBalance：隨機(jī)策略。按照概率設(shè)置權(quán)重，比較均勻，并且可以動(dòng)態(tài)調(diào)節(jié)提供者的權(quán)重。
RoundRobin LoadBalance：輪詢策略。輪詢，按公約后的權(quán)重設(shè)置輪詢比率。會(huì)存在執(zhí)行比較慢的服務(wù)提供者堆積請(qǐng)求的情況，比如一個(gè)機(jī)器執(zhí)行的非常慢，但是機(jī)器沒有掛調(diào)用（如果掛了，那么當(dāng)前機(jī)器會(huì)從Zookeeper的服務(wù)列表刪除），當(dāng)很多新的請(qǐng)求到達(dá)該機(jī)器后，由于之前的請(qǐng)求還沒有處理完畢，會(huì)導(dǎo)致新的請(qǐng)求被堆積，久而久之，所有消費(fèi)者調(diào)用這臺(tái)機(jī)器上的請(qǐng)求都被阻塞。
LeastActive LoadBalance：最少活躍調(diào)用數(shù)。如果每個(gè)提供者的活躍數(shù)相同，則隨機(jī)選擇一個(gè)。在每個(gè)服務(wù)提供者里面維護(hù)者一個(gè)活躍數(shù)計(jì)數(shù)器，用來記錄當(dāng)前同時(shí)處理請(qǐng)求的個(gè)數(shù)，也就是并發(fā)處理任務(wù)的個(gè)數(shù)。所以如果這個(gè)值越小說明當(dāng)前服務(wù)提供者處理的速度很快或者當(dāng)前機(jī)器的負(fù)載比較低，所以路由選擇時(shí)候就選擇該活躍度最小的機(jī)器。如果一個(gè)服務(wù)提供者處理速度很慢，由于堆積，那么同時(shí)處理的請(qǐng)求就比較多，也就是活躍調(diào)用數(shù)目越大，這也使得慢的提供者收到更少請(qǐng)求，因?yàn)樵铰奶峁┱叩幕钴S度越來越大。
ConsistentHash LoadBalance：一致性Hash策略。一致性Hash，可以保證相同參數(shù)的請(qǐng)求總是發(fā)到同一提供者，當(dāng)某一臺(tái)提供者掛了時(shí)，原本發(fā)往該提供者的請(qǐng)求，基于虛擬節(jié)點(diǎn)，平攤到其他提供者，不會(huì)引起劇烈變動(dòng)。
容錯(cuò)策略：
失敗重試
快速失敗
失敗安全
失敗自動(dòng)恢復(fù)
并行調(diào)用
廣播調(diào)用
6.2-Dubbo的配置優(yōu)先級(jí)順序，消費(fèi)方>提供方，方法>類>全局
6.3-Dubbo協(xié)議
6.4-Zookeeper注冊(cè)中心掛了，影響服務(wù)調(diào)用嗎
不影響，本地會(huì)緩存一份服務(wù)提供者的調(diào)用地址
6.6-Dubbo為什么要用zookeeper作為注冊(cè)中心
6.7-Dubbo服務(wù)治理用了哪些
https://blog.csdn.net/qq_40369435/article/details/92087995
6.8-讓你實(shí)現(xiàn)一個(gè)RPC框架怎么做
https://itweknow.cn/blog-site/posts/3998282649.html
https://blog.csdn.net/justloveyou_/article/details/79441306
1.網(wǎng)絡(luò)編程 socket
2.java - rmi
6.9-Dubbo的zookeeper注冊(cè)中心中存儲(chǔ)了什么內(nèi)容
https://blog.csdn.net/u012988901/article/details/84394168
6.10-Dubbo的降級(jí)，mock
7-MQ（RabbitMQ）
7.1-用MQ有哪些好處，你系統(tǒng)中怎么用的
異步、解耦、削峰
7.2-Rabbitmq的工作過程
消息生產(chǎn)者連接到RabbitMQ Broker，創(chuàng)建connection，開啟channel。
生產(chǎn)者聲明交換機(jī)類型、名稱、是否持久化等。
發(fā)送消息，并指定消息是否持久化等屬性和routing key。
exchange收到消息之后，根據(jù)routing key路由到跟當(dāng)前交換機(jī)綁定的相匹配的隊(duì)列里面。
消費(fèi)者監(jiān)聽接收到消息之后開始業(yè)務(wù)處理，然后發(fā)送一個(gè)ack確認(rèn)告知消息已經(jīng)被消費(fèi)。
RabbitMQ Broker收到ack之后將對(duì)應(yīng)的消息從隊(duì)列里面刪除掉。
7.3-Rabbitmq的exchange類型及特點(diǎn)
Fanout: 該類型不處理路由鍵，會(huì)把所有發(fā)送到交換器的消息路由到所有綁定的隊(duì)列中。優(yōu)點(diǎn)是轉(zhuǎn)發(fā)消息最快，性能最好。
Direct:該類型的交換器將所有發(fā)送到該交換器的消息被轉(zhuǎn)發(fā)到RoutingKey指定的隊(duì)列中，也就是說路由到BindingKey和RoutingKey完全匹配的隊(duì)列中
Topic:該類型的交換器將所有發(fā)送到Topic Exchange的消息被轉(zhuǎn)發(fā)到所有RoutingKey中指定的Topic的隊(duì)列上面。Exchange將RoutingKey和某Topic進(jìn)行模糊匹配，其中“”用來匹配一個(gè)詞，“#”用于匹配一個(gè)或者多個(gè)詞。例如“com.#”能匹配到“com.rabbitmq.oa”和“com.rabbitmq”；而"login."只能匹配到“com.rabbitmq”。
headers: 該類型的交換器不依賴路由規(guī)則來路由消息，而是根據(jù)消息內(nèi)容中的headers屬性進(jìn)行匹配。headers類型交換器性能差，在實(shí)際中并不常用。
7.4-Rabbitmq怎么進(jìn)行順序消費(fèi)
RabbitMq
保證順序消費(fèi)：順序消息扔到一個(gè)queue，一個(gè)消費(fèi)者進(jìn)行消費(fèi)
Kafka保證順序：
Kafka一個(gè)partition只能對(duì)應(yīng)一個(gè)消費(fèi)者
設(shè)定一個(gè)只有一個(gè)partition的topic
需要順序消費(fèi)的數(shù)據(jù)設(shè)定相同的topic，進(jìn)入到同一個(gè)partiton中
重點(diǎn)就是順序操作要放到一個(gè)隊(duì)列或者線程隊(duì)列中
7.6-Rabbitmq的可靠性消息投遞（怎么保證消息不丟失）
http://m.itdecent.cn/p/2c5eebfd0e95
https://blog.csdn.net/u012211603/article/details/85707760
7.7-Rabbitmq的消息什么時(shí)候會(huì)成為死信
1.消息被拒絕 (basic.reject / basic.nack) 并且 reQueue=false 2.消息 TTL 過期 3.隊(duì)列達(dá)到最大長(zhǎng)度了
7.8-Rabbitmq怎么實(shí)現(xiàn)延遲隊(duì)列
1.死信隊(duì)列，創(chuàng)建兩個(gè)隊(duì)列，一個(gè)隊(duì)列設(shè)置超時(shí)后路由到另一個(gè)隊(duì)列
2.插件
7.9-消費(fèi)方掛了，但是沒有進(jìn)行ack會(huì)有問題嗎？（沒有問題，消息會(huì)重回隊(duì)列，然后發(fā)給其他的消費(fèi)方）
7.10-Rabbitmq你們是怎么部署的，單機(jī)還是集群
集群
7.11-Rabbitmq怎么做到消息不重復(fù)消費(fèi)
1.做消息冪等，redis啊，數(shù)據(jù)庫(kù)啊
7.12-其他的mq，kafka，rocketmq用過嗎
- kafka
8-Spring和SpringMVC
8.1-Springmvc的工作過程
8.2-Spring的bean的生命周期
- Bean 容器找到配置文件中 Spring Bean 的定義。
- Bean 容器利用 Java Reflection API 創(chuàng)建一個(gè)Bean的實(shí)例。
- 如果涉及到一些屬性值 利用
set()方法設(shè)置一些屬性值。 - 如果 Bean 實(shí)現(xiàn)了
BeanNameAware接口，調(diào)用setBeanName()方法，傳入Bean的名字。 - 如果 Bean 實(shí)現(xiàn)了
BeanClassLoaderAware接口，調(diào)用setBeanClassLoader()方法，傳入ClassLoader對(duì)象的實(shí)例。 - 與上面的類似，如果實(shí)現(xiàn)了其他
*.Aware接口，就調(diào)用相應(yīng)的方法。 - 如果有和加載這個(gè) Bean 的 Spring 容器相關(guān)的
BeanPostProcessor對(duì)象，執(zhí)行postProcessBeforeInitialization()方法 - 如果Bean實(shí)現(xiàn)了
InitializingBean接口，執(zhí)行afterPropertiesSet()方法。 - 如果 Bean 在配置文件中的定義包含 init-method 屬性，執(zhí)行指定的方法。
- 如果有和加載這個(gè) Bean的 Spring 容器相關(guān)的
BeanPostProcessor對(duì)象，執(zhí)行postProcessAfterInitialization()方法 - 當(dāng)要銷毀 Bean 的時(shí)候，如果 Bean 實(shí)現(xiàn)了
DisposableBean接口，執(zhí)行destroy()方法。 - 當(dāng)要銷毀 Bean 的時(shí)候，如果 Bean 在配置文件中的定義包含 destroy-method 屬性，執(zhí)行指定的方法。
8.3-Beanfactory和factorybean的區(qū)別
https://www.cnblogs.com/aspirant/p/9082858.html
8.4-Spring的IOC，aop，以及是怎么實(shí)現(xiàn)的，jdk動(dòng)態(tài)代理與cglib的區(qū)別，JDK動(dòng)態(tài)代理的原理了解嗎
https://www.zhihu.com/question/23277575/answer/169698662
https://www.cnblogs.com/xdp-gacl/p/4249939.html
反射
動(dòng)態(tài)代理(JDK動(dòng)態(tài)代理，cglib動(dòng)態(tài)代理)
https://www.zhihu.com/question/23641679
https://blog.csdn.net/briblue/article/details/73928350
8.5-Spring的切面有哪些關(guān)鍵內(nèi)容，切點(diǎn)，切面，織入
- 通知（Advice）: AOP 框架中的增強(qiáng)處理。通知描述了切面何時(shí)執(zhí)行以及如何執(zhí)行增強(qiáng)處理。
- 連接點(diǎn)（join point）: 連接點(diǎn)表示應(yīng)用執(zhí)行過程中能夠插入切面的一個(gè)點(diǎn)，這個(gè)點(diǎn)可以是方法的調(diào)用、異常的拋出。在 Spring AOP 中，連接點(diǎn)總是方法的調(diào)用。
- 切點(diǎn)（PointCut）: 可以插入增強(qiáng)處理的連接點(diǎn)。
- 切面（Aspect）: 切面是通知和切點(diǎn)的結(jié)合。
- 引入（Introduction）：引入允許我們向現(xiàn)有的類添加新的方法或者屬性。
- 織入（Weaving）: 將增強(qiáng)處理添加到目標(biāo)對(duì)象中，并創(chuàng)建一個(gè)被增強(qiáng)的對(duì)象，這個(gè)過程就是織入。
8.6-你項(xiàng)目里面mysql的讀寫分離是怎么做的，AOP + 自定義注解 + 實(shí)現(xiàn)AbstractRoutingDataSource
8.7-Spring中的事務(wù)傳播行為
PROPAGATION_REQUIRED--支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就新建一個(gè)事務(wù)。這是最常見的選擇。
PROPAGATION_SUPPORTS--支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就以非事務(wù)方式執(zhí)行。
PROPAGATION_MANDATORY--支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就拋出異常。
PROPAGATION_REQUIRES_NEW--新建事務(wù)，如果當(dāng)前存在事務(wù)，把當(dāng)前事務(wù)掛起。
PROPAGATION_NOT_SUPPORTED--以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。
PROPAGATION_NEVER--以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。
9-Mybatis
9.1-看過mybatis的源碼嗎，知道它的攔截器嗎
https://blog.csdn.net/weixin_39494923/article/details/91534658
分頁(yè)插件
https://www.cnblogs.com/dengpengbo/p/10579631.html
9.2-Mybatis的二級(jí)緩存了解不
https://blog.csdn.net/luanlouis/article/details/41408341
https://www.cnblogs.com/cxuanBlog/p/11324034.html
https://www.cnblogs.com/cxuanBlog/p/11333021.html
[https://blog.csdn.net/Yang_Hui_Liang/article/details/88291752
](https://blog.csdn.net/Yang_Hui_Liang/article/details/88291752
10-SpringBoot
10.1-Springboot有什么好處
https://www.zhihu.com/question/39483566
https://blog.csdn.net/qq_32595453/article/details/81141643
10.2-Springboot自動(dòng)裝配原理
10.3-Springboot的常用注解
10.4-SpringCloud
10.5-Springcloud的常用組件，怎么用的
10.6-Eureka跟zookeeper的區(qū)別
10.7-Hystrix的使用，原理知道嗎
11-網(wǎng)絡(luò)及Http協(xié)議相關(guān)
11.1-http協(xié)議
11.2-https的加密過程原理
11.3- 其他可能被問到的，url從瀏覽器輸入到響應(yīng)的過程，TCP協(xié)議三次握手，四次揮手，TCP和UDP的區(qū)別
12-IO相關(guān)
- BIO、NIO、AIO
- 什么是阻塞，非阻塞，同步，異步
- Reactor模型知道嗎
- Netty用過嗎
- ByteBuffer用過嗎
13-Tomcat
-
Tomcat是什么，對(duì)請(qǐng)求做了什么
-
讓你實(shí)現(xiàn)一個(gè)Tomcat怎么做
14-數(shù)據(jù)結(jié)構(gòu)及算法相關(guān)
- 手寫二叉樹的深度
- 鏈表的元素刪除
- 怎么判斷鏈表有沒有環(huán)
- 鏈表反轉(zhuǎn)
15-設(shè)計(jì)模式
常用的設(shè)計(jì)模式
單例，工廠，代理，策略，模板，觀察者，裝飾，適配器……..
-
程序中有大量的if else配置怎么解決
適配器模式
項(xiàng)目中有用過哪些設(shè)計(jì)模式
16-分布式相關(guān)
-
如何設(shè)計(jì)一個(gè)可以承載高并發(fā)的系統(tǒng)或者接口，要考慮哪些因素？
分布式事務(wù)了解哪些解決方案
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
-
對(duì)微服務(wù)的理解，為什么要做微服務(wù)，微服務(wù)系統(tǒng)會(huì)出現(xiàn)什么問題，怎么解決
-
常用限流算法有哪些
做過系統(tǒng)監(jiān)控嗎
-
分布式系統(tǒng)中日志追蹤
https://www.cnblogs.com/tong-yuan/p/12128796.html
zipkinpinpoint
-
系統(tǒng)怎么做接口防刷
聚安全-美杜莎
圖片驗(yàn)證碼
-
怎么實(shí)現(xiàn)接口的冪等
17-場(chǎng)景問題
- 多個(gè)商戶支付路由，每個(gè)商戶都會(huì)有每天支付總金額，總筆數(shù)限制，怎么進(jìn)行支付路由
- 一共5000個(gè)商品，每個(gè)用戶進(jìn)來會(huì)看到這5000個(gè)商品中的一部分，比如10個(gè)，同一個(gè)人每次進(jìn)來看到的商品不能與之前的重復(fù)，用redis怎么實(shí)現(xiàn)
- 大量的用戶訪問，比如一天好幾百萬的訪問量Redis怎么統(tǒng)計(jì)日活，月活
- 查詢數(shù)據(jù)進(jìn)行redis緩存，每次的查詢條件可能都不一樣，怎么做到盡可能的緩存查詢結(jié)果但是不能重復(fù)緩存……..
- 假如單筆支付限額一萬，但是用戶要支付兩萬塊錢，你的支付系統(tǒng)怎么做
