螞蟻金服面試題和答案

螞蟻金服面試題和答案

1. 自我介紹、本身作的項目和技術領域

2. 項目中的監控：那個監控指標常見的哪些？

名詞	含義
TPS	應用每秒處理的請求數
AVG	應用對每一個請求響應的平均時間
TP99	99%的請求響應時間小於等於該值
TP90	90%的請求響應時間小於等於該值
TP50	50%的請求響應時間小於等於該值
FAIL	應用對請求響應的成功、失敗比率
調用連接	一次請求所通過的全部系統的集合產生的鏈條，反饋了系統將的依賴關係及時許

2.1服務端監控指標

性能測試一般須要監控的指標包括：

服務器 Linux (包括CPU、Memory、Load、I/O)

數據庫：MySQL（緩存命中、索引、單條SQL性能、數據庫線程數、數據池鏈接數）

中間件：1.tomcat 二、nginx 三、memcache 四、Redis（包括線程數、鏈接數、日誌）

網絡：吞吐量、吞吐率

應用：Jvm內存、日誌、Full GC頻率

2.2客戶端監控指標

LoadRunner:用戶執行狀況、場景狀態、事物響應時間、TPS、吞吐量

測試機資源：CPU、Memory、網絡、磁盤空間

3.微服務涉及到的技術以及須要注意的問題有哪些？

1.每一個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。

2.微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。

3.微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段或部署階段都是獨立的。

4.微服務能使用不一樣的語言開發。

5.微服務易於被一個開發人員理解，修改和維護，這樣小團隊可以更關注本身的工做成果。無需經過合做才能體現價值。

3.1微服務架構的缺點

1.微服務架構可能帶來過多的操做。

2.須要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps)。

3.可能雙倍的努力。

4.分佈式系統可能複雜難以管理。

5.由於分佈部署跟蹤問題難。

6.當服務數量增長，管理複雜性增長。

4.註冊中心你瞭解了哪些？

在微服務架構中，註冊中心是核心的基礎服務之一。在微服務架構流行以前，註冊中心就已經開始出如今分佈式架構的系統中。Dubbo是一個在國內比較流行的分佈式框架，被大量的中小型互聯網公司所採用，Dubbo是一個很是實用的框架，提供了比較完善的服務治理功能，而服務治理的實現主要依靠的就是註冊中心。

5.consul 的可靠性你瞭解嗎？

那麼consul是啥？consul就是提供服務發現的工具

consul是分佈式的、高可用、橫向擴展的

6.consul 的機制你有沒有具體深刻過？有沒有和其餘的註冊中心對比過？

ZooKeeper

歷史悠久，數據存儲格式相似文件系統，經過私有協議訪問，集羣式架構。優勢是成熟穩定，缺點是系統複雜，資源佔用高

etcd

etcd是經過HTTP協議訪問的k/v存儲系統，採用集羣架構，容易部署和使用。但他更多功能是提供存儲，要實現服務發現還得配合一些第三方的應用或者本身實現。 \* 「registrator」, 自動註冊工具，將服務提供方的信息存儲到etcd, consul這種kv存儲系統 * 」confd「，輕量級的配置管理工具，他能夠從etcd裏取最新的服務信息生成配置文件，服務使用方就能夠用它來實時更新配置文件

Consul

Consul 提供了高可用的kv存儲，集羣架構，這點和etcd zookeeper相似。 另外也提供了自動服務發現註冊的套件，而且可否對服務進行健康檢查。 結合consul-template能夠實現服務提供方信息更新(好比增長了API服務器)時，自動生成配置文件給服務使用方自動更新配置。

7.項目用 Spring 比較多，有沒有了解 Spring 的原理？AOP 和 IOC 的原理

Spring的兩個核心概念是IOC（控制反轉）和AOP（面向切面編程）

spring原理

8.Spring Boot除了自動配置，相比傳統的 Spring 有什麼其餘的區別？

從本質上來講，Spring Boot就是Spring,它作了那些沒有它你也會去作的Spring Bean配置

