java技術棧

1 java基礎：
1 算法
1.1 排序算法：直接插入排序、希爾排序、冒泡排序、快速排序、直接選擇排序、堆排序、歸併排序、基數排序
1.2 二叉查找樹、紅黑樹、B樹、B+樹
1.3 BitSet解決數據重複和是否存在等問題

2 基本
2.1 字符串常量池的遷移
jdk1.6,string in PermGen永久代，方法區，在運行時大小不可擴展，
jdk1.7,string in heap,-XX:StringTableSize=1009(default),WeakHashMap<String, WeakReference<String>> 
jdk1.8,string in heap,default table size 25-50K
2.2 字符串KMP算法
2.3 equals和hashcode
2.4 泛型、異常、反射
2.5 string的hash算法
2.6 hash衝突的解決辦法：開放定址法和拉鍊法
2.7 foreach循環的原理
2.8 static、final、transient等關鍵字的做用
2.9 volatile關鍵字的底層實現原理
2.10 Collections.sort方法使用的是哪一種排序方法
2.11 Future接口，常見的線程池中的FutureTask實現等
2.12 string的intern方法的內部細節，jdk1.6和jdk1.7的變化以及內部cpp代碼StringTable的實現

3 設計模式
單例模式
工廠模式
裝飾者模式
觀察者設計模式
ThreadLocal設計模式

4 正則表達式
4.1 捕獲組和非捕獲組
4.2 貪婪，勉強，獨佔模式

5 java內存模型以及垃圾回收算法
5.1 類加載機制，也就是雙親委派模型
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

6 鎖以及併發容器的源碼
6.1 synchronized和volatile理解
6.2 Unsafe類的原理，使用它來實現CAS。所以誕生了AtomicInteger系列等
6.3 CAS可能產生的ABA問題的解決，如加入修改次數、版本號
6.4 同步器AQS的實現原理
AQS的核心思想是基於volatile int state這樣的volatile變量，配合Unsafe工具對其原子性的操做來實現對當前鎖狀態進行修改。同步器內部依賴一個FIFO的雙向隊列來完成資源獲取線程的排隊工做。同步器主要使用方式是繼承，子類經過繼承同步器並實現它的抽象方法來管理同步狀態，對同步狀態的修改或者訪問主要經過同步器提供的3個方法：
getState() 獲取當前的同步狀態
setState(int newState) 設置當前同步狀態
compareAndSetState(int expect,int update) 使用CAS設置當前狀態，該方法可以保證狀態設置的原子性。
同步器能夠支持獨佔式的獲取同步狀態，也能夠支持共享式的獲取同步狀態，這樣能夠方便實現不一樣類型的同步組件。
同步器也是實現鎖的關鍵，在鎖的實現中聚合同步器，利用同步器實現鎖的語義。
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

7 線程池源碼
7.1 內部執行原理
7.2 各類線程池的區別

2 web方面：

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 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實現方式區分

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 事物的掛起和恢復的原理

4 數據庫隔離級別
4.1 Read uncommitted：讀未提交
4.2 Read committed ： 讀已提交
4.3 Repeatable read：可重複讀
4.4 Serializable ：串行化

5 sql
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理解

6 ORM框架: mybatis、Hibernate
6.1 最原始的jdbc->Spring的JdbcTemplate->hibernate->JPA->SpringDataJPA的演進之路

7 SpringSecurity、shiro、SSO（單點登陸）
7.1 Session和Cookie的區別和聯繫以及Session的實現原理
7.2 SpringSecurity的認證過程以及與Session的關係
7.3 CAS實現SSO（詳見Cas（01）——簡介）

8 日誌
8.1 jdk自帶的logging、log4j、log4j二、logback
8.2 門面commons-logging、slf4j
8.3 上述6種混戰時的日誌轉換

9 datasource
9.1 c3p0
9.2 druid
9.3 JdbcTemplate執行sql語句的過程當中對Connection的使用和管理

10 HTTPS的實現原理

3 分佈式、java中間件、web服務器等方面：

1 ZooKeeper源碼
1.1 客戶端架構
1.2 服務器端單機版和集羣版，對應的請求處理器
1.3 集羣版session的創建和激活過程
1.4 Leader選舉過程
1.5 事務日誌和快照文件的詳細解析
1.6 實現分佈式鎖、分佈式ID分發器
1.7 實現Leader選舉

2 序列化和反序列化框架Avro、Thrift、Protobuf、Protostuff
2.1 Avro研究
2.2 Thrift研究
2.3 Protobuf研究
2.4 Protostuff研究

3 RPC框架dubbo源碼
3.1 dubbo擴展機制的實現，對比SPI機制
3.2 服務的發佈過程
3.3 服務的訂閱過程
3.4 RPC通訊的設計

