Java篇

JVM

001.談談對Java的理解

<需要對JAVA語言特點做匯總>
JAVA語言特點有以下方面:
1.平臺無關性(一次編譯到處運行)
2.GC垃圾回識訓制
3.語言特性(泛型,反射,Lambda運算式)
4.面向物件(封裝,繼承,多型)
5.類別庫
6.例外處理

002.如何實作平臺無關性

<.java檔案 -> .class檔案 -> 指令>
JAVA原始碼首先被編譯成位元組碼,再由<不同平臺的JVM進行決議>,
Java語言在不同的平臺上運行時不需要進行重新編譯,Java虛擬機在執行位元組碼的時候,把位元組碼轉換成對應平臺的機器指令

# <程序> 
1.撰寫java原始碼
2.javac 編譯指令(語法檢查等)
3.編譯后生成.class檔案(二進制檔案);
<可以通過javap -c xxx 反編譯>
4. java命令執行.class檔案

003.什么是JVM

1.<Java虛擬機(JVM)是一種抽象化的計算機>
<是一個記憶體中的虛擬機,JVM的存盤就是記憶體>,仿真模擬各種計算機的功能
2.JVM也<有自己完善的架構>,如處理器,堆疊, 暫存器,指令系統等
3.<JVM屏蔽了與具體作業系統相關的資訊>,不需要知道運行原理,<可以專注寫java代碼>,剩下的事情由jvm幫我們決議位元組碼去運行
4.這就是JVM存在的原因
5.JVM記憶體結構模型和GC就是我們平時需要掌握的

004.談談JVM的記憶體架構

<整個JVM大致分為五個部分>
<Class Loader 類加載器>
依據特定格式加載class檔案到記憶體
<Runtime Data Area 運行時資料區>
JVM記憶體空間結構模型
方法區,堆 ; 本地方法堆疊,java堆疊,程式計數器
<Execution Engine 執行引擎> 
對命令進行決議
<NativeInterface 本地介面>
融合不同開發語言的原生庫為java所用
需要一些較高執行性能的時候需要呼叫其他語言來處理(C++),JVM開辟了一塊為Native的記憶體來呼叫方法
<NativeLibrary 本地介面庫>
Native介面寫好的庫

005.什么是反射reflect

JAVA反射機制是<在運行狀態中>,對于任意一個類,都能夠知道這個類的所有屬性和方法;對于任意一個物件,都能呼叫它的任意方法和屬性;這種<動態獲取資訊>以<動態呼叫物件方法>的功能稱為java語言的反射機制

006.談談ClassLoader,編譯到執行程序

1.編譯器將.java源檔案編譯成Robot.class位元組碼檔案
2.ClassLoader將位元組碼轉換為JVM中的Class<Robot>物件

框架篇

SpringBoot

001.常用注解

# 專案配置注解
<@SpringBootApplication 復合注解>
是一個復合注解，包含了@SpringBootConfiguration，@EnableAutoConfiguration，@ComponentScan這三個注解，
	<@SpringBootConfiguration:標注當前類是配置類>
	這個注解繼承自@Configuration，并會將當前類內宣告的一個或多個以@Bean注解標記的方法的實體納入到srping容器中，并且實體名就是方法名，
	<@EnableAutoConfiguration:是自動配置的注解>
	這個注解會根據我們添加的組件jar來完成一些默認配置，我們做微服時會添加spring-boot-starter-web這個組件jar的pom依賴，這樣配置會默認配置springmvc 和tomcat
	<@ComponentScan:掃描當前包及其子包>
	被@Component，@Controller，@Service，@Repository注解標記的類并納入到spring容器中進行管理，
	等價于<context:component-scan>的xml組態檔中的配置項，

<@Autowired>是spring的自動裝配，從bean 工廠中獲取一個bean時,這個注解可以用到構造器，變數域，方法，注解型別上，
	<@Resource>一樣都可以用來裝配bean,不是spring提供的，是屬于J2EE規范的注解，

<@MapperScan:spring-boot支持mybatis組件>
的一個注解，通過此注解指定mybatis介面類的路徑，即可完成對mybatis介面的掃描，
	<@mapper需要加在每一個mapper介面類上面>


# 三層注解
<@Controller 表明這個類是一個控制器類>
	<@RequestMapping 使用攔截請求>，如果不在method中注明請求的方式，默認是攔截get和post請求，這樣請求會完成后轉向一個視圖決議器，
	<@ResponseBody注解>前后端會做分離，回傳json資料
	<@RestController 復合注解>是@Controller 和@ResponseBody的結合
	<@GetMapping><@PostMapping><@PutMapping><@DeleteMapping>Rest風格
	<@CrossOrigin>可以為整個controller配置啟用跨域，也可以在方法級別啟用
	<@PathVariable>路徑變數注解，@RequestMapping中用{}來定義url部分的變數名

<@Service 注解用來標記業務層的組件>
	@Resource默認按照名稱方式進行bean匹配
	@Autowired默認按照型別方式進行bean匹配