SpringBoot的優勢？Spring因爲其繁瑣的配置，一度被人認爲「配置地獄」，各類XML、Annotation配置，讓人眼花繚亂，並且若是出錯了也很難找出緣由。SpringBoot幫助開發者快速啓動一個Web容器；SpringBoot繼承了原有Spring框架的優秀基因；SpringBoot簡化了使用Spring的過程。
SpringBoot的缺點？Spring Boot做爲一個微框架，離微服務的實現仍是有距離的。沒有提供相應的服務發現和註冊的配套功能，自身的acturator所提供的監控功能，也須要與現有的監控對接。沒有配套的安全管控方案，對於REST的落地，還須要自行結合實際進行URI的規範化工做。

9.Spring Cloud 有了解多少？

10.Spring Bean 的生命週期

實例化==>填充屬性==>調用BeanNameAware的setBeanName方法==>調用BeanFactoryAware的setBeanDactory方法==>調用ApplicationContext方法==>調用BeanPostProcess的postProcessBeforeInitialization方法==>調用InitializingBean的afterPropertiesSet方法==>調用定製的初始化方法==>調用BeanPostProcess的postProcessAfterInitialization方法==>Bean準備就緒==>調用DispostbleBean的destory方法==>調用定製的銷燬方法

Spring 只幫咱們管理單例模式 Bean 的**完整**生命週期，對於 prototype 的 bean ，Spring 在建立好交給使用者以後則不會再管理後續的生命週期。

11.HashMap 和 hashTable 區別？

HashMap線程是不安全的，HashTable是安全的。HashTable的key和value都不能爲null，HashMap的key和value能夠爲null

12.Object 的 hashcode 方法重寫了，equals 方法要不要改？

我的觀點：若是咱們重寫了equals方法的話，咱們就必須重寫hashcode方法，爲何equals()相等，那麼hashCode()必須相等。由於，若是兩個對象的equals()方法返回true，則它們在哈希表中只應該出現一次；若是hashCode()不相等，那麼它們會被散列到表中不一樣的位置，哈希表中不止出現一次

若是隻修改了hashcode的方法，equlas方法能夠沒必要要修改

13.Hashmap 線程不安全的出現場景

咱們都知道HashMap初始容量大小爲16,通常來講，當有數據要插入時，都會檢查容量有沒有超過設定的thredhold，若是超過，須要增大Hash表的尺寸，可是這樣一來，整個Hash表裏的元素都須要被重算一遍。這叫rehash

外一個比較明顯的線程不安全的問題是HashMap的get操做可能由於resize而引發死循環（cpu100%）

14.線上服務 CPU 很高該怎麼作？有哪些措施能夠找到問題

top oder by with P：1040 // 首先按進程負載排序找到  axLoad(pid)
top -Hp 進程PID：1073    // 找到相關負載 線程PID
printf 「0x%x\n」線程PID： 0x431  // 將線程PID轉換爲 16進制，爲後面查找 jstack 日誌作準備
jstack  進程PID | vim +/十六進制線程PID -        // 例如：jstack 1040|vim +/0x431 -

記一次線上Java程序致使服務器CPU佔用率太高的問題排除過程

線上服務 CPU 100%？一鍵定位不騙你-掘金

15.JDK 中有哪幾個線程池？順帶把線程池講了個遍

java封裝的幾個線程池介紹

FixedThreadPool:
FixedThreadPool並非一個類，它是由Executors工具類建立出來的一個固定線程數的ThreadPoolEexcutor的對象。
SingleThreadPool:
SingleThreadPool是隻有一個線程的線程池，內部實現和FixedThreadPool同樣，不過就是線程數有區別。
CachedThreadPool:
一個可緩存線程池，若是線程池長度超過處理須要，可靈活回收空閒線程，若無可回收，則新建線程
ScheduledThreadPoolExecutor:
一個定長線程池，支持定時及週期性任務執行。

16.SQL 優化的常見方法有哪些

1.應儘可能避免在 where 子句中使用!=或<>操做符，不然將引擎放棄使用索引而進行全表掃描

2.對查詢進行優化，應儘可能避免全表掃描，首先應考慮在 where 及 order by 涉及的列上創建索引

3.應儘可能避免在 where 子句中對字段進行 null值判斷，不然將致使引擎放棄使用索引而進行全表掃描，

​ 如：select id from t where num is null能夠在num上設置默認值0，確保表中num列沒有null值，

​ 而後這樣查詢：select id from t where num=0

4.儘可能避免在 where 子句中使用 or 來鏈接條件，不然將致使引擎放棄使用索引而進行全表掃描，

