螞蟻金服面試題和答案
1. 自我介紹、自己做的項目和技術領域
2. 項目中的監控:那個監控指標常見的哪些?
| 名詞 | 含義 |
|---|---|
| TPS | 應用每秒處理的請求數 |
| AVG | 應用對每個請求響應的平均時間 |
| TP99 | 99%的請求響應時間小於等於該值 |
| TP90 | 90%的請求響應時間小於等於該值 |
| TP50 | 50%的請求響應時間小於等於該值 |
| FAIL | 應用對請求響應的成功、失敗比率 |
| 調用鏈接 | 一次請求所經過的所有系統的集合產生的鏈條,反饋了系統將的依賴關系及時許 |
2.1服務端監控指標
性能測試通常需要監控的指標包括:
服務器 Linux (包括CPU、Memory、Load、I/O)
數據庫:MySQL(緩存命中、索引、單條SQL性能、數據庫線程數、數據池連接數)
中間件:1.tomcat 2、nginx 3、memcache 4、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(面向切面編程)
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占用率過高的問題排除過程
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區別總結:
1、TCP面向連接(如打電話要先撥號建立連接);UDP是無連接的,即發送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說,通過TCP連接傳送的數據,無差錯,不丟失,不重復,且按序到達;UDP盡最大努力交付,即不保 證可靠交付
3、TCP面向字節流,實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的
UDP沒有擁塞控制,因此網絡出現擁塞不會使源主機的發送速率降低(對實時應用很有用,如IP電話,實時視頻會議等)
4、每一條TCP連接只能是點到點的;UDP支持一對一,一對多,多對一和多對多的交互通信
5、TCP首部開銷20字節;UDP的首部開銷小,只有8個字節
6、TCP的邏輯通信信道是全雙工的可靠信道,UDP則是不可靠信道
TCP協議與UDP協議的區別
首先咱們弄清楚,TCP協議和UCP協議與TCP/IP協議的聯系,很多人犯糊塗了,
一直都是說TCP協議與UDP協議的區別,我覺得這是沒有從本質上弄清楚網絡通信!
TCP/IP協議是一個協議簇。里面包括很多協議的,UDP只是其中的一個, 之所以命名為TCP/IP協議,因為TCP、IP協議是兩個很重要的協議,就用他兩命名了。
TCP/IP協議集包括應用層,傳輸層,網絡層,網絡訪問層。
其中應用層包括:
1、超文本傳輸協議(HTTP):萬維網的基本協議;
2、文件傳輸(TFTP簡單文件傳輸協議);
3、遠程登錄(Telnet),提供遠程訪問其它主機功能, 它允許用戶登錄internet主機,並在這台主機上執行命令;
4、網絡管理(SNMP簡單網絡管理協議),該協議提供了監控網絡設備的方法, 以及配置管理,統計信息收集,性能管理及安全管理等;
5、域名系統(DNS),該系統用於在internet中將域名及其公共廣播的網絡節點轉換成IP地址。
其次網絡層包括:
1、Internet協議(IP);
2、Internet控制信息協議(ICMP);
3、地址解析協議(ARP);
4、反向地址解析協議(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,雙方向的關閉結束.
名詞解釋
1、ACK 是TCP報頭的控制位之一,對數據進行確認。確認由目的端發出, 用它來告訴發送端這個序列號之前的數據段都收到了。 比如確認號為X,則表示前X-1個數據段都收到了,只有當ACK=1時,確認號才有效,當ACK=0時,確認號無效,這時會要求重傳數據,保證數據的完整性。
2、SYN 同步序列號,TCP建立連接時將這個位置1。
3、FIN 發送端完成發送任務位,當TCP完成數據傳輸需要斷開時,,提出斷開連接的一方將這位置1。
TCP的包頭結構:
源端口 16位;
目標端口 16位;
序列號 32位;
回應序號 32位;
TCP頭長度 4位;
reserved 6位;
控制代碼 6位;
窗口大小 16位;
偏移量 16位;
校驗和 16位;
選項 32位(可選);
這樣我們得出了TCP包頭的最小長度,為20字節。
UDP(User Data Protocol,用戶數據報協議)
1、UDP是一個非連接的協議,傳輸數據之前源端和終端不建立連接, 當它想傳送時就簡單地去抓取來自應用程序的數據,並盡可能快地把它扔到網絡上。 在發送端,UDP傳送數據的速度僅僅是受應用程序生成數據的速度、 計算機的能力和傳輸帶寬的限制; 在接收端,UDP把每個消息段放在隊列中,應用程序每次從隊列中讀一個消息段。
2、 由於傳輸數據不建立連接,因此也就不需要維護連接狀態,包括收發狀態等, 因此一台服務機可同時向多個客戶機傳輸相同的消息。
3、UDP信息包的標題很短,只有8個字節,相對於TCP的20個字節信息包的額外開銷很小。
4、吞吐量不受擁擠控制算法的調節,只受應用軟件生成數據的速率、傳輸帶寬、 源端和終端主機性能的限制。
5、UDP使用盡最大努力交付,即不保證可靠交付, 因此主機不需要維持復雜的鏈接狀態表(這里面有許多參數)。
6、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了,它是線程不安全的。
看下面兩個場景:
1、當用在方法內的局部變量時,局部變量屬於當前線程級別的變量,其他線程訪問不了,所以這時也不存在線程安全不安全的問題了。
2、當用在單例對象成員變量的時候呢?這時候多個線程過來訪問的就是同一個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.不可重復讀會出現在什么場景?
事務不考慮隔離性可能會引發的問題
1、臟讀
臟讀指一個事務讀取了另外一個事務未提交的數據。
這是非常危險的,假設A向B轉帳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未提交時),如果此時B查詢自己的帳戶,就會發現自己多了100元錢。如果A等B走后再回滾,B就會損失100元。
2、不可重復讀
不可重復讀指在一個事務內讀取表中的某一行數據,多次讀取結果不同。
例如銀行想查詢A帳戶余額,第一次查詢A帳戶為200元,此時A向帳戶內存了100元並提交了,銀行接着又進行了一次查詢,此時A帳戶為300元了。銀行兩次查詢不一致,可能就會很困惑,不知道哪次查詢是准的。
不可重復讀和臟讀的區別是,臟讀是讀取前一事務未提交的臟數據,不可重復讀是重新讀取了前一事務已提交的數據。
很多人認為這種情況就對了,無須困惑,當然是后面的為准。我們可以考慮這樣一種情況,比如銀行程序需要將查詢結果分別輸出到電腦屏幕和寫到文件中,結果在一個事務中針對輸出的目的地,進行的兩次查詢不一致,導致文件和屏幕中的結果不一致,銀行工作人員就不知道以哪個為准了。
3、虛讀(幻讀)
虛讀(幻讀)是指在一個事務內讀取到了別的事務插入的數據,導致前后讀取不一致。
如丙存款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 | 刪除一個資源 |
