JAVA關鍵技術

通用技術方面

MVC

1）概念

MVC是一個架構模式，它分離了表現與交互。它被分爲三個核心部件：模型-model、視圖-view、控制器-controller

2）工做原理

全部的終端用戶請求被髮送到控制器。
控制器依賴請求去選擇加載哪一個模型，並把模型附加到對應的視圖。
附加了模型數據的最終視圖作爲響應發送給終端用戶。

struts2

1）struts2的基本流程

一、客戶端瀏覽器發出HTTP請求。

二、根據web.xml配置，該請求被FilterDispatcher接收。

三、根據struts.xml配置，找到須要調用的Action類和方法， 並經過IoC方式，將值注入給Aciton。

四、Action調用業務邏輯組件處理業務邏輯，這一步包含表單驗證。在Action被調用先後，能夠注入攔截器

五、Action執行完畢，根據struts.xml中的配置找到對應的返回結果result，並跳轉到相應頁面。

六、返回HTTP響應到客戶端瀏覽器。 

 

2）攔截器的做用及常見攔截器

做用：在action執行先後，執行特定模塊。甚至能夠阻止action的執行

框架提供的攔截器：i18n：記錄用戶選擇的區域環境   logger：輸出Action的名字  params：將請求中的參數設置到Action中去。

 

spring

1）IOC概念

將在編譯階段還不能肯定的類的調用關係，放在配置文件中，在執行階段動態調用。

2）AOP概念

默認使用java動態代理實現

3）做用域

1. singleton：單實例
2. prototype：一個bean能夠定義多個實例。
3. request：每次HTTP請求都會建立一個新的Bean。
4. session：一個HTTP Session定義一個Bean。
5. globalSession：同一個全局HTTP Session定義一個Bean。

bean默認的scope屬性是’singleton‘。

4）事務

Spring自己不實現事務，而是爲不一樣的事務API(如JTA, JDBC, Hibernate, JPA, 和JDO)提供了統一的編程模型。

5）Spring 中的設計模式

單例模式：jdbc connectionter

代理模式：AOP

工廠模式：用SpringFactory建立特定的bean

觀察者模式：根據SpringContext的配置方式，決定AOP的模式

hibernate

1）get和load的不一樣

get：若是緩存中沒有，hibernate將會直接訪問數據庫，並初始化一個持久化對象

load：若是緩存中沒有，hibernate將會建立代理對象，只有真正須要使用這個對象的時候，參會從數據庫中加載數據，即延遲加載。

2）save、persist和saveOrUpdate以及update比較

save：只能insert記錄，返回的是Serializable對象

saveOrUpdate：既能insert，也能update

persist：返回的是void

update()和saveOrUpdate()是用來對跨Session的PO進行狀態管理的。

update()方法操做的對象必須是持久化了的對象。也就是說，若是此對象在數據庫中不存在的話，就不能使用update()方法

saveOrUpdate()方法操做的對象既可使持久化了的，也可使沒有持久化的對象。若是是持久化了的對象調用saveOrUpdate()則會  更新數據庫中的對象；若是是未持久化的對象使用此方法,則save到數據庫中。

3）瞬態，遊離態，持久態如何轉換

剛new出一個對象，還未保存到數據庫，是瞬態

調用save()保存進數據庫，就成了持久態（即session緩存中的狀態）

當關閉session後，數據庫中有，session中沒有，叫遊離態

4）Hibernate併發控制

問題：hibernate中的session是線程非安全的，若是多個線程共享將導資源爭用，進而致使髒讀，幻讀等問題

解決方案：設置JDBC事務隔離級別

    Serializable：串行化。隔離級別最高  
    Repeatable Read：可重複讀  
    Read Committed：已提交數據讀  （默認）
    Read Uncommitted：未提交數據讀。隔離級別最差  
    設置鎖：樂觀鎖和悲觀鎖。  
    樂 觀鎖：使用版本號或時間戳來檢測更新丟失

    悲觀鎖：Hibernate老是使用數據庫的鎖定機制，從不在內存中鎖定對象

 

redis/cache

1）虛擬內存

當你的key很小而value很大時,使用VM的效果會比較好

當你的key不小時,能夠考慮將key,value組合成一個新的value.

vm-max-threads這個參數,能夠設置訪問swap文件的線程數,設置最好不要超過機器的核數,若是設置爲0,那麼全部對swap文件的操做都是串行的.可能會形成比較長時間的延遲,可是對數據完整性有很好的保證.

2）分佈式