4 NIO模塊以及對應的Netty和Mina、thrift源碼
4.1 TCP握手和斷開及有限狀態機
4.2 backlog
4.3 BIO NIO
4.4 阻塞/非阻塞的區別、同步/異步的區別
4.5 阻塞IO、非阻塞IO、多路複用IO、異步IO
4.6 Reactor線程模型
4.7 jdk的poll、epoll與底層poll、epoll的對接實現
4.8 Netty本身的epoll實現
4.9 內核層poll、epoll的大體實現
4.10 epoll的邊緣觸發和水平觸發
4.11 Netty的EventLoopGroup設計
4.12 Netty的ByteBuf設計
4.13 Netty的ChannelHandler
4.13 Netty的零拷貝
4.14 Netty的線程模型，特別是與業務線程以及資源釋放方面的理解

5 消息隊列kafka、MetaQ（後來版本RocketMQ）、Notify、Hermes
5.1 kafka的文件存儲設計
5.2 kafka的高可用設計
5.3 kafka自己作的很輕量級來保持高效，不少高級特性沒有：事務、優先級的消息、消息的過濾，更重要的是服務治理不健全，一旦出問題，不能直觀反應出來，不太適合對數據要求十分嚴苛的企業級系統，而適合日誌之類併發量大可是容許少許的丟失或重複等場景
5.4 Notify的事務設計
5.5 基於文件的kafka、metaq和基於數據庫的Notify和Hermes
5.6 設計一個消息系統要考慮哪些方面

6 數據庫的分庫分表mycat

7 NoSql數據庫mongodb

8 分佈式緩存 memcached redis
8.1 redis對客戶端的維護和管理，讀寫緩衝區
8.2 redis事務的實現
8.3 Jedis客戶端的實現
8.4 JedisPool以及ShardedJedisPool的實現
8.5 redis epoll實現，循環中的文件事件和時間事件
8.6 redis的RDB持久化，save和bgsave
8.7 redis AOF命令追加、文件寫入、文件同步到磁盤
8.8 redis AOF重寫，爲了減小阻塞時間採起的措施
8.9 redis的LRU內存回收算法
8.10 redis的master slave複製
8.11 redis的sentinel高可用方案
8.12 redis的cluster分片方案

9 web服務器tomcat、ngnix的設計原理
9.1 tomcat的總體架構設計
9.2 tomcat對通訊的併發控制
9.3 http請求到達tomcat的整個處理流程

10 ELK日誌實時處理查詢系統
Elasticsearch、Logstash、Kibana

11 擴展
11.1 SOA與微服務
11.2 服務的合併部署、多版本自動快速切換和回滾
詳見基於Java容器的多應用部署技術實踐
11.3 服務的治理：限流、降級
具體見 張開濤大神的架構系列
服務限流：令牌桶、漏桶
服務降級、服務的熔斷、服務的隔離：netflix的hystrix組件
11.4 服務的線性擴展
無狀態的服務如何作線性擴展：
如通常的web應用，直接使用硬件或者軟件作負載均衡，簡單的輪訓機制
有狀態服務如何作線性擴展：
如Redis的擴展：一致性hash，遷移工具
11.5 服務鏈路監控和報警：CAT、Dapper、Pinpoint

12 Spring Cloud
12.1 Spring Cloud Zookeeper:用於服務註冊和發現
12.2 Spring Cloud Config:分佈式配置
12.2 Spring Cloud Netflix Eureka：用於rest服務的註冊和發現
12.3 Spring Cloud Netflix Hystrix：服務的隔離、熔斷和降級
12.4 Spring Cloud Netflix Zuul:動態路由，API Gateway

