Java 技術棧

時間 2019-11-12

標籤 java 技術欄目 Java 简体版

原文原文鏈接

朋友圈看到的，轉發一下。html

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
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的實現

1.3 設計模式

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

1.4 正則表達式

4.1 捕獲組和非捕獲組
4.2 貪婪，勉強，獨佔模式

1.5 java內存模型以及垃圾回收算法

5.1 類加載機制，也就是雙親委派模型java
5.2 Java內存分配模型（默認HotSpot）mysql

線程共享的：堆區、永久區線程獨享的：虛擬機棧、本地方法棧、程序計數器git
5.3 內存分配機制：年輕代（Eden區、兩個Survivor區）、年老代、永久代以及他們的分配過程github
5.4 強引用、軟引用、弱引用、虛引用與GCweb
5.5 happens-before規則正則表達式
5.6 指令重排序、內存柵欄redis
5.7 Java 8的內存分代改進算法
5.8 垃圾回收算法：spring

標記-清除（不足之處：效率不高、內存碎片）

複製算法（解決了上述問題，可是內存只能使用一半，針對大部分對象存活時間短的場景，引出了一個默認的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的演進之路

2.7 SpringSecurity、shiro、SSO（單點登陸）

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

2.8 日誌

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

2.9 datasource

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

2.10 HTTPS的實現原理

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

3.1 ZooKeeper源碼

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

3.2 序列化和反序列化框架

2.1 Avro研究
2.2 Thrift研究
2.3 Protobuf研究
2.4 Protostuff研究
2.5 Hessian

3.3 RPC框架dubbo源碼

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

3.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的線程模型，特別是與業務線程以及資源釋放方面的理解

3.5 消息隊列kafka、RocketMQ、Notify、Hermes

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

3.6 數據庫的分庫分表mycat

3.7 NoSql數據庫mongodb

3.8 KV鍵值系統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分片方案

3.9 web服務器tomcat、ngnix的設計原理

9.1 tomcat的總體架構設計
9.2 tomcat對通訊的併發控制
9.3 http請求到達tomcat的整個處理流程

3.10 ELK日誌實時處理查詢系統

10.1 Elasticsearch、Logstash、Kibana

3.11 服務方面

11.1 SOA與微服務
11.2 服務的合併部署、多版本自動快速切換和回滾

詳見基於Java容器的多應用部署技術實踐

11.3 服務的治理：限流、降級

具體見張開濤大神的架構系列

服務限流：令牌桶、漏桶

服務降級、服務的熔斷、服務的隔離：netflix的hystrix組件

11.4 服務的線性擴展

無狀態的服務如何作線性擴展：

如通常的web應用，直接使用硬件或者軟件作負載均衡，簡單的輪訓機制

有狀態服務如何作線性擴展：

如Redis的擴展：一致性hash，遷移工具
11.5 服務鏈路監控和報警：CAT、Dapper、Pinpoint

3.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

3.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 事務的存儲和恢復，集羣是否共享問題調用方建立CompensableTransaction事務，並加入資源
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參與方建立分支的CompensableTransaction事務，並加入資源，而後提交jta事務
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事務進行提交（包含jdbc等XAResource資源的提交），提交成功後再對CompensableTransaction類型事務進行提交，若是jta事務提交失敗，則須要回滾CompensableTransaction類型事務。
13.4.11 CompensableTransaction類型事務的提交就是對CompensableInvocation資源和RPC資源的提交，分別調用每個CompensableInvocation資源的confirm，以及每個RPC資源的提交CompensableInvocation資源的提交
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事務RPC資源的提交（參與方CompensableTransaction事務的提交）
13.4.15 當全部CompensableInvocation資源的confirm執行完畢，開始執行RPC資源的commit，會進行遠程調用，執行遠程provider分支事務的提交，遠程調用過程會傳遞事務id
13.4.16 provider端，根據傳遞過來的事務id找到對應的CompensableTransaction事務，開始執行提交操做，提交操做完成後返回響應結束
13.4.17 協調者收到響應後繼續執行下一個RPC資源的提交，當全部RPC資源也完成相應的提交，則協調者算是完全完成該事務

3.14 一致性算法

14.1 raft（詳見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協議（詳見ZooKeeper的一致性算法賞析）
- 14.2.1 leader選舉過程。要點：對於不一樣狀態下的server的投票的收集，投票是須要選舉出一個包含全部日誌的server來做爲leader
- 14.2.2 leader和follower數據同步過程，全量同步、差別同步、日誌之間的糾正和截斷，來保證和leader之間的一致性。以及follower加入已經完成選舉的系統，此時的同步的要點：阻塞leader處理寫請求，完成日誌之間的差別同步，還要處理現有進行中的請求的同步，完成同步後，解除阻塞。
- 14.2.3 廣播階段，即正常處理客戶端的請求，過半響應便可回覆客戶端。
- 14.2.4 日誌的恢復和持久化。持久化：每隔必定數量的事務日誌持久化一次，leader選舉前持久化一次。恢復：簡單的認爲已寫入日誌的的事務請求都算做已提交的請求（無論以前是否已過半複製），所有執行commit提交。具體的恢復是：先恢復快照日誌，而後再應用相應的事務日誌
14.3 paxos（詳見paxos算法證實過程）
- 14.3.1 paxos的運做過程：
  
  Phase 1: (a) 一個proposer選擇一個編號爲n的議案，向全部的acceptor發送prepare請求
  
  Phase 1: (b) 若是acceptor已經響應的prepare請求中議案編號都比n小，則它承諾再也不響應prepare請求或者accept請求中議案編號小於n的，而且找出已經accept的最大議案的value返回給該proposer。若是已響應的編號比n大，則直接忽略該prepare請求。
  
  Phase 2：(a) 若是proposer收到了過半的acceptors響應，那麼將提出一個議案（n，v）,v就是上述全部acceptor響應中最大accept議案的value，或者是proposer本身的value。而後將該議案發送給全部的acceptor。這個請求叫作accept請求，這一步纔是所謂發送議案請求，而前面的prepare請求更多的是一個構建出最終議案(n,v)的過程。
  
  Phase 2：(b) acceptor接收到編號爲n的議案，若是acceptor尚未對大於n的議案的prepare請求響應過，則acceptor就accept該議案，不然拒絕
- 14.3.2 paxos的證實過程：
  
  1 足夠多的問題
  
  2 acceptor的初始accept
  
  3 P2-對結果要求
  
  4 P2a-對acceptor的accept要求
  
  5 P2b-對proposer提出議案的要求（結果上要求）
  
  6 P2c-對proposer提出議案的要求（作法上要求）
  
  7 引出prepare過程和P1a
  
  8 8 優化prepare
- 14.3.3 base paxos和multi-paxos