java技術棧
1 java基礎：
1.1 算法
- 1.1 排序算法：直接插入排序、希爾排序、冒泡排序、快速排序、直接選擇排序、堆排序、歸並排序、基數排序
- 1.2 二叉查找樹、紅黑樹、B樹、B+樹、LSM樹（分別有對應的應用，數據庫、HBase）
- 1.3 BitSet解決數據重復和是否存在等問題
1.2 基本
- 2.1 字符串常量池的遷移
- 2.2 字符串KMP算法
- 2.3 equals和hashcode
-
1、equals方法用於比較對象的內容是否相等（覆蓋以后）
2、hashcode方法只有在集合中用到
3、當覆蓋了equals方法時，比較對象是否相等將通過覆蓋后的equals方法進行比較（判斷對象的內容是否相等）。
4、將對象放入到集合中時，首先判斷要放入對象的hashcode值與集合中的任意一個元素的hashcode值是否相等，如果不相等直接將該對象放入集合中。如果hashcode值相等，然后再通過equals方法判斷要放入對象與集合中的任意一個對象是否相等，如果equals判斷不相等，直接將該元素放入到集合中，否則不放入。
5、將元素放入集合的流程圖：
-
- 2.4 泛型、異常、反射
- 2.5 string的hash算法
- 設計高效算法往往需要使用Hash表，O(1)級的查找速度是任何別的算法無法比擬的。
所謂Hash，一般是一個整數，通過某種算法，可以把一個字符串"pack"成一個整數，這個數稱為Hash，當然，一個整數是無法對應一個字符串的。
所以Hash函數是Hash表最核心的部分，對於一個Hash函數，評價其優劣的標准應為隨機性或離散性，即對任意一組標本，進入Hash表每一個單元（cell）之概率的平均程度，因為這個概率越平均，兩個字符串計算出的Hash值相等hash collision的可能越小，數據在表中的分布就越平均，表的空間利用率就越高。
- 設計高效算法往往需要使用Hash表，O(1)級的查找速度是任何別的算法無法比擬的。
- 2.6 hash沖突的解決辦法：拉鏈法
-
拉鏈法
（1）拉鏈法解決沖突的方法
拉鏈法解決沖突的做法是：將所有關鍵字為同義詞的結點鏈接在同一個單鏈表中。若選定的散列表長度為m，則可將散列表定義為一個由m個頭指針組成的指針數 組T[0..m-1]。凡是散列地址為i的結點，均插入到以T[i]為頭指針的單鏈表中。T中各分量的初值均應為空指針。在拉鏈法中，裝填因子α可以大於 1，但一般均取α≤1。
【例】設有 m ＝ 5 ， H(K) ＝ K mod 5 ，關鍵字值序例 5 ， 21 ， 17 ， 9 ， 15 ， 36 ， 41 ， 24 ，按外鏈地址法所建立的哈希表如下圖所示：
（2）拉鏈法的優點
與開放定址法相比，拉鏈法有如下幾個優點：
①拉鏈法處理沖突簡單，且無堆積現象，即非同義詞決不會發生沖突，因此平均查找長度較短；
②由於拉鏈法中各鏈表上的結點空間是動態申請的，故它更適合於造表前無法確定表長的情況；
③開放定址法為減少沖突，要求裝填因子α較小，故當結點規模較大時會浪費很多空間。而拉鏈法中可取α≥1，且結點較大時，拉鏈法中增加的指針域可忽略不計，因此節省空間；
④在用拉鏈法構造的散列表中，刪除結點的操作易於實現。只要簡單地刪去鏈表上相應的結點即可。而對開放地址法構造的散列表，刪除結點不能簡單地將被刪結 點的空間置為空，否則將截斷在它之后填人散列表的同義詞結點的查找路徑。這是因為各種開放地址法中，空地址單元(即開放地址)都是查找失敗的條件。因此在 用開放地址法處理沖突的散列表上執行刪除操作，只能在被刪結點上做刪除標記，而不能真正刪除結點。
（3）拉鏈法的缺點
拉鏈法的缺點是：指針需要額外的空間，故當結點規模較小時，開放定址法較為節省空間，而若將節省的指針空間用來擴大散列表的規模，可使裝填因子變小，這又減少了開放定址法中的沖突，從而提高平均查找速度。
-
- 2.7 foreach循環的原理
-
- 對於list編譯器會調用Iterable接口的 iterator方法來循環遍歷數組的元素，iterator方法中是調用Iterator接口的的 next()和hasNext（）方法來做循環遍歷。java中有一個叫做迭代器模式的設計模式，這個其實就是對迭代器模式的一個實現。
- 對於數組，就是轉化為對數組中的每一個元素的循環引用
-
- 2.8 static、final、transient等關鍵字的作用
-
static 和final
static 靜態修飾關鍵字，可以修飾 變量，程序塊，類的方法；
當你定義一個static的變量的時候jvm會將將其分配在內存堆上，所有程序對它的引用都會指向這一個地址而不會重新分配內存；
修飾一個程序塊的時候(也就是直接將代碼寫在static{...}中)時候，虛擬機就會優先加載靜態塊中代碼，這主要用於系統初始化；
當修飾一個類方法時候你就可以直接通過類來調用而不需要新建對象。
final 只能賦值一次；修飾變量、方法及類，
當你定義一個final變量時，jvm會將其分配到常量池中，程序不可改變其值；當你定義一個方法時，改方法在子類中將不能被重寫；當你修飾一個類時，該類不能被繼承。
static和final使用范圍：類、方法、變量。
2.區別和聯系：
2.1.static 含義：靜態的，被 static 修飾的方法和屬性只屬於類不屬於類的任何對象。
2.2.static 用法：
2.2.1.static 可以修飾【內部類】、方法和成員變量。
2.2.2.static【不可以修飾外部類】、【不可以修飾局部變量】（因為 static 本身就是定義為類級別的，所以局部級別的變量是不可以用 static 修飾的）。
2.3 final 含義：【只能賦值一次】的。
2.2.final 用法：
2.2.1.final 修飾屬性，表示屬性【只能賦值一次】，（1）基本類型：值不能被修改；（2）引用類型：引用不可以被修改該。
2.2.2.final 修飾方法，表示方法不可以重寫，但是可以被子類訪問（如果方法不是 private 類型話）。
2.2.2.final 修飾類，表示類不可以被繼承。
3.聯合使用 static final3.1.適用范圍：
3.1.2.兩者范圍的交集，所以只能修飾：成員變量、方法、內部類。
3.2.含義：也是二者交集：
3.2.1.方法：屬於類的方法且不可以被重寫。
3.2.2.成員變量：屬於類的變量且只能賦值一次。
3.2.3.內部類：屬於外部類，且不能被繼承
transient
類型修飾符，只能用來修飾字段，如果用transient聲明一個實例變量，當對象存儲時，它的值不需要維持。換句話來說就是，用transient關鍵字標記的成員變量不參與序列化過程。
-
- 2.9 volatile關鍵字的底層實現原理
-
volatile
volatile也是變量修飾符，只能用來修飾變量。volatile修飾的成員變量在每次被線程訪問時，都強迫從共享內存中重讀該成員變量的值。而且，當成員變量發生變化時，強迫線程將變化值回寫到共享內存。這樣在任何時刻，兩個不同的線程總是看到某個成員變量的同一個值。在此解釋一下Java的內存機制：
Java使用一個主內存來保存變量當前值，而每個線程則有其獨立的工作內存。線程訪問變量的時候會將變量的值拷貝到自己的工作內存中，這樣，當線程對自己工作內存中的變量進行操作之后，就造成了工作內存中的變量拷貝的值與主內存中的變量值不同。
Java語言規范中指出：為了獲得最佳速度，允許線程保存共享成員變量的私有拷貝，而且只當線程進入或者離開同步代碼塊時才與共享成員變量的原始值對比。
這樣當多個線程同時與某個對象交互時，就必須要注意到要讓線程及時的得到共享成員變量的變化。
而volatile關鍵字就是提示VM：對於這個成員變量不能保存它的私有拷貝，而應直接與共享成員變量交互。
使用建議：在兩個或者更多的線程訪問的成員變量上使用volatile。當要訪問的變量已在synchronized代碼塊中，或者為常量時，不必使用。
由於使用volatile屏蔽掉了VM中必要的代碼優化，所以在效率上比較低，因此一定在必要時才使用此關鍵字。
-
- 2.10 Collections.sort方法使用的是哪種排序方法
-
Collections是個服務於Collection的工具類（靜態的），它里面定義了一些集合可以用到的方法。
本文演示了Collections類里sort()的兩個方法。第一種只需傳入被排序的集合，便會為它自然排序。但有時我們需要自定義排序的方式，這是我們就得定義一個比較器，里面定義我們要排序的方式，調用sort()時，把被排序的集合和比較器同時傳入，就可以按照自定義的方式排序了。
-
- 2.11 Future接口，常見的線程池中的FutureTask實現等
- 2.12 string的intern方法的內部細節，jdk1.6和jdk1.7的變化以及內部cpp代碼StringTable的實現
1.3 設計模式
- 單例模式
- 工廠模式
- 裝飾者模式
- 觀察者設計模式
- ThreadLocal設計模式
- 。。。
1.4 正則表達式
- 4.1 捕獲組和非捕獲組
- http://www.360doc.com/content/12/0123/05/820209_181153675.shtml
- 4.2 貪婪，勉強，獨占模式
-
正則表達式中匹配的三種量詞：貪婪(Greedy)、勉強(Reluctant)、獨占(Possessive)
貪婪 非貪婪(?) 獨占(+)
X? X?? X?+
X* X*? X*+
X+ X+? X++
X{n} X{n}? X{n}+
X{n,} X{n,}? X{n,}+
X{n,m} X{n,m}? X{n,m}+Greedy：貪婪
匹配最長。在貪婪量詞模式下，正則表達式會盡可能長地去匹配符合規則的字符串，且會回溯。Reluctant ：非貪婪
匹配最短。在非貪婪量詞模式下，正則表達式會匹配盡可能短的字符串。Possessive ：獨占
同貪婪一樣匹配最長。不過在獨占量詞模式下，正則表達式盡可能長地去匹配字符串，一旦匹配不成功就會結束匹配而不會回溯。
-
1.5 java內存模型以及垃圾回收算法
-
5.1 類加載機制，也就是雙親委派模型
- 見JVM P229
-
5.2 java內存分配模型（默認HotSpot）
線程共享的：堆區、永久區 線程獨享的：虛擬機棧、本地方法棧、程序計數器
-
5.3 內存分配機制：年輕代（Eden區、兩個Survivor區）、年老代、永久代以及他們的分配過程
-
5.4 強引用、軟引用、弱引用、虛引用與GC
-
5.5 happens-before規則
-
5.6 指令重排序、內存柵欄
-
5.7 Java 8的內存分代改進
-
5.8 垃圾回收算法：
標記-清除（不足之處：效率不高、內存碎片）
復制算法（解決了上述問題，但是內存只能使用一半，針對大部分對象存活時間短的場景，引出了一個默認的8:1:1的改進，缺點是仍然需要借助外界來解決可能承載不下的問題）
標記整理
-
5.8 常用垃圾收集器：
新生代：Serial收集器、ParNew收集器、Parallel Scavenge 收集器
老年代：Serial Old收集器、Parallel Old收集器、CMS（Concurrent Mark Sweep）收集器、 G1 收集器（跨新生代和老年代）
-
5.9 常用gc的參數：-Xmn、-Xms、-Xmx、-XX:MaxPermSize、-XX:SurvivorRatio、-XX:-PrintGCDetails
-
5.10 常用工具： jps、jstat、jmap、jstack、圖形工具jConsole、Visual VM、MAT
1.6 鎖以及並發容器的源碼
- 6.1 synchronized和volatile理解
- 6.2 Unsafe類的原理，使用它來實現CAS。因此誕生了AtomicInteger系列等
- 6.3 CAS可能產生的ABA問題的解決，如加入修改次數、版本號
- 6.4 同步器AQS的實現原理
- 6.5 獨占鎖、共享鎖；可重入的獨占鎖ReentrantLock、共享鎖 實現原理
- 6.6 公平鎖和非公平鎖
- 6.7 讀寫鎖 ReentrantReadWriteLock的實現原理
- 6.8 LockSupport工具
- 6.9 Condition接口及其實現原理
- 6.10 HashMap、HashSet、ArrayList、LinkedList、HashTable、ConcurrentHashMap、TreeMap的實現原理
- 6.11 HashMap的並發問題
- 6.12 ConcurrentLinkedQueue的實現原理
- 6.13 Fork/Join框架
- 6.14 CountDownLatch和CyclicBarrier
1.7 線程池源碼
- 7.1 內部執行原理
- 7.2 各種線程池的區別
2 web方面：
2.1 SpringMVC的架構設計
- 1.1 servlet開發存在的問題：映射問題、參數獲取問題、格式化轉換問題、返回值處理問題、視圖渲染問題
- 1.2 SpringMVC為解決上述問題開發的幾大組件及接口：HandlerMapping、HandlerAdapter、HandlerMethodArgumentResolver、HttpMessageConverter、Converter、GenericConverter、HandlerMethodReturnValueHandler、ViewResolver、MultipartResolver
- 1.3 DispatcherServlet、容器、組件三者之間的關系
- 1.4 敘述SpringMVC對請求的整體處理流程
- 1.5 SpringBoot
2.2 SpringAOP源碼
-
2.1 AOP的實現分類：編譯期、字節碼加載前、字節碼加載后三種時機來實現AOP
-
2.2 深刻理解其中的角色：AOP聯盟、aspectj、jboss AOP、Spring自身實現的AOP、Spring嵌入aspectj。特別是能用代碼區分后兩者
-
2.3 接口設計：
AOP聯盟定義的概念或接口：Pointcut（概念，沒有定義對應的接口）、Joinpoint、Advice、MethodInterceptor、MethodInvocation
SpringAOP針對上述Advice接口定義的接口及其實現類：BeforeAdvice、AfterAdvice、MethodBeforeAdvice、AfterReturningAdvice；針對aspectj對上述接口的實現AspectJMethodBeforeAdvice、AspectJAfterReturningAdvice、AspectJAfterThrowingAdvice、AspectJAfterAdvice。
SpringAOP定義的定義的AdvisorAdapter接口：將上述Advise轉化為MethodInterceptor
SpringAOP定義的Pointcut接口：含有兩個屬性ClassFilter（過濾類）、MethodMatcher（過濾方法）
SpringAOP定義的ExpressionPointcut接口：實現中會引入aspectj的pointcut表達式
SpringAOP定義的PointcutAdvisor接口（將上述Advice接口和Pointcut接口結合起來）
-
2.4 SpringAOP的調用流程
-
2.5 SpringAOP自己的實現方式（代表人物ProxyFactoryBean）和借助aspectj實現方式區分
2.3 Spring事務體系源碼以及分布式事務Jotm Atomikos源碼實現
- 3.1 jdbc事務存在的問題
- 3.2 Hibernate對事務的改進
- 3.3 針對各種各樣的事務，Spring如何定義事務體系的接口，以及如何融合jdbc事務和Hibernate事務的
- 3.4 三種事務模型包含的角色以及各自的職責
- 3.5 事務代碼也業務代碼分離的實現（AOP+ThreadLocal來實現）
- 3.6 Spring事務攔截器TransactionInterceptor全景
- 3.7 X/Open DTP模型，兩階段提交，JTA接口定義
- 3.8 Jotm、Atomikos的實現原理
- 3.9 事務的傳播屬性
- 3.10 PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED的實現原理以及區別
- 3.11 事物的掛起和恢復的原理
2.4 數據庫隔離級別
- 4.1 Read uncommitted：讀未提交
- 4.2 Read committed ： 讀已提交
- 4.3 Repeatable read：可重復讀
- 4.4 Serializable ：串行化
2.5 數據庫
-
5.1 數據庫性能的優化
-
5.2 深入理解mysql的Record Locks、Gap Locks、Next-Key Locks
例如下面的在什么情況下會出現死鎖：
start transaction; DELETE FROM t WHERE id =6; INSERT INTO t VALUES(6); commit;
-
5.3 insert into select語句的加鎖情況
-
5.4 事務的ACID特性概念
-
5.5 innodb的MVCC理解
-
5.6 undo redo binlog
- 1 undo redo 都可以實現持久化，他們的流程是什么？為什么選用redo來做持久化？
- 2 undo、redo結合起來實現原子性和持久化，為什么undo log要先於redo log持久化？
- 3 undo為什么要依賴redo？
- 4 日志內容可以是物理日志，也可以是邏輯日志？他們各自的優點和缺點是？
- 5 redo log最終采用的是物理日志加邏輯日志，物理到page，page內邏輯。還存在什么問題？怎么解決？Double Write
- 6 undo log為什么不采用物理日志而采用邏輯日志？
- 7 為什么要引入Checkpoint？
- 8 引入Checkpoint后為了保證一致性需要阻塞用戶操作一段時間，怎么解決這個問題？（這個問題還是很有普遍性的，redis、ZooKeeper都有類似的情況以及不同的應對策略）又有了同步Checkpoint和異步Checkpoint
- 9 開啟binlog的情況下，事務內部2PC的一般過程（含有2次持久化，redo log和binlog的持久化）
- 10 解釋上述過程，為什么binlog的持久化要在redo log之后，在存儲引擎commit之前？
- 11 為什么要保持事務之間寫入binlog和執行存儲引擎commit操作的順序性？（即先寫入binlog日志的事務一定先commit）
- 12 為了保證上述順序性，之前的辦法是加鎖prepare_commit_mutex，但是這極大的降低了事務的效率，怎么來實現binlog的group commit？
- 13 怎么將redo log的持久化也實現group commit？至此事務內部2PC的過程，2次持久化的操作都可以group commit了，極大提高了效率
2.6 ORM框架: mybatis、Hibernate
- 6.1 最原始的jdbc->Spring的JdbcTemplate->hibernate->JPA->SpringDataJPA的演進之路