3.23 17：50-18：50，就1個(gè)小時(shí)

題量很大，20道單選題，11道多選題，5道填空題，5道綜合題，1道附加題。

考察范圍很廣，Java基礎(chǔ)，JVM，JUC，SQL，redis，消息隊(duì)列，微服務(wù)。

鼠人寄了，好多沒(méi)做出來(lái)。

說(shuō)一說(shuō)面向?qū)ο蟮娜筇卣鳎?/strong>

synchronized和violated的區(qū)別？

一旦一個(gè)共享變量（類(lèi)的成員變量、類(lèi)的靜態(tài)成員變量）被volatile修飾之后，那么就具備了兩層語(yǔ)義：

1）保證了不同線(xiàn)程對(duì)這個(gè)變量進(jìn)行操作時(shí)的可見(jiàn)性，即一個(gè)線(xiàn)程修改了某個(gè)變量的值，這新值對(duì)其他線(xiàn)程來(lái)說(shuō)是立即可見(jiàn)的。

2）禁止進(jìn)行指令重排序。

volatile本質(zhì)是在告訴jvm當(dāng)前變量在寄存器（工作內(nèi)存）中的值是不確定的，需要從主存中讀取；

synchronized則是鎖定當(dāng)前變量，只有當(dāng)前線(xiàn)程可以訪(fǎng)問(wèn)該變量，其他線(xiàn)程被阻塞住。

1.volatile僅能使用在變量級(jí)別；synchronized則可以使用在變量、方法、和類(lèi)級(jí)別的

2.volatile僅能實(shí)現(xiàn)變量的修改可見(jiàn)性，并不能保證原子性；synchronized則可以保證變量的修改可見(jiàn)性和原子性

3.volatile不會(huì)造成線(xiàn)程的阻塞；synchronized可能會(huì)造成線(xiàn)程的阻塞。

4.volatile標(biāo)記的變量不會(huì)被編譯器優(yōu)化；synchronized標(biāo)記的變量可以被編譯器優(yōu)化

String,StringBuffer,StringBuilder增加字符串長(zhǎng)度哪個(gè)效率高：StringBuilder效率高，但是線(xiàn)程不安全,StringBuffer效率低一些，但是線(xiàn)程安全。

redis存儲(chǔ)的五種數(shù)據(jù)類(lèi)型是什么，如何進(jìn)行數(shù)據(jù)持久化？

附加題：你了解哪些微服務(wù)框架？微服務(wù)的優(yōu)點(diǎn)和缺點(diǎn)是什么？微服務(wù)未來(lái)會(huì)面臨什么樣的挑戰(zhàn)？

微服務(wù)的優(yōu)點(diǎn)

·易于開(kāi)發(fā)和維護(hù): 一個(gè)微服務(wù)只會(huì)關(guān)注一個(gè)特定的業(yè)務(wù)功能，所以它業(yè)務(wù)清晰、代碼量少。開(kāi)發(fā)和維護(hù)單個(gè)微服務(wù)相當(dāng)簡(jiǎn)單。而整個(gè)應(yīng)用是若干個(gè)微服務(wù)構(gòu)建而成的，所以整個(gè)應(yīng)用也被維持在一個(gè)可控狀態(tài)。

·單個(gè)微服務(wù)啟動(dòng)較快: 單個(gè)微服務(wù)代碼量較少，所以啟動(dòng)會(huì)比較快。

·局部修改容易部署: 單個(gè)應(yīng)用只要有修改，就得重新部署整個(gè)應(yīng)用，微服務(wù)解決了這樣的問(wèn)題。一般來(lái)說(shuō)，對(duì)某個(gè)微服務(wù)進(jìn)行修改，只需要重新部署這個(gè)服務(wù)即可。

·技術(shù)棧不受限: 在微服務(wù)架構(gòu)中，可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)，合理選擇技術(shù)棧。例如某些服務(wù)可以使用關(guān)系型數(shù)據(jù)庫(kù) Mysql,有些服務(wù)可以使用非關(guān)系型數(shù)據(jù)庫(kù)如 redis;甚至可根據(jù)需求，部分微服務(wù)使用 Java 開(kāi)發(fā)，部分微服務(wù)使用 Node.js 開(kāi)發(fā)。按需收縮: 可根據(jù)需求，實(shí)現(xiàn)細(xì)粒度的擴(kuò)展。例如，系統(tǒng)中的某個(gè)微服務(wù)遇到了瓶頸，可以結(jié)合這個(gè)微服務(wù)的業(yè)務(wù)特點(diǎn)，增加內(nèi)存、升級(jí) CPU 或者增加節(jié)點(diǎn)。

微服務(wù)的缺點(diǎn)

·運(yùn)維要求較高: 更多的服務(wù)意味著更多的運(yùn)維投入。在單體架構(gòu)中，只需要保證一個(gè)應(yīng)用的正常運(yùn)行。而在微服務(wù)中，需要保證幾十甚至幾百個(gè)服務(wù)正常運(yùn)行與協(xié)作，這給運(yùn)維帶來(lái)了很大的挑戰(zhàn)。

·分布式固有的復(fù)雜性: 使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對(duì)于一個(gè)分布式系統(tǒng)，系統(tǒng)容錯(cuò)、網(wǎng)絡(luò)延遲等都會(huì)帶來(lái)巨大的挑戰(zhàn)。

·接口調(diào)整成本高: 微服務(wù)之間通過(guò)接口進(jìn)行通信。如果修改某一個(gè)微服務(wù) API，可能所有使用該接口的微服務(wù)都需要調(diào)整。

————————————————

版權(quán)聲明：本文為CSDN博主「Blue92120」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。

貼上原文鏈接：什么是微服務(wù)架構(gòu)？微服務(wù)架構(gòu)有什么優(yōu)缺點(diǎn)？