​ 如：select id from t where num=10 or num=20

​ 能夠這樣查詢：select id from t where num=10 unionall select id from t where num=20

5.下面的查詢也將致使全表掃描 select id from t where name like ‘%c%’,左模糊和全模糊查詢都會致使搜索引擎放棄索引直接全表掃描，要想使用索引可使用右模糊查詢

6.in 和 not in 也要慎用，不然會致使全表掃描

​ 如：select id from t where num in(1,2,3)

​ 對於連續的數值，能用 between 就不要用 in 了：select id from t where num between 1 and 3

7.若是在 where 子句中使用參數，也會致使全表掃描。由於SQL只有在運行時纔會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，若是在編譯時創建訪問計劃，變量的值仍是未知的，於是沒法做爲索引選擇的輸入項。

​ 以下面語句將進行全表掃描：select id from t where num = @num

​ 能夠改成強制查詢使用索引：select id from t with(index(索引名)) where num = @num

8.應儘可能避免在 where 子句中對字段進行表達式操做，這將致使引擎放棄使用索引而進行全表掃描。

​ 如：select id from t where num/2=100

​ 應改成: select id from t where num=100*2

9.應儘可能避免在where子句中對字段進行函數操做，這將致使引擎放棄使用索引而進行全表掃描。

​ 如：select id from t where substring(name,1,3)=’abc’–name以abc開頭的id

​ select id from t where date diff(day,createdate,’2005-11-30′)=0–’2005-11-30′生成的id

​ 應修改成：select id from t where name like‘abc%’select id from t where createdate>=’2005-11-30′ andcreatedate<’2005-12-1′

10.不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引

11.在使用索引字段做爲條件時，若是該索引是複合索引，那麼必須使用到該索引中的第一個字段做爲條件時才能保證系統使用該索引，不然該索引將不會被使用，而且應儘量的讓字段順序與索引順序相一致

12.不要寫一些沒有意義的查詢，如須要生成一個空表結構：

​ 如：select col1,col2 into #t from t where 1=0這類代碼不會返回任何結果集，可是會消耗系統資源的，

​ 應改爲這樣：create table #t(…)

13.不少時候用 exists 代替 in 是一個好的選擇

​ 如：select num from a where num in(select num from b)

​ 修改爲 select num from a where exists(select 1 from b where num=a.num)

14.並非全部索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重複時，SQL查詢可能不會去利用索引，如一表中有字段 sex，male、female幾乎各一半，那麼即便在sex上建了索引也對查詢效率起不了做用。

15.索引並非越多越好，索引當然能夠提升相應的 select 的效率，但同時也下降了 insert 及 update 的效率，由於 insert 或 update 時有可能會重建索引，因此怎樣建索引須要慎重考慮，視具體狀況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要

16.儘可能使用數字型字段，若只含數值信息的字段儘可能不要設計爲字符型，這會下降查詢和鏈接的性能，並會增長存儲開銷。這是由於引擎在處理查詢和鏈接時會逐個比較字符串中每個字符，而對於數字型而言只須要比較一次就夠了

17.儘量的使用varchar/nvarchar 代替 char/nchar ，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。

18.任何地方都不要使用 select *from t ，用具體的字段列表代替「*」，不要返回用不到的任何字段。

19.儘可能避免使用遊標，由於遊標的效率較差，若是遊標操做的數據超過1萬行，那麼就應該考慮改寫

20.在全部的存儲過程和觸發器的開始處設置SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每一個語句後向客戶端發送 DONE_IN_PROC 消息。

21.儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

17.SQL 索引的順序，字段的順序

遵循最左原則

18.查看 SQL 是否是使用了索引？（有什麼工具）

查看SQL語句是否引用了索引，可使用EXPLAIN 方法如：EXPLAIN SELECT * FROM student WHERE cid=1;

之前有個工具叫作mysqlreport。如今他的身份就是percona toolkit。點擊連接查看官方網站。能夠下載使用手冊。

19.TCP 和 UDP 的區別？TCP 數據傳輸過程當中怎麼作到可靠的？

TCP與UDP區別總結：
一、TCP面向鏈接（如打電話要先撥號創建鏈接）;UDP是無鏈接的，即發送數據以前不須要創建鏈接
二、TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保   證可靠交付
三、TCP面向字節流，其實是TCP把數據當作一連串無結構的字節流;UDP是面向報文的
  UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）
