Java面試題-實用技術

文件上傳和下載如何實現?

數據較大時必須用文件上傳，文件上傳的本質是IO流的從操做；
客戶端：
1）必須使用post，post才能攜帶大數據
2）必須設置type=「file」 name=「f」必需要有名字；
3）必需要設置enctype=「multlpart/form-data」
服務器端：
1）經過request.getInputStream()獲取字節輸入流讀取請求正文內容;
將上傳內容獲得,保存在服務器端,就完成了文件上傳;
2）實際使用直接用框架中的api就能夠,commons-fileupload是apache提供的一套文件上傳工具;
文件上傳實現:
導入commons-io包和commons-fileupload包;放在WEB_INF下的lib文件夾下。
文件下載有兩種方法:
1.超連接下載:若是文件能被瀏覽器解析，點擊就會打開文件，若是要下載，須要使用右鍵另存爲，不能被瀏覽器解析的文件，點擊就下載;
⒉.經過服務器流回寫到瀏覽器下載;要設置MIME，即設置setcontentType(String mimeType);瀏覽器能解析的直接顯示，不能解析的直接下載;
獲取文件的mimeType類型: String mimeType=this.getServletContext().getMimeType(filename);
若是設置響應頭respponse.setHeader("content-disposition","attachment;flename=下載的文件名稱");無論瀏覽器能不能解析，都是下載操做;

第三方的工做流有哪些?如何使用?

Activiti和JBPM:
JBPM5(Java Business Process Management)和Activiti都支持BPMN2.0規範。
jBPM5推翻了jBPM3和jBPM4的架構,使用了Drools Flow做爲工做流的架構，而Activiti更像是jBPM4的延續。
jBPM5採用LGPL開源協議（若是修改LGPL協議的代碼或者衍生，則全部修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議，因 此LGPL協議的開源 代碼很適合做爲第三方類庫被商業軟件引用，但不適合但願以LGPL協議代碼爲基礎，經過修改和衍生的方式作二次開發的商業軟件採用）;
Activiti採用寬鬆的Apache License2.0協議（鼓勵代碼共享並尊重原做者的著做權，容許對代碼進行修改和發佈而無論其用途）。
Git工做流：
Workflow.Net、NetBpm、OSWorkflow

對activemq、rabbitmq、kafuka的瞭解和使用？消息發送失敗如何處理？如何預防消息的重複消費？

訂閱方式：
ActiveMQ：點對點(p2p)、廣播（發佈-訂閱）；
RabbitMQ：work queue(工做隊列)、Publish/Subscribe(發佈訂閱模式)、Routing(路由模式)、Topic(通配符模式)、Hreader()、RPC()；
Kafka：點對點(p2p)；
使用：
1）ActiveMQ：
在項目中，咱們使用的是SpringJMS操做activeMQ，已maven操做爲例,首先先引用SpringJMS的依賴 及 activeMQ的依賴，而後在spring的配置中，
若是要配置消息的生產者的話，須要配置springjms的鏈接工廠，經過鏈接工廠配置 jmsTemplate實例，咱們可使用jmsTemplate進行消息的相關操做，另外咱們也須要配置消息的目的地，也是在spring的配置文件中配置配置隊列 或者 主題。
消息的消費者和生產者配置差很少，不一樣的是須要配置一個消息的監聽器，監聽器裏面實現onMessage方法，在這個方法裏面處理消息
2）RabbitMQ：
在咱們秒殺搶購商品的時候，系統會提醒咱們稍等排隊中，而不是像幾年前同樣頁面卡死或報錯給用戶。
像這種排隊結算就用到了消息隊列機制，放入通道里面一個一個結算處理，而不是某個時間斷忽然涌入大批量的查詢新增把數據庫給搞宕機，因此RabbitMQ本質上起到的做用就是削峯填谷，爲業務保駕護航。
服務間異步通訊
順序消費
定時任務
請求削峯
Kafka：
日誌收集：一個公司能夠用Kafka能夠收集各類服務的log，經過kafka以統一接口服務的方式開放給各類consumer，例如hadoop、HBase、Solr等。
消息系統：解耦和生產者和消費者、緩存消息等。
用戶活動跟蹤：Kafka常常被用來記錄web用戶或者app用戶的各類活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發佈到kafka的topic中，而後訂閱者經過訂閱這些topic來作實時的監控分析，或者裝載到hadoop、數據倉庫中作離線分析和挖掘。
運營指標：Kafka也常常用來記錄運營監控數據。包括收集各類分佈式應用的數據，生產各類操做的集中反饋，好比報警和報告。
流式處理：好比spark streaming和 Flink
消息發送失敗如何處理：
1.自動重發
2.系統預警人工處理等