13 分佈式事務
13.1 JTA分佈式事務接口定義，對此與Spring事務體系的整合
13.2 TCC分佈式事務概念
13.3 TCC分佈式事務實現框架案例1：tcc-transaction
13.3.1 TccCompensableAspect切面攔截建立ROOT事務
13.3.2 TccTransactionContextAspect切面使遠程RPC調用資源加入到上述事務中，做爲一個參與者
13.3.3 TccCompensableAspect切面根據遠程RPC傳遞的TransactionContext的標記建立出分支事務
13.3.4 所有RPC調用完畢，ROOT事務開始提交或者回滾，執行全部參與者的提交或回滾
13.3.5 全部參與者的提交或者回滾，仍是經過遠程RPC調用，provider端開始執行對應分支事務的confirm或者cancel方法
13.3.6 事務的存儲，集羣共享問題
13.3.7 事務的恢復，避免集羣重複恢復
13.4 TCC分佈式事務實現框架案例2：ByteTCC
13.4.1 JTA事務管理實現，類比Jotm、Atomikos等JTA實現
13.4.2 事務的存儲和恢復，集羣是否共享問題
13.4.3 CompensableMethodInterceptor攔截器向spring事務注入CompensableInvocation資源
13.4.4 Spring的分佈式事務管理器建立做爲協調者CompensableTransaction類型事務，和當前線程進行綁定，同時建立一個jta事務
13.4.5 在執行sql等操做的時候，所使用的jdbc等XAResource資源加入上述jta事務
13.4.6 dubbo RPC遠程調用前，CompensableDubboServiceFilter建立出一個代理XAResource，加入上述CompensableTransaction類型事務，並在RPC調用過程傳遞TransactionContext
13.4.7 RPC遠程調用來到provider端，CompensableDubboServiceFilter根據傳遞過來的TransactionContext建立出對應的CompensableTransaction類型事務
13.4.8 provider端，執行時碰見@Transactional和@Compensable，做爲一個參與者開啓try階段的事務，即建立了一個jta事務
13.4.9 provider端try執行完畢開始準備try的提交，僅僅是提交上述jta事務，返回結果到RPC調用端
13.4.10 所有執行完畢後開始事務的提交或者回滾，先對jta事務進行提交，提交成功後再對CompensableTransaction類型事務進行提交，若是jta事務提交失敗，則須要回滾CompensableTransaction類型事務。
13.4.11 CompensableTransaction類型事務的提交就是對CompensableInvocation資源和RPC資源的提交，分別調用每個CompensableInvocation資源的confirm，以及每個RPC資源的提交
13.4.12 此時每個CompensableInvocation資源的confirm又會準備開啓一個新的事務，當前線程的CompensableTransaction類型事務，因此這裏開啓事務僅僅是建立了一個新的jta事務而已
13.4.13 針對此，每個CompensableInvocation資源的confirm開啓的事務，又開始重複上述過程，對於jdbc等資源都加入新建立的jta事務中，而RPC資源和CompensableInvocation資源仍然加入到當前線程綁定的CompensableTransaction類型事務
13.4.14 當前CompensableInvocation資源的confirm開啓的事務執行完畢後，開始執行commit,此時仍然是執行jta事務的提交，提交完畢，一個CompensableInvocation資源的confirm完成，繼續執行下一個CompensableInvocation資源的confirm，即又要從新開啓一個新的jta事務
13.4.15 當全部CompensableInvocation資源的confirm執行完畢，開始執行RPC資源的commit，會進行遠程調用，執行遠程provider分支事務的提交，遠程調用過程會傳遞事務id
13.4.16 provider端，根據傳遞過來的事務id找到對應的CompensableTransaction事務，開始執行提交操做，提交操做完成後返回響應
13.4.17 協調者收到響應後繼續執行下一個RPC資源的提交，當全部RPC資源也完成相應的提交，則協調者算是完全完成該事務

14 一致性算法
14.1 raft
14.1.1 leader選舉過程，leader選舉約束，要包含全部commited entries，實現上log比過半的log都最新便可
14.1.2 log複製過程，leader給全部的follower發送AppendEntries RPC請求，過半follower回覆ok，則可提交該entry，而後向客戶端響應OK
14.1.3 在上述leader收到過半複製以後，掛了，則後續leader不能直接對這些以前term的過半entry進行提交（這一部分有詳細的案例來證實，並能說出根本緣由），目前作法是在當前term中建立空的entry，而後若是這些新建立的entry被大部分複製了，則此時就能夠對以前term的過半entry進行提交了
14.1.4 leader一旦認爲某個term能夠提交了，則更新本身的commitIndex，同時應用entry到狀態機中，而後在下一次與follower的heartbeat通訊中，將leader的commitIndex帶給follower，讓他們進行更新，同時應用entry到他們的狀態機中
14.1.5 從上述流程能夠看到，做爲client來講，可能會出現這樣的狀況：leader認爲某次client的請求能夠提交了（對應的entry已經被過半複製了），此時leader掛了，還沒來得及給client回覆，也就是說對client來講，請求雖然失敗了，可是請求對應的entry卻被持久化保存了，可是有的時候倒是請求失敗了（過半都沒複製成功）沒有持久化成功，也就是說請求失敗了，服務器端可能成功了也可能失敗了。因此這時候須要在client端下功夫，即cleint端重試的時候仍然使用以前的請求數據進行重試，而不是採用新的數據進行重試，服務器端也必需要實現冪等。
14.1.6 Cluster membership changes
14.2 ZooKeeper使用的ZAB協議

4 大數據方向

1 Hadoop
1.1 UserGroupInformation源碼解讀：JAAS認證、user和group關係的維護
1.2 RPC通訊的實現
1.3 代理用戶的過程
1.4 kerberos認證

2 MapReduce
2.1 MapReduce理論及其對應的接口定義

3 HDFS
3.1 MapFile、SequenceFile
3.2 ACL
4 YARN、Mesos 資源調度

5 oozie
5.1 oozie XCommand設計
5.2 DagEngine的實現原理

6 Hive
6.1 HiveServer二、metatore的thrift RPC通訊設計
6.2 Hive的優化過程
6.3 HiveServer2的認證和受權
6.4 metastore的認證和受權
6.5 HiveServer2向metatore的用戶傳遞過程

7 Hbase
7.1 Hbase的總體架構圖
7.2 Hbase的WAL和MVCC設計
7.3 client端的異步批量flush尋找RegionServer的過程
7.4 Zookeeper上HBase節點解釋
7.5 Hbase中的mini、major合併
7.6 Region的高可用問題對比kafka分區的高可用實現
7.7 RegionServer RPC調用的隔離問題
7.8 數據從內存刷寫到HDFS的粒度問題
7.9 rowKey的設計
7.10 MemStore與LSM
8 Spark

8.1 不一樣的部署方式
8.2 SparkSql的實現方式
8.3 。。。