四、每一條TCP鏈接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通訊
五、TCP首部開銷20字節;UDP的首部開銷小，只有8個字節
六、TCP的邏輯通訊信道是全雙工的可靠信道，UDP則是不可靠信道

TCP協議與UDP協議的區別
首先我們弄清楚，TCP協議和UCP協議與TCP/IP協議的聯繫，不少人犯糊塗了，
一直都是說TCP協議與UDP協議的區別，我以爲這是沒有從本質上弄清楚網絡通訊！
TCP/IP協議是一個協議簇。裏面包括不少協議的，UDP只是其中的一個， 之因此命名爲TCP/IP協議，由於TCP、IP協議是兩個很重要的協議，就用他兩命名了。

TCP/IP協議集包括應用層,傳輸層，網絡層，網絡訪問層。

其中應用層包括:
一、超文本傳輸協議（HTTP）:萬維網的基本協議；
二、文件傳輸（TFTP簡單文件傳輸協議）；
三、遠程登陸（Telnet），提供遠程訪問其它主機功能, 它容許用戶登陸internet主機，並在這臺主機上執行命令；
四、網絡管理（SNMP簡單網絡管理協議），該協議提供了監控網絡設備的方法， 以及配置管理,統計信息收集,性能管理及安全管理等；
五、域名系統（DNS），該系統用於在internet中將域名及其公共廣播的網絡節點轉換成IP地址。

其次網絡層包括:
一、Internet協議（IP）；
二、Internet控制信息協議（ICMP）；
三、地址解析協議（ARP）；
四、反向地址解析協議（RARP）。

最後說網絡訪問層:
網絡訪問層又稱做主機到網絡層（host-to-network），網絡訪問層的功能包括IP地址與物理地址硬件的映射， 以及將IP封裝成幀.基於不一樣硬件類型的網絡接口，網絡訪問層定義了和物理介質的鏈接. 固然我這裏說得不夠完善，TCP/IP協議原本就是一門學問，每個分支都是一個很複雜的流程， 但我相信每位學習軟件開發的同窗都有必要去仔細瞭解一番。

下面着重講解一下TCP協議和UDP協議的區別:
TCP三次握手過程
第一次握手：主機A經過向主機B 發送一個含有同步序列號的標誌位的數據段給主機B，向主機B 請求創建鏈接，經過這個數據段， 主機A告訴主機B 兩件事：我想要和你通訊；你能夠用哪一個序列號做爲起始數據段來回應我。

第二次握手：主機B 收到主機A的請求後，用一個帶有確認應答（ACK）和同步序列號（SYN）標誌位的數據段響應主機A，也告訴主機A兩件事：我已經收到你的請求了，你能夠傳輸數據了；你要用那個序列號做爲起始數據段來回應我

第三次握手：主機A收到這個數據段後，再發送一個確認應答，確認已收到主機B 的數據段："我已收到回覆，我如今要開始傳輸實際數據了，這樣3次握手就完成了，主機A和主機B 就能夠傳輸數據了。

3次握手的特色
沒有應用層的數據 SYN這個標誌位只有在TCP創建鏈接時纔會被置1 握手完成後SYN標誌位被置0。

TCP創建鏈接要進行3次握手，而斷開鏈接要進行4次
第一次： 當主機A完成數據傳輸後,將控制位FIN置1，提出中止TCP鏈接的請求 ；

第二次： 主機B收到FIN後對其做出響應，確認這一方向上的TCP鏈接將關閉,將ACK置1；

第三次： 由B 端再提出反方向的關閉請求,將FIN置1 ；

第四次： 主機A對主機B的請求進行確認，將ACK置1，雙方向的關閉結束.
名詞解釋
一、ACK 是TCP報頭的控制位之一，對數據進行確認。確認由目的端發出， 用它來告訴發送端這個序列號以前的數據段都收到了。 好比確認號爲X，則表示前X-1個數據段都收到了，只有當ACK=1時,確認號纔有效，當ACK=0時，確認號無效，這時會要求重傳數據，保證數據的完整性。

二、SYN 同步序列號，TCP創建鏈接時將這個位置1。

三、FIN 發送端完成發送任務位，當TCP完成數據傳輸須要斷開時,，提出斷開鏈接的一方將這位置1。