如何防止消息的重複消費：
​ 保證消息的惟一性，就算是屢次傳輸，不要讓消息的屢次消費帶來影響；保證消息等冪性；
​ 好比：在寫入消息隊列的數據作惟一標示，消費消息時，根據惟一標識判斷是否消費過；

svn和git衝突如何解決？

SVN解決衝突有三種選擇：
​A、放棄本身的更新，使用svn revert（回滾），而後提交。在這種方式下不須要使用svn resolved（解決）
B、放棄本身的更新，使用別人的更新。使用最新獲取的版本覆蓋目標文件，執行resolved filename並提交(選擇文件—右鍵—解決)。
C、手動解決：衝突發生時，經過和其餘用戶溝通以後，手動更新目標文件。而後執行resolved filename來解除衝突，最後提交。
Git
1）直接修改文件：
第一步，選擇文件鼠標右擊選擇 Git-commit --提交到本地倉庫
第二部，在文件同級空白處鼠標右擊選擇 tortoisGit --> pull，文件發生改變。
直接修改文件中數據，最後保存文件
第三步，選擇文件鼠標右擊選擇 Git Commit --> 提交 -- >push 發佈。
2）經過edit conflicts修改
選中文件，右擊菜單選項 tortoiseGit --> Edit conflict
修改編輯區：將Theirs- 或者 Local-中須要的數據添加到Meged中。
保存時 標記衝突解決。

如何測試本身的接口？

postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等

poi導入excel時若是數據溢出如何解決？

POI官方推薦解決內存溢出的方式使用CSV格式解析

linux經常使用命令有哪些？

如何調用第三方的接口？

ajax（會出現跨域問題）
from表單（此方法在Android端不適用），form的提交不存的跨域的問題，因此能夠考慮使用form的action方法來解決。）
經過Java代碼調用（Android端適用，導入HttpClientUtil這個工具類，或者也可使用Spring框架的restTemplate來調用，上面有調用接口的方法，分爲Get和Post方式的有參和無參調用）

分佈式、集羣、微服務的理解？

分佈式：一個業務分拆多個子業務，部署在不一樣的服務器上；
集羣：同一個業務，部署在多個服務器上；
微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的，經過接口來實現數據的交互。每一個微服務僅關注於完成一件任務並很好地完成該任務。在全部狀況下，每一個任務表明着一個小的業務能力。
分佈式屬於微服務
分佈式：分佈壓力(集羣)
微服務：分佈能力

事務的特性？分佈式如何保證數據一致性？

ACID
數據的一致性協議有：
​1. 兩階段提交協議 2PC
​2. 三階段提交協議 3PC
​3. RWN協議
​4. raft協議
​5. Paxos協議

分佈式事務的處理邏輯?怎麼實現的?

分佈式事務是將各個模塊都是單獨獨立出來的微服務，進行了分佈式部署，單系統裏的事務將不能保證各個數據庫操做的一致性。
基於XA的兩階段提交方案：

1. XA 它包含兩個部分：事務管理器和本地資源管理器。其中本地資源管理器每每由數據庫實現，而事務管理器做爲全局的協調者，負責各個本地資源的提交和回滾。
2. 兩階段提交方案開發複雜、鎖定資源時間長，對性能影響很大，基本不適合解決微服務事務問題。

TCC解決方案：