<@Repository 作為DAO物件，管理操作資料庫的物件>
	<@Component>通用注解，其他三個注解是這個注解的拓展
	<@Transactional>通過這個注解可以宣告事務，可以添加在類上或者方法上
	<@Configuration>配置類

# 攔截注解
<@ControllerAdvice>Controller的統一處理注解
<@ExceptionHandler>配合完成統一例外攔截處理
<@RestControllerAdvice>可以將例外以json的格式回傳資料

002.Spring IOC(控制反轉,面向物件)

配置 + 型別 = IOC容器

# <如何優先裝配bean(bean歧義沖突)>
@Primary 優先裝配,防止bean歧義沖突

# <如何主動獲取Bean根據命名獲取>
@Repository("alphadao")// 重新命名這個bean的名字
//主動獲取ioc容器中自定義名字的bean
alphaDao = applicationContext.getBean("alphadao",AlphaDao.class);

# <Bean的生命周期>
	@PreDestroy,在bean銷毀之前執行
	@PostConstruct,在bean初始化之后構造執行

# <如何IOC容器每次創建新的bean>
	<IOC容器的bean默認是單例模式,只創建一次>
	<@Scope("prototype")>創建多個bean
	<@Scope("singleton")>默認是單例模式,只創建一次bean

# <如何自動裝配指定名字的bean>
	@Repository("alphadao")
	@Autowired
	@Qualifier("alphadao")

003.Spring Application做了什么

# <spring應用 運行了啟動>
SpringApplication.run() 這個類做了什么?
<@SpringBootApplication>=
@SpringBootConfiguration(組態檔) +
@EnableAutoConfiguration(啟動自動配置) +
@ComponentScan(組件掃描) + ……
1.啟動Tomcat
2.自動創建了一個spring容器
3.自動裝配bean

SpringCloud

001.萬變不離其綜，微服務的4個核心問題

根本原因：網路不可靠

1.API 路由問題
2.HTTP，RPC通信問題
3.注冊和發現，高可用問題
4.熔斷機制

002.什么是微服務，如何獨立通訊

<提倡將單一的應用程式劃分成一組小的服務>，每個服務運行在其獨立的自己的行程內，服務間互相協調，互相配置，為用戶提供價值，<服務之間采用輕量級的通信機制互相溝通，每個服務都圍繞具體的業務進行構建，并且能夠獨立部署到生產的環境中>，

1.API 路由問題
2.HTTP，RPC通信問題
3.注冊和發現，高可用問題
4.熔斷機制

003.什么是服務熔斷，什么是服務降級

根本原因：網路不可靠

1.API 路由問題
2.HTTP，RPC通信問題
3.注冊和發現，高可用問題
4.熔斷機制

004.SpringCloud和Dubbo和Alibaba的區別

根本原因：網路不可靠

1.API 路由問題
2.HTTP，RPC通信問題
3.注冊和發現，高可用問題
4.熔斷機制

計算機網路篇

網路協議(四,七層)

OSI七層(僅供參考模型)

TCP/IP (主流)
(應用層,傳輸層,網路層,鏈路層)

TCP

<TCP三大特性> <ACK確認和SYN序號> <源埠和目的端>
<seq序號><TCP滑動視窗><>

1. 能不能說一說 TCP 和 UDP 的區別？
2. 說說 TCP 三次握手的程序？
3. 說說 TCP 四次揮手的程序?

001.能不能說一說 TCP 和 UDP 的區別？

# <一句話 概括>:
TCP是一個<面向連接的、可靠的、基于位元組流的傳輸層協議>，
而UDP(用戶資料報)是一個面向無連接的傳輸層協議，

# 詳細:
<TCP 三大特性 >:
1.<面向連接>，是客戶端和服務器的連接，在雙方互相通信之前，TCP 需要<三次握手建立連接>，而 UDP 沒有相應建立連接的程序
2.<可靠性>，體現在<有狀態, 即ACK確認和序號>，<可控制>，
TCP有狀態:<保證資料包按序到達,精準記錄哪些資料發送了，哪些資料被對方接收了>
TCP可控制:丟包了或者網路環境不佳，<控制自己的發送速度或者重發>
3.<面向位元組流>UDP 的資料傳輸是基于資料報的，
而 TCP 為了維護狀態，將一個個<IP包變成了位元組流>

# <IP協議和TCP協議>
< IP是無連接的通信協議 ,是不可靠的>
所以需要它的上層協議TCP傳輸控制協議來傳輸,增加可靠性

002.說說 TCP 三次握手的程序？

# <一句話 概括>
以<談戀愛>為例，就是確認<各自愛和被愛的能力>
<男方主動,女方被動>
<第一次:>
男: 我愛你，
女方收到，
由此證明男方擁有愛的能力，
<第二次:>
女: 我收到了你的愛，我也愛你，
男方收到，
OK，現在的情況說明，女方擁有愛和被愛的能力，
<第三次:>
男: 我收到了你的愛，
女方收到，
現在能夠保證男方具備被愛的能力，
由此<完整地確認了雙方愛和被愛的能力>，兩人開始一段甜蜜的愛情，