TCP的包頭結構：
源端口 16位；

目標端口 16位；

序列號 32位；

迴應序號 32位；

TCP頭長度 4位；

reserved 6位；

控制代碼 6位；

窗口大小 16位；

偏移量 16位；

校驗和 16位；

選項 32位(可選)；

這樣咱們得出了TCP包頭的最小長度，爲20字節。

UDP（User Data Protocol，用戶數據報協議）
一、UDP是一個非鏈接的協議，傳輸數據以前源端和終端不創建鏈接， 當它想傳送時就簡單地去抓取來自應用程序的數據，並儘量快地把它扔到網絡上。 在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、 計算機的能力和傳輸帶寬的限制； 在接收端，UDP把每一個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。

二、 因爲傳輸數據不創建鏈接，所以也就不須要維護鏈接狀態，包括收發狀態等， 所以一臺服務機可同時向多個客戶機傳輸相同的消息。

三、UDP信息包的標題很短，只有8個字節，相對於TCP的20個字節信息包的額外開銷很小。

四、吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬、 源端和終端主機性能的限制。

五、UDP使用盡最大努力交付，即不保證可靠交付， 所以主機不須要維持複雜的連接狀態表（這裏面有許多參數）。

六、UDP是面向報文的。發送方的UDP對應用程序交下來的報文， 在添加首部後就向下交付給IP層。既不拆分，也不合並，而是保留這些報文的邊界， 所以，應用程序須要選擇合適的報文大小。



咱們常用「ping」命令來測試兩臺主機之間TCP/IP通訊是否正常， 其實「ping」命令的原理就是向對方主機發送UDP數據包，而後對方主機確認收到數據包， 若是數據包是否到達的消息及時反饋回來，那麼網絡就是通的。



ping命令是用來探測主機到主機之間是否可通訊，若是不能ping到某臺主機，代表不能和這臺主機創建鏈接。ping命令是使用 IP 和網絡控制信息協議 (ICMP)，於是沒有涉及到任何傳輸協議(UDP/TCP) 和應用程序。它發送icmp回送請求消息給目的主機。

ICMP協議規定：目的主機必須返回ICMP回送應答消息給源主機。若是源主機在必定時間內收到應答，則認爲主機可達。

UDP的包頭結構：
源端口 16位 目的端口 16位 長度 16位 校驗和 16位

20.說下你知道的排序算法吧

排序算法