1. TCC方案實際上是兩階段提交的一種改進。其將整個業務邏輯的每一個分支顯式的分紅了Try、Confirm、Cancel三個操做。
2. Try 階段主要是對業務系統作檢測及資源預留，完成業務的準備工做。
3. Confirm 階段主要是對業務系統作確認提交，Try階段執行成功並開始執行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm必定成功。
4. Cancel 階段主要是在業務執行錯誤，須要回滾的狀態下執行的業務取消，預留資源釋放。
5. TCC方案中不少事務的處理邏輯須要應用本身編碼實現，複雜且開發量大。

本地消息表（異步確保）

1. 嚴重依賴於數據庫的消息表來管理事務，這樣在高併發的狀況下難以擴展，同時要在數據庫中額外添加一個與實際業務無關的消息表來實現分佈式事務，繁瑣

MQ事務消息：

1. 直接基於 MQ 來實現事務，再也不用本地的消息表。缺點就是實現難度大，並且主流MQ不支持。

LCN分佈式事務框架：

1. 建立事務組：是指在事務發起方開始執行業務代碼以前先調用TxManager建立事務組對象，而後拿到事務標示GroupId的過程。
2. 添加事務組：添加事務組是指參與方在執行完業務方法之後，將該模塊的事務信息添加通知給TxManager的操做。
3. 關閉事務組：是指在發起方執行完業務代碼之後，將發起方執行結果狀態通知給TxManager的動做。當執行完關閉事務組的方法之後，TxManager將根據事務組信息來通知相應的參與模塊提交或回滾事務。
4. 使用：搭建tx-manager服務　　修改application.properties配置文件，提供本地微服務應用的Eureka註冊中心配置、redis配置。配置文件打包,啓動微服務,java -jar tx-manager-x.x.x.jar;成功的話,直接在微服務中使用LCN實現分佈式事務管理~~~~

其中@Transactional用於管理本地事務，而@TxTransaction管理分佈式事務，當須要回滾時，調用本地自帶的事務管理器進行回滾。

docker的經常使用命令有哪些？

模板引擎的瞭解和使用？

模板引擎（這裏特指用於Web開發的模板引擎）是爲了使用戶界面與業務數據（內容）分離而產生的，它能夠生成特定格式的文檔，用於網站的模板引擎就會生成一個標準的HTML文檔。
模板引擎有哪些：jsp、Velocity、FreeMarker、Thymleaf、Beetl、Enjoy。
FreeMarker：
建立Configuration實例,該實例負責管理FreeMarker的模板加載路徑,負責生成模板實例；
使用Configuration實例來生成Template實例,同進須要指定使用的模板文件；
填充數據模型,數據模型就是一個Map對象；
調用Template實例的process方法完成合並。
Thymleaf：
特色：
動靜結合：頁面採用模板+數據的方式，在前端美工手中，能夠展現靜態頁面。在後臺開發人員手中，也能夠展現數據返回到頁面後的界面。這是由於thymeleaf支持html原型，能夠在原型上添加額外的屬性，瀏覽器在解釋html時會忽視未定義的屬性，當定義的屬性有值時就會動態替換靜態頁面，來實現動態展現。
開箱即用：提供標準和spring標準兩種方言，能夠直接套用模板實現JSTL、 OGNL表達式效果，
避免天天套模板、改jstl、改標籤的困擾。同時開發人員也能夠擴展和建立自定義的方言。
多方言支持：
Thymeleaf 提供spring標準方言和一個與 SpringMVC 完美集成的可選模塊，能夠快速的實現表單綁定、屬性編輯器、國際化等功能。
與springboor完美整合：SpringBoot提供了Thymeleaf的默認配置，而且爲Thymeleaf設置了視圖解析器，咱們能夠像之前操做jsp同樣來操做Thymeleaf。代碼幾乎沒有任何區別，就是在模板語法上有區別。
使用：

1. 建立一個sprinboot項目
2. 添加thymeleaf的起步依賴
3. 添加spring web的起步依賴
4. 編寫html 使用thymleaf的語法獲取變量對應後臺傳遞的值
5. 編寫controller 設置變量的值到model中

項目中定時任務怎麼寫的？

最簡單的一種：在線程中執行 Thread.sleep()，休眠掛起線程，等待一段時間後再執行；
藉助Timer和TimerTask實現定時任務；
藉助調度線程池 Executors.newScheduledThreadPool() 實現定時任務；
藉助第三方工具，如spring的定時任務； Quartz；

