每日一句
人到情多情轉薄，而今真個不多情，
每日一句
The frog in the well knows nothing of the great ocean.
井底之蛙，不知大海，
JVM 的類加載階段
JVM 的類加載分為五個階段：
1. 加載：被虛擬機讀入記憶體
2. 驗證：驗證 Class 位元組流的資料是否遵守JVM的規定
3. 準備：正式為類變數（靜態變數）分配記憶體并設定初始值，并非代碼中設定的值
4. 決議：將常量池中的符號參考決議為直接參考
5. 初始化：真正執行類中定義的java代碼
加載
指 JVM 讀取 class 檔案，并且根據 Class 檔案描述創建 java.lang.Class 物件的程序，
類加載程序主要包含將 Class 檔案讀取到運行時區域的方法區內，在堆中創建 java.lang.Class 物件，并封裝類在方法區的資料結構的程序，
在讀取 Class 檔案是既可以通過檔案的形式讀取，也可以通過 jar 包、war 包讀取，還可以通過代理自動生成 Class或其他方式讀取
驗證
主要用于確保 Class 檔案符合當前虛擬機的要求，保障虛擬機自身的安全，只有通過驗證的 CLass 檔案才能被 JVM 加載
準備
主要作業是在方法區中為類變數分配記憶體空間并設定類中變數的初始值，
初始值指不同資料型別的默認值，這里需要注意 final 型別的變數和非final型別的變數在準備階段的資料初始化程序不同
例如一個成員變數定義如下：
public static long value = https://www.cnblogs.com/yltrcc/archive/2022/04/23/1000;
在以上代碼中，靜態變數 value 在準備階段的初始值是0，將 value 設定為 1000 的動作是在物件初始化時完成的，因為 JVM 在編譯階段會將靜態變數的初始化操作定義在構造器中，
public static final int value = https://www.cnblogs.com/yltrcc/archive/2022/04/23/1000;
則JVM在編譯階段后會為final型別的變數value生成其對應的ConstantValue屬性，虛擬機在準備階段會根據ConstantValue屬性將value賦值為1000，
總結：靜態變數會賦兩次初值，準備階段賦零值，初始化時賦用戶設定值，而final變數會在準備階段一次性賦值完畢
決議
JVM 會將常量池中的符號參考替換為直接參考，
初始化
主要通過執行類構造器的
在一個類中既沒有靜態變數賦值操作也沒有靜態陳述句塊時，編譯器不會為該類生成
在發生以下幾種情況時，JVM不會執行類的初始化流程：
1. 常量在編譯時會將其常量值存入使用該常量的類的常量池中，該程序不需要呼叫常量所在的類，因此，不會觸發該常量類的初始化，
2. 在子類參考父類的靜態欄位時，不會觸發子類的初始化，只會觸發父類的初始化，
3. 定義物件陣列，不會觸發父類的初始化
4. 在使用類名獲取 Class 物件時不會觸發類的初始化
5. 在使用 Class.forName 加載指定的類時，可以通過 initialize 引數設定是否需要對類進行初始化
6. 在使用ClassLoader默認的loadClass方法加載類時不會觸發該類的初始化，
美文佳句
很多時候，事情的困境，常常是因為我們自己鉆了牛角尖，此時，你需要做的就是改變，
完美主義者可以放下執念，允許自己有普通人都會犯的小迷糊；職場媽媽可以直面現實，一個人永遠做不到家庭和事業的雙百分；承擔了過多作業任務的員工，可以嘗試向上級反映，尋求資源或調整目標……這些，都是我們應當并可以作出的改變，
正如這句話所說：世界上從來都沒有所謂的奇跡，命運一直都掌握在我們自己手里，想要改變自己的命運，最重要的就是改變自己，當你開始改變自己的時候，很多東西就跟著改變了，
下一次，當煩惱降臨時，不妨試試從自身找找問題，調整努力的方向和節奏，學會給心靈松綁，你會發現：很多事，其實沒什么大不了，
面試題
SpringMVC 框架有什么用？
Spring Web MVC 框架提供”模型-視圖-控制器”( Model-View-Controller )架構和隨時可用的組件，用于開發靈活且松散耦合的 Web 應用程式，
MVC 模式有助于分離應用程式的不同方面，如輸入邏輯，業務邏輯和 UI 邏輯，同時在所有這些元素之間提供松散耦合，
@RestController 和 @Controller 有什么區別？
@RestController 注解，在 @Controller 基礎上，增加了 @ResponseBody 注解，更加適合目前前后端分離的架構下，提供 Restful API ，回傳例如 JSON 資料格式，當然，回傳什么樣的資料格式，根據客戶端的 "ACCEPT" 請求頭來決定，
SpringMVC作業原理？
1. 客戶端發送請求到前端控制器 DispatcherServlet
2. DispatcherServlet 收到請求后，呼叫 HandlerMapping 處理器映射器，請求獲取 handler
3. 處理器映射器根據 url 找到具體的處理器，生成處理器物件以及處理器攔截器（如果有則生成）一并回傳給 DispatcherServlet
4. DispatcherServlet 呼叫 HandlerAdapter 處理器配接器
5. HandlerAdapter 經過配接器呼叫 具體處理器（Handler，也叫后端控制器）
6. Handler 執行完成回傳 ModelAndView
7. HandlerAdaper 將 Handler 執行結果 ModelAndView 回傳給 DispatcherServlet
8. DispatcherServlet 將 ModelAndView 傳給 ViewResolver 視圖決議器 進行決議
9. ViewResolver 決議后回傳具體 View
10. DispatcherServlet 對 view 進行 渲染視圖（即將模型資料填充至視圖中）
11. DispatcherServlet 回應用戶
你好，我是yltrcc，日常分享技術點滴，歡迎關注我：ylcoder
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/462927.html
標籤：其他
上一篇：Redis主從同步
下一篇：Unity制作一個小星球