# 詳細
<三次握手程序 - closed - listen -sent>
從最開始雙方都處于<CLOSED狀態>，然后服務端開始監聽某個埠，進入了<LISTEN狀態>，
然后客戶端主動發起連接，發送 SYN , 自己變成了SYN-<SENT狀態>，
服務端接收到，回傳SYN和ACK(對應客戶端發來的SYN)，自己變成了SYN-REVD，
之后客戶端再發送ACK給服務端，自己變成了ESTABLISHED狀態；服務端收到ACK之后，也變成了ESTABLISHED狀態，
另外需要提醒你注意的是，從圖中可以看出，SYN 是需要消耗一個序列號的，下次發送對應的 ACK 序列號要加1，為什么呢？只需要記住一個規則:
<凡是需要對端確認的，一定消耗TCP報文的序列號>

# <為什么不是兩次？>
根本原因: 無法確認客戶端的接收能力，
# <為什么不是四次？>
當然可以，100 次都可以，但為了解決問題，三次就足夠了，再多用處就不大了，
# <三次握手程序中可以攜帶資料么？>
<第三次握手的時候，可以攜帶>，前兩次握手不能攜帶資料，
如果前兩次握手能夠攜帶資料，有人想攻擊服務器，增大了<服務器被攻擊的風險>，

003.說說 TCP 四次揮手的程序?

# <一句話 概括>
以<分手>為例，就是確認<不愛的能力和分手通知>
<男方主動,女方被動>
<第一次:>
男: 我不愛你了，
女方收到，
由此證明男方已經不愛，
<第二次:>
女: 
1.我知道了,我不愛你了，
<第三次:>
2.我們分手吧
男方收到，
OK，現在的情況說明，女方不愛了和想分手了，
<第四次:>
男: 我收到了你的分手，
女方收到，
由此<完整地確認了雙方真正分手>

<等待2MSL><揮手是為了終止連接>
<等待是為了避免新舊連接混淆>
<為了確保有足夠時間讓對方收到ack包>

# <為什么需要四次>
因為全雙工,發送方和接受方都需要FIN報文和ACK報文

004.HTTP和TCP/IP

TPC/IP協議是<傳輸層協議>，主要解決資料如何在網路中傳輸
而HTTP是<應用層協議>，主要解決如何包裝資料

HTTP超文本傳輸協議

1.主要特點
2.請求回應的步驟
3.輸入URL后,按下回車之后的流程
4.HTTP狀態碼

001.主要特點？

支持客戶/服務端模式
簡單快速
靈活
無連接
無狀態

002.請求回應的步驟？

客戶端連接到Web服務器
發送HTTP請求
服務器接受請求并回傳HTTP回應
釋放TCP連接
客戶端瀏覽器決議HTML內容

003.輸入URL后,按下回車之后的流程？

DNS決議域名對應的地址
(瀏覽器快取,系統快取,路由器快取,IPS服務器快取,DNS快取)
建立TCP連接
發送HTTP請求
服務器處理請求并回傳HTTP報文
瀏覽器決議渲染頁面
連接結束

004.HTTP狀態碼

<五種可能的取值,1~5代表處理程序>

1xx 表示請求已接收,繼續處理
2xx 正常接收
3xx 重定向,初步完成請求需要進一步操作
4xx 客戶端錯誤 請求無法實作
5xx 服務端錯誤 不能回應合法的請求

<詳細>
200: 正常回傳資訊

400: Bad Request 客戶端請求語法錯誤,服務端不能理解
401: Unauthorized 請求未授權
403: Forbidden 服務器收到請求,但是拒絕提供服務
404: Not Found 請求資源不存在 eg.錯誤URL

500: Internal Server Error 服務器發生不可預期的錯誤 eg.服務器拋出例外代碼健壯性不佳
503: Server Unavailable 服務器當前不能處理請求,一段時間后可能恢復 eg.連接池滿了

005.Get請求和Post請求區別

<三個層面>
http報文層面:get請求資訊放在url中,post放在報文體中
資料庫層面:get符合冪等性和安全性,post不符合
其他層面:get可以被快取存盤,post不行

006.Cookie和Session

Cookie資料存放在客戶的瀏覽器上,Session資料放在服務器上
Session相對于Cookie更安全
Session會占用服務器,若考慮減輕服務器壓力,應當使用Cookie

<Cookie 客戶端保存機制>
服務器發給客戶端的特殊資訊,以文本的形式存放在客戶端
客戶端再次請求的時候,會把Cookie回發
服務器接收到后,會決議Cookie生成與客戶端相對應的內容

<Session 服務端保存機制>
服務端的機制,在服務器上保存的資訊
決議客戶端請求操作并操作session id,按需保存狀態資訊
<Session 實作方式>
方式一:<Cookie來實作>在發送Cookie時候系結一個JSessionID在Cookie頭中,下次請求的時候<攜帶這個頭>
方式二:<URL回寫來實作>通過URL回傳的新URL鏈接攜帶一個JSessionID