如何實現郵箱和短信的發送？

短信：阿里雲SMS，百度雲SMS，七牛雲SMS等
郵件：
進入郵箱設置，將其開啓POP3/SMTP服務，以容許咱們經過第三方客戶端發送郵件。而且獲取受權碼（不是登陸密碼）
使用JavaMail發送郵件很是簡單，也是三步曲：
​ 建立鏈接對象javax.mail.Session
​ 建立郵件對象 javax.mail.Message
​ 發送郵件

兩個異構項目之間的實時數據互通會怎麼作？

Web Service就能夠解決異構系統的通訊的整合。
web Service技術獲得了Java的支持，在JDK6之後都給出了相關規範的實現：
JAX-WS（XML web services的Java API）是SOAP方式：簡單對象訪問協議，他是用於交換XML編碼信息的輕量級協議；
JAX-RS即restful方式風格。

nginx的瞭解和使用？

Nginx是一個高性能的HTTP和反向代理web服務器，同時也提供IMAP/POP3/SMTP服務;
主要功能：反向代理，經過配置文件能夠實現集羣和負載均衡，靜態資源虛擬化

maven如何解決jar包衝突？

移除依賴：
用於排除某項依賴的依賴jar包；
能夠藉助Maven Helper插件中的Dependency Analyzer分析衝突的jar包，而後在對應標紅版本的jar包上面點擊execlude，就能夠將該jar包排除出去。
手動排除:
手動在pom.xml中使用<exclusion>標籤去排除衝突的jar包（上面利用插件Maven Helper中的execlude方法其實等同於該方法）：
mvn dependency:tree
版本鎖定原則：
通常用在繼承項目的父項目中；
正常項目都是多模塊的項目，如moduleA和moduleB共同依賴X這個依賴的話，那麼能夠將X抽取出來，同時設置其版本號，這樣X依賴在升級的時候，不須要分別對moduleA和moduleB模塊中的依賴X進行升級，避免太多地方（moduleC、moduleD…）引用X依賴的時候忘記升級形成jar包衝突，這也是實際項目開發中比較常見的方法。

樹形結構的表怎麼設計？

設計1:鄰接表,是最多見的設計，能正確的表達菜單的樹狀結構且沒有冗餘數據，但在跨層級查詢須要遞歸處理。優勢結構簡單;缺點:不使用遞歸狀況下沒法查詢某節點全部父級,全部子集
設計2:路徑枚舉;在設計1基礎上新增一個父部門id集字段，用來存儲全部父集，多個以固定分隔符分隔，好比逗號。優勢:方便查詢全部的子集;也能夠所以經過比較字符串dept_parent_ids長度獲取當前節點層級。缺點:新增節點時須要將dept_parent_ids字段值處理好；dept_parent_ids字段的長度很難肯定，不管長度多大，都存在不可以無線擴展的狀況；節點移動複雜，須要同時變動全部子集中的dept_parent_ids字段值。
設計3：閉包表 是解決分級存儲的一個簡單而優雅的解決方案，是一種經過空間換取時間的方式；須要額外建立一張TreePaths表，它記錄了樹中全部節點間的關係；包含兩列，祖先列與後代列，即便這兩個節點之間不是直接的父子關係；同時增長一行指向節點本身；優勢：非遞歸查詢減小冗餘的計算時間；方便非遞歸查詢任意節點全部的父集；方便查詢任意節點全部的子集；能夠實現無限層級；支持移動節點；缺點：層級太多狀況下移動樹節點會帶來關係表多條操做；須要單獨一張表存儲對應關係，在新增與編譯節點時操做相對複雜；

如何實現菜單及增刪改查的功能權限管理？

SpringSecurity
Shiro

開發程序須要哪些文檔?

可行性分析報告;項目開發計劃;軟件需求說明書（軟件規格說明書）；概要設計說明書；詳細設計說明書；用戶操做手冊；測試計劃；測試分析報告；開發進度月報；軟件維護手冊；軟件問題報告；軟件修改報告。