面試中的排序算法總結(https://www.cnblogs.com/wxisme/p/5243631.html)

​ 冒泡排序、選擇排序、插入排序、快速排序、堆排序、希爾排序、歸併排序、計數排序、桶排序、基數排序、

算法	最快時間複雜度	平均時間複雜度	最壞時間複雜度	空間複雜度	是否穩定
冒泡排序	Ω(n)	Θ(n2)	O(n2)	O(1)	穩定
插入排序	Ω(n)	Θ(n2)	O(n2)	O(1)	穩定
希爾排序	Ω(nlogn)	Θ(n(log(n))2)	O(n(log(n))2)	O(1)	不穩定
選擇排序	Ω(n2)	Θ(n2)	O(n2)	O(1)	不穩定
堆排序	Ω(nlogn)	Θ(nlogn)	O(nlogn)	O(1)	不穩定
歸併排序	Ω(nlogn)	Θ(nlogn)	O(nlogn)	O(n)	穩定
快速排序	Ω(nlogn)	Θ(nlogn)	O(nlogn)	O(logn)	不穩定
基數排序	Ω(n+b)	Θ(n+b)	O(n+b)	O(n+k)	穩定

O表示上界(小於等於)Ω表示下界(大於等於)Θ表示便是上界也是下界(等於)

21.查找一個數組的中位數？

【算法】無序數組中求中位數(https://blog.csdn.net/u010983881/article/details/78160671)

22.http 默認端口，https 默認端口

⑴. HTTP協議代理服務器經常使用端口號：80/8080/3128/8081/9080
⑵. SOCKS代理協議服務器經常使用端口號：1080
⑶. FTP（文件傳輸）協議代理服務器經常使用端口號：21
⑷. Telnet（遠程登陸）協議代理服務器經常使用端口：23

HTTP服務器，默認的端口號爲80/tcp（木馬Executor開放此端口）；
HTTPS（securely transferring web pages）服務器，默認的端口號爲443/tcp 443/udp；
Telnet（不安全的文本傳送），默認端口號爲23/tcp（木馬Tiny Telnet Server所開放的端口）；
FTP，默認的端口號爲21/tcp（木馬Doly Trojan、Fore、Invisible FTP、WebEx、WinCrash和Blade Runner所開放的端口）；
TFTP（Trivial File Transfer Protocol），默認的端口號爲69/udp；
SSH（安全登陸）、SCP（文件傳輸）、端口重定向，默認的端口號爲22/tcp；
SMTP Simple Mail Transfer Protocol (E-mail），默認的端口號爲25/tcp（木馬Antigen、Email Password Sender、Haebu Coceda、Shtrilitz Stealth、WinPC、WinSpy都開放這個端口）；
POP3 Post Office Protocol (E-mail) ，默認的端口號爲110/tcp；
WebLogic，默認的端口號爲7001；
Webshpere應用程序，默認的端口號爲9080；
webshpere管理工具，默認的端口號爲9090；
JBOSS，默認的端口號爲8080；
TOMCAT，默認的端口號爲8080；
WIN2003遠程登錄，默認的端口號爲3389；
Symantec AV/Filter for MSE,默認端口號爲 8081；
Oracle 數據庫，默認的端口號爲1521；
ORACLE EMCTL，默認的端口號爲1158；
Oracle XDB（XML 數據庫），默認的端口號爲8080；
Oracle XDB FTP服務，默認的端口號爲2100；
MS SQL*SERVER數據庫server，默認的端口號爲1433/tcp 1433/udp；
MS SQL*SERVER數據庫monitor，默認的端口號爲1434/tcp 1434/udp；

23.DNS 你知道是幹嗎的嗎

DNS是Domain Name Service的縮寫，翻譯過來就是計算機域名服務器（也有擴寫成Domain Name System，譯爲計算機域名系統）。而之因此本文稱DNS服務器爲「翻譯官」，是由於DNS是進行域名(domain name)和與之相對應的IP地址(IP address)轉換的服務器。
一個域名能夠指向多個ip，用來作負載均衡嘛。
一樣一個ip能夠被多個域名指向，就是你們所購買的虛擬主機嘛;一個域名至少解析到一個IP地址，能夠解析到多個個IP地址，DNS輪詢和CDN加速就是這個原理。

24.git rebase 和 merge 有什麼區別

marge 特色：自動建立一個新的commit
若是合併的時候遇到衝突，僅須要修改後從新commit
優勢：記錄了真實的commit狀況，包括每一個分支的詳情
缺點：由於每次merge會自動產生一個merge commit，因此在使用一些git 的GUI tools，特別是commit比較頻繁時，看到分支很雜亂。

rebase 特色：會合並以前的commit歷史
優勢：獲得更簡潔的項目歷史，去掉了merge commit
缺點：若是合併出現代碼問題不容易定位，由於re-write了history

25.經常使用的負載均衡，該怎麼用

簡單介紹幾種經常使用的負載均衡原理(https://www.jianshu.com/p/da6e562fa3a6)

經常使用的負載均衡軟件詳解(https://blog.csdn.net/chengxuyuanyonghu/article/details/78500297)

負載均衡的幾種經常使用算法(https://www.cnblogs.com/me115/p/5000465.html)

26.網關可以爲後端服務帶來哪些好處

27.hashcode 和 equals 方法經常使用地方

Java的基類Object提供了一些方法，其中equals()方法用於判斷兩個對象是否相等，hashCode()方法用於計算對象的哈希碼。equals()和hashCode()都不是final方法，均可以被重寫(overwrite)。

28.hashmap put 方法存放的時候怎麼判斷是不是重複的

Map中判斷key是否相同是經過containsKey()方法進行的，它就是先判斷key的hashCode是否相同，再判斷key是否相等或equals的。若是存放的key值重複那麼會直接覆蓋掉與原來的Key值

29.ArrayList 和 LinkedList 區別

1.ArrayList是實現了基於動態數組的數據結構，每一個元素在內存中存儲地址是連續的；LinkedList基於鏈表的數據結構
2.LinkedList查詢用的遍歷，AyyayList查詢用的是數組下標，因此對於查詢ArrayList性能高於LinkedList，因此檢索性能顯然高於經過for循環來查找每一個元素的LinkedList。
3.元素插入刪除的效率對比，要視插入刪除的位置來分析，各有優劣：在列表首位添加（刪除）元素，LnkedList性能遠遠優於ArrayList；在列表中間位置添加（刪除）元素，總的來講位置靠前則LnkedList性能優於ArrayList，靠後則相反；在列表末尾位置添加（刪除）元素，性能相差不大。

30.Set 存的順序是有序的嗎？

   咱們常常據說List是有序且可重複的，Set是無序且不重複的。這是一個誤區，這裏所說的順序有兩個概念，一是按照添加的順序排列，二是按，照天然順序a-z排列。Set並非無序的傳統所說的Set無序指的是HashSet，它不能保證元素的添加順序，更不能保證天然順序，而Set的其餘實現類是能夠實現這兩種順序的。

1，LinkedHashset : 保證元素添加的天然順序

2，TreeSet : 保證元素的天然順序

31.HashSet 是否是線程安全的？爲何不是線程安全的？

hashset其實就是用hashmap實現的，因此是不安全的

32.Java 中有哪些線程安全的 Map

Java中平時用的最多的Map集合就是HashMap了，它是線程不安全的。
看下面兩個場景：
一、當用在方法內的局部變量時，局部變量屬於當前線程級別的變量，其餘線程訪問不了，因此這時也不存在線程安全不安全的問題了。
二、當用在單例對象成員變量的時候呢？這時候多個線程過來訪問的就是同一個HashMap了，對同個HashMap操做這時候就存在線程安全的問題了。

HashTable
HashTable的get/put方法都被synchronized關鍵字修飾，說明它們是方法級別阻塞的，它們佔用共享資源鎖，因此致使同時只能一個線程操做get或者put，並且get/put操做不能同時執行，因此這種同步的集合效率很是低，通常不建議使用這個集合。
SynchronizedMap
這種是直接使用工具類裏面的方法建立SynchronizedMap，把傳入進行的HashMap對象進行了包裝同步而已，這個同步方式實現也比較簡單，看出SynchronizedMap的實現方式是加了個對象鎖，每次對HashMap的操做都要先獲取這個mutex的對象鎖才能進入，因此性能也不會比HashTable好到哪裏去，也不建議使用。
ConcurrentHashMap - 推薦
這個也是最推薦使用的線程安全的Map，也是實現方式最複雜的一個集合，每一個版本的實現方式也不同，在jdk8以前是使用分段加鎖的一個方式，分紅16個桶，每次只加鎖其中一個桶，而在jdk8又加入了紅黑樹和CAS算法來實現。
做者：Java技術棧
連接：https://www.jianshu.com/p/533bb7cf8901
來源：簡書
簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。

33.Concurrenthashmap 是怎麼作到線程安全的？

分段機制：segment，每段加reentrantLock可重入鎖
定位元素：1 找segment數組下標  2 找segment的HashEntry數組下標
get方法：不須要加鎖，value值使用了volatile關鍵字修飾
put方法：hash計算段---鎖定段---hash計算HashEntry數組---若超多閾值---擴容---釋放；
ConcurrentHashMap是線程安全的，那是在他們的內部操做，其外部操做仍是須要本身來保證其同步的，特別是靜態的ConcurrentHashMap,其有更新和查詢的過程，要保證其線程安全，須要syn一個不可變的參數才能保證其原子性

34.你項目除了寫 Java 代碼，還有前端代碼，那你知道前端有哪些框架嗎

vue、React、Angular：是前段三大主流框架

35.MySQL 分頁查詢語句

mysql> SELECT * FROM table LIMIT 5,10; // 檢索記錄行 6-15  
  
//爲了檢索從某一個偏移量到記錄集的結束全部的記錄行，能夠指定第二個參數爲 -1：   
mysql> SELECT * FROM table LIMIT 95,-1; // 檢索記錄行 96-last.  
  
//若是隻給定一個參數，它表示返回最大的記錄行數目：   
mysql> SELECT * FROM table LIMIT 5; //檢索前 5 個記錄行  
  
//換句話說，LIMIT n 等價於 LIMIT 0,n。

36.不可重複讀會出如今什麼場景？

事務不考慮隔離性可能會引起的問題

一、髒讀
　　　　　髒讀指一個事務讀取了另一個事務未提交的數據。

　　　　　這是很是危險的，假設Ａ向Ｂ轉賬100元，對應sql語句以下所示
    　　　　　　1.update account set money=money+100 where name='B';    
    　　　　　　2.update account set money=money-100  where name='A';
    　　　 當第1條sql執行完，第2條還沒執行(A未提交時)，若是此時Ｂ查詢本身的賬戶，就會發現本身多了100元錢。若是A等B走後再回滾，B就會損失100元。

二、不可重複讀
　　不可重複讀指在一個事務內讀取表中的某一行數據，屢次讀取結果不一樣。
　　例如銀行想查詢A賬戶餘額，第一次查詢A賬戶爲200元，此時A向賬戶內存了100元並提交了，銀行接着又進行了一次查詢，此時A賬戶爲300元了。銀行兩次查詢不一致，可能就會很困惑，不知道哪次查詢是準的。
　　不可重複讀和髒讀的區別是，髒讀是讀取前一事務未提交的髒數據，不可重複讀是從新讀取了前一事務已提交的數據。
　　不少人認爲這種狀況就對了，無須困惑，固然是後面的爲準。咱們能夠考慮這樣一種狀況，好比銀行程序須要將查詢結果分別輸出到電腦屏幕和寫到文件中，結果在一個事務中針對輸出的目的地，進行的兩次查詢不一致，致使文件和屏幕中的結果不一致，銀行工做人員就不知道以哪一個爲準了。

三、虛讀(幻讀)
　　虛讀(幻讀)是指在一個事務內讀取到了別的事務插入的數據，致使先後讀取不一致。
　　如丙存款100元未提交，這時銀行作報表統計account表中全部用戶的總額爲500元，而後丙提交了，這時銀行再統計發現賬戶爲600元了，形成虛讀一樣會使銀行不知所措，到底以哪一個爲準。

37.前端瀏覽器地址的一個 http 請求到後端整個流程是怎麼樣？可以說下嗎？

域名解析 --> 發起TCP的3次握手 --> 創建TCP鏈接後發起http請求 --> 服務器響應http請求，瀏覽器獲得html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶

http請求方法：

GET: 完整請求一個資源 （經常使用）
HEAD: 僅請求響應首部
POST：提交表單  （經常使用）
PUT: (webdav) 上傳文件（可是瀏覽器不支持該方法）
DELETE：(webdav) 刪除
OPTIONS：返回請求的資源所支持的方法的方法
TRACE: 追求一個資源請求中間所通過的代理（該方法不能由瀏覽器發出）

【一次完整的Http請求過程】(https://blog.csdn.net/zjkC050818/article/details/78345819)

HTTP協議是無狀態的，咱們看到查到的用到的返回404，500,200，201,202,301.這些不是HTTP協議的狀態碼。是HTTP的狀態碼，就是HTTP請求服務器返回的狀態碼。HTTP協議和HTTP請求返回狀態碼是二回事。

**HTTP請求方法並非只有GET和POST，只是最經常使用的。據RFC2616標準（現行的HTTP/1.1）得知，一般有如下8種方法：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE和CONNECT。**

Code	HTTP Operation	Body Contents	Description
200	GET,PUT	資源	操做成功
201	POST	在資源,元數據	對象建立成功
202	POST,PUT,DELETE.PATCH	N/A	全請求已經被接受
204	DELETE,PUT,PATCH	N/A	操做已經執行成功，可是沒有返回數據
301	GET	link	資源已被移除
303	GET	link	重定向
304	GET	N/A	資源沒有被修改
400	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	參數列表錯誤(缺乏,但是不匹配)
401	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	未受權
403	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	和訪問受限，受權過時
404	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	資源，服務未找到
405	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	不容許的http方法
409	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	資源衝突，或者資源被鎖定
415	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	不支持的數據(媒體)類型
429	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	請求過多被限制
500	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	系統內部錯誤
501	GET,POST,PUT,DELETE.PATCH	錯誤提示(消息)	接口未實現

Java中HTTP的CRUD方法

HTTP方法	數據處理	說明
POST	Create	新增一個沒有id的資源
GET	Read	取得一個資源
PUT	Update	更新一個資源。或新增一個含 id 資源(若是 id 不存在)
DELETE	Delete	刪除一個資源