a)讀寫分離——主從模式

redis支持主從的模式。原則：Master會將數據同步到slave，而slave不會將數據同步到master。Slave啓動時會鏈接master來同步數據。

經過增長Slave DB的數量，讀的性能能夠線性增加。爲了不Master DB的單點故障，集羣通常都會採用兩臺Master DB作雙機熱備，因此整個集羣的讀和寫的可用性都很是高，可是集羣的擴展能力受限於單個節點的存儲能力。

b)數據分片（相似數據庫水平拆分）

分佈式總結：結合上面兩種模型，能夠將每一個master設計成由一個master和多個slave組成的模型。

3）MySQL裏有2000w數據，redis中只存20w的數據，如何保證redis中的數據都是熱點數據

redis 內存數據集大小上升到必定大小的時候，就會施行數據淘汰策略，有如下幾種策略

隨機淘汰

淘汰最少使用的

淘汰過時數據集中最少使用的

淘汰將要過時的

4）redis性能問題

寫內存快照會阻塞主線程，所以master最好不要寫快照

重寫AOF會佔用高內存，且AOF文件過大會影響master重啓和恢復速度，所以maste人最好不要作任何持久化工做，包括內存快照和aof，二用slave執行aof

主從最好在同一局域網內提升主從複製的性能

5）redis適用場景

Redis最適合全部數據in-momory的場景而不是持久化，至關於增強版的memcache

A）會話緩存，例如購物車信息，能夠持久化

B)全頁緩存

C)作隊列使用

D)排行榜和計數器

E)發佈訂閱

6）若是出對列阻塞了怎麼辦

redis分片，縮短單個隊列長度

優化consomer，調查處理慢的緣由

增長consumer（即分佈式的集羣服務器）

容許請求超時 /失敗，作好失敗後處理

作好內存報警和配置好內存回收策略

 

jms，消息隊列

1）特性

異步通訊，鬆耦合的系統集成

websphere MQ是FIFO的，AWS的MQ是random的

 

併發性能

咱們公司面試也常常問這種問題，不少人答很大面的東西，例如JVM調優，負載均衡，可是做爲一個程序員，有誰專門在這方面下過功夫，有的人說作過jvm調優，可是一問細節，又說不上來。
作爲編碼的程序員，更重要的是應用程序的設計，如何寫出高效的sql，如何佔用最小的內存，如何把某些程序在後臺異步操做。面試的時候說一說你平常工做的時候這方面的經驗，也能很好的回答這個問題。     

 

1）性能通用解決方案

前端:異步請求+資源靜態化+cdn
後端:請求隊列（如12306）+輪詢分發+F5負載均衡+共享緩存
數據層:redis緩存+數據分表+寫隊列+存儲過程（減小跟客戶端交互的IO）
存儲:raid陣列+熱備
網絡:dns輪詢+DDOS攻擊防禦

2）數據庫解決方案

最基本的：創建索引

100萬數據：主從數據庫（讀寫分離，主從複製同步），slave上能夠作集羣

1000萬數據：數據庫水平拆分，按uid拆分

注意問題

id使用通用算法集中分配

作好數據庫性能監控

不要用長鏈接，儘可能使用鏈接池。

3）緩存

CND

靜態頁面緩存

動靜分離，圖片，視頻，附件等使用專用服務器

5）前沿解決方案：雲平臺——可伸縮擴展，快速熱部署，內存數據，      

 

12306如何解決併發的

併發性能的問題和緣由

A.帶寬問題 1.5G的帶寬大約支持1萬PV，

B.服務器集羣難以伸縮擴展

C.事務不一致性，12306十分鐘才更新一次餘票，期間已經售出不少。2012年處理能力爲400-500TPS，有效請求卻高於3000QPS

D.計算量巨大：線路多，車次多，車站多，坐席多，票種多，致使10分鐘才能計算完一次餘票

12306雲技術升級 

http://www.csdn.net/article/2015-02-10/2823900

http://storage.it168.com/a2012/0217/1313/000001313424_all.shtml

傳統的解決方案

優化架構

1）利用第三方平臺登陸來緩解併發壓力，例如新浪，騰訊，阿里等

2）第三方售票平臺應該以消息隊列方式，異步地與12306進行集成。 對於登陸的消息隊列，能夠在12306批量受權處理（有點相似數據庫存儲過程，減小與客戶端交互的io損耗）

優化軟件

使用線程池和事件驅動處理尖峯請求，能夠經過下游負載指標反饋來決定上游處理，對於太老的請求，直接拒絕。

使用KV內存數據庫來緩存餘票，只有當數據庫中本車次無票（或者小於n張）纔去同步一次緩存

緩存的更新是基於數據庫餘票數主動觸發，只有當無票（或者低於n張票）才觸發，而不是根據用戶查詢而觸發，所以能夠大幅減小緩存更新頻率

能夠基於查詢結果生成靜態頁面緩存起來，設置失效時間，或者由數據庫餘票出發頁面失效，徹底由CDN或者redis來承擔查詢壓力

加強防做弊機制，在web層對IP作限制，對UID作限制

數據庫層優化

主從數據庫（讀寫分離）

數據庫水平拆分

優化隊列

隊列不能操做鎖

設置隊列等待時間（15分鐘後未處理完的事務直接終止）

設計分佈式隊列（由於排隊的人並不必定買的相同車次，不必跟着人家一塊兒排隊，而是讓相同車次的人排同一個隊列）

 

 

 

Pivotal Gemfire的解決方案：雲

 

2012年，業務複雜：路線多，火車站多，坐席多，票等級多，組合就多。使用不少服務器。

2013年，使用Gemfire集羣進行餘票計算，能夠2分鐘刷新一次餘票數據

2014年，將訂單生成和訂單查詢分庫處理，將查詢的熱點數據放在Gemfire集羣，同時提升了訂單生成和查詢速度

2015年，單獨分出餘票查詢服務器羣（之前是64臺，如今是是幾臺雲服務器搭建的上百部虛擬機，節約成本），並與web服務器集羣，應用服務器集羣一塊兒部署到阿里雲

 

 

併發事務

JVM內存結構，GC算法，性能優化

類的生命週期

1）將.class文件加載到內存，生成Class對象——類加載

2）類鏈接（驗證，準備，解析）

3）初始化：靜態變量賦值

4）使用

5）卸載：垃圾回收

三種類加載器

啓動加載器（jvm），擴展加載器（基礎庫），應用加載器（程序代碼）

加載機制

全盤負責，父類委託，緩存機制

 

JVM內存結構

三大塊：堆，棧，方法區

堆又分爲：年輕代和老年代

年輕代又分爲：Eden，from，to

--------

方法區存儲常量，靜態變量，類信息

棧區：存放臨時變量，方法參數

--------

對象引用判斷

引用技術（新增引用時+1，引用釋放時-1，但互相引用的對象則沒法計算）

可達性分析

GC算法

標記清除算法

複製算法

分代收集算法

對象分配法則（GC優化法則）

1）優先分配在Eden區，若是Eden區沒有足夠的空間時，執行一次Minor GC，Eden採用複製算法收集內存

2）大對象直接進入老年代，避免在年輕代頻繁進行內存拷貝

3）長期存活的對象進入老年代，由於年輕代的對象隨着年齡增長，最終會進入老年代內存區

4）空間分配擔保。每次進行Minor GC時，JVM會計算Survivor區移至老年區的對象的平均大小，若是這個值大於老年區的剩餘值大小則進行一次Full GC

 

 

數據庫性能

存儲過程

執行存儲過程是爲了1）利用服務器每每具備強大的計算能力和速度，2）避免把大量的數據下載到客戶端，減小網絡上的傳輸量，3）只須要一次編譯，4）方便事務處理

觸發器

1）概念

就是一組由特定條件觸發執行的操做語句。

2）分類

行級：每條記錄都觸發

語句級：指定操做以前或以後觸發

3）應用場景

進行安全檢查（例如數據更新前的權限檢查）

數據同步或者備份（主表更新後， 備份表也更新）

生成自定義ID列：第一步建立一個sequence，用來自定義ID格式，第二步在目標表上面建立觸發器，每當插入數據時，就取sequence的next值

記錄用戶操做（工做流系統中的追蹤，審計）

 

 

 

項目方面

IBE流程

Payment流程

單點登陸

數字證書

communicate service

MPO

 

重大故障

寫日誌致使的故障

故障描述：service頻繁time out， 沒法search flight，沒法訂票

問題分析：disk io high utilization, terracotta and JVM reject rejoin,  was server high CPU, MQ and service error log

分析過程：

懷疑WAS 上的IBE和 WMB 上的MQ通訊出故障

MQ connection error and time out， 可能有阻塞，重啓WMB，無效， 2）重啓WAS JVM， 無效，

root cause： 

solution

1.限制層數

2.限制表查詢條件

3.緩存結果