前言

一直想著復盤下知識點，剛好趁著最近的間隙時間，進行一個簡單的階段系列小結(jié)，如下

======================================================================================================

--1、spring 的生命周期、ioc\aop (1)Spring的生命周期主要指創(chuàng)建、初始化、銷毀。Bean的生命周期主要由容器進行管理，我們可以自定義bean的初始化和銷毀方法，容器在bean進行到生命周期的特定時間點，來調(diào)用自定義的初始化和銷毀方法。 以下需結(jié)合項目以及實際生產(chǎn)的使用進行進一步的解釋 (2)ioc控制反轉(zhuǎn) (3)AOP面向切面 --2、int 和 integer的區(qū)別 兩者的區(qū)別主要體現(xiàn)在以下幾個方面： (1)數(shù)據(jù)類型不同：int 是基礎數(shù)據(jù)類型，而 Integer 是包裝數(shù)據(jù)類型； (2)默認值不同：int 的默認值是 0，而 Integer 的默認值是 null； (3)內(nèi)存中存儲的方式不同：int 在內(nèi)存中直接存儲的是數(shù)據(jù)值，而 Integer 實際存儲的是對象引用，當 new 一個 Integer 時實際上是生成一個指針指向此對象； (4)實例化方式不同：Integer 必須實例化才可以使用，而 int 不需要； (5)變量的比較方式不同：int 可以使用 == 來對比兩個變量是否相等，而 Integer 一定要使用 equals 來比較兩個變量是否相等。 --3、list的種類和區(qū)別 (1)作為共享變量時，存在線程安全問題，作為方法局部變量時，沒有線程安全問題 (2)ArrayList與LinkedList區(qū)別、ArrayList與Vector區(qū)別①底層數(shù)據(jù)結(jié)構(gòu)不同：ArrayList底層時數(shù)組 LinkedList是雙向鏈表，數(shù)據(jù)結(jié)構(gòu)不同導致api有所差異，比如新增A會計算并決定是否需要擴容，然后把新增的數(shù)據(jù)直接賦值到數(shù)組上；而L只需要改變插入節(jié)點與前后節(jié)點的指向關(guān)系即可②A常用于快速查詢匹配,L常用于新增與刪除，適合大量修改③Vector與ArrayList區(qū)別是V是線程安全的集合，在需要線程安全且對效率要求比較低的情況，使用Vector --4、Collections知識 ------------>原文鏈接：https://blog.csdn.net/qq_50692350/article/details/126292057 --5、map的種類與區(qū)別 Map類有：HashMap，LinkedHashMap，TreeMap (1)HashMap中k的值沒有順序，常用來做統(tǒng)計,key和value可以為空，同時是線程不安全的，存入和輸出的數(shù)據(jù)，順序可能發(fā)生變化。 (2)LinkedHashMap。它內(nèi)部有一個鏈表，保持Key插入的順序。迭代的時候，也是按照插入順序迭代，而且迭代比HashMap快，存入和輸出的數(shù)據(jù)，順序保持一致。 (3) TreeMap的順序是Key的自然順序（如整數(shù)從小到大），也可以指定比較函數(shù)。但不是插入的順序。 需要多說明一下：HashMap它的訪問時根據(jù)容器的大小進行訪問，如果容器過大，那么它訪問的時間也會變長，但是它訪問單個數(shù)據(jù)的速度要比LinkedHashMap要快，因為linkedHashMap是基于鏈表有前驅(qū)和后繼數(shù)據(jù)占的空間也比較大。LinkedHashMap是HashMap的一個子類。 --6、在JDK1.7和JDK1.8中HashMap有哪些不同 (1)1.8用了紅黑樹 (2)1.7用了頭插法，1.8是尾插法 (3)1.7會rehash，1.8沒有這個代碼邏輯，但他多了putIfAbsent(key,value) --7、spring cloud的用到了哪些 --8、項目中是如何處理分布式事務 --9、常用的linux指令 (1)cd /u01/page/ 進入文件路徑 (2)ll 查看當前路面下所有文件 (3)mv oisp-beijing-web.zip oisp-beijing-web$(date +%Y%m%d%H%M%S).zip zip重命名 (4)zip -p -r oisp-beijing-web.zip oisp-beijing-web/ 壓縮項目 (5)unzip -o oisp-beijing-web.zip 解壓 (6)history 查看歷史 (7)tail -f 日志.log 查看實時日志 (8)tail -f -n 100 日志文件名 查看日志后100行 --10、數(shù)據(jù)庫優(yōu)化有哪些 ------------>原文鏈接：https://blog.csdn.net/m0_72088858/article/details/126815713 (1)最左前綴法則： 如果使用多個列創(chuàng)建了組合索引，則必須滿足最左前綴法則才會使用索引，即查詢條件中使用了組合索引靠左邊的列就會使用索引，不能跳過組合索引的列。 ①例如： EXPLAIN SELECT * FROM tb_seller WHERE NAME = '小米科技' 這條查詢語句的條件使用了name,組合索引為:“name,status,address”，屬于組合索引靠左邊的列。 ②再比如: EXPLAIN SELECT * FROM tb_seller WHERE NAME = '小米科技' AND STATUS = 1 這條查詢語句的條件使用了name和status，屬于組合索引靠左邊的列。 ③再比如：EXPLAIN SELECT * FROM tb_seller WHERE NAME = '小米科技' AND STATUS = 1 AND address = '北京市' 這條查詢語句的條件使用了name,status和address屬于組合索引靠左邊的列。 這三條查詢語句都滿足最左前綴法則會使用索引。 再來看看不符合最左前綴法則的例子： ④例如：EXPLAIN SELECT * FROM tb_seller WHERE STATUS = 1 這條sql語句的查詢條件跳過了name,直接使用status不符合最左前綴法則EXPLAIN SELECT * FROM tb_seller WHERE STATUS = 1 AND address='北京市' 這條sql語句同樣跳過了name不符合最左前綴法則 如果查詢條件跳過了組合索引的某列則只有左邊的索引會生效 ⑤例如： EXPLAIN SELECT * FROM tb_seller WHERE NAME = '小米科技' AND address='北京市' 只有name上的索引會生效(2)范圍查詢右邊的列不能使用索引 例如： EXPLAIN SELECT * FROM tb_seller WHERE NAME = '小米科技' AND STATUS='1' AND address = '北京市' 這條sql語句會使用組合索引中的每一列： 下面這條sql語句使用了范圍查詢： EXPLAIN SELECT * FROM tb_seller WHERE NAME = '小米科技' AND STATUS>'1' AND address = '北京市' 索引只能使用name和status索引，不能使用address索引，因此key_len 為410 (3)如果在索引列上進行運算操作索引會失效： 例如： EXPLAIN SELECT * FROM tb_seller WHERE SUBSTRING(NAME,3,2) = '科技' 這個sql語句的索引列name使用了substring函數(shù)所以索引會失效。(4)字符串不加單引號會導致索引失效: 例如： EXPLAIN SELECT * FROM tb_seller WHERE NAME='科技' AND STATUS = '0' 字符串’0’加了單引號，會使用索引列name和status查詢EXPLAIN SELECT * FROM tb_seller WHERE NAME='科技' AND STATUS = '0' 如果使用下面的sql語句，0沒有加單引號，只會使用索引列name來查詢： EXPLAIN SELECT * FROM tb_seller WHERE NAME='科技' AND STATUS = 0(5)盡量使用覆蓋索引即查詢的列都是索引中的列避免使用 select * ： 例如： EXPLAIN SELECT NAME,STATUS FROM tb_seller WHERE NAME='科技' AND STATUS = '0' AND address='西安市' 效率比： EXPLAIN SELECT * FROM tb_seller WHERE NAME='科技' AND STATUS = '0' AND address='西安市' 要高。(6)用or分割開的條件當中只要有一個非索引列則不會使用索引： 例如： EXPLAIN SELECT NAME,STATUS FROM tb_seller WHERE STATUS = '0' OR PASSWORD='123' 會導致全表掃描(7)以%開頭的模糊查詢索引失效。 例如： EXPLAIN SELECT * FROM tb_seller WHERE NAME LIKE '%米' 這種情況可以采用覆蓋索引來解決： EXPLAIN SELECT NAME FROM tb_seller WHERE NAME = '小米科技' --11、說說項目使用到redis的地方 (1)保存一些通用參數(shù)表信息到redis方便即時查詢 (2)通過鎖獲取redis只增數(shù)生成指定業(yè)務批次號 --12、說說nginx的使用，配置文件有什么信息 (1)配置文件信息 nginx.conf的內(nèi)容分為以下幾段： main配置段：全局配置段。其中main配置段中可能包含event配置段 event {}：定義event模型工作特性 http {}：定義http協(xié)議相關(guān)的配置-----端口、服務地址 配置指令：要以分號結(jié)尾，語法格式如下： derective value1 [value2 …]; (2)作用;nginx錯誤日志地址配置，服務上傳地址，web指定跳轉(zhuǎn) --13、索引失效的原因有哪些 ------------>原文鏈接：https://www.cnblogs.com/xiaolincoding/p/15839040.html (1)當我們使用左或者左右模糊匹配的時候，也就是 like %xx 或者 like %xx%這兩種方式都會造成索引失效； (2)當我們在查詢條件中對索引列使用函數(shù)，就會導致索引失效。 (3)當我們在查詢條件中對索引列進行表達式計算，也是無法走索引的。 (4)MySQL 在遇到字符串和數(shù)字比較的時候，會自動把字符串轉(zhuǎn)為數(shù)字，然后再進行比較。如果字符串是索引列，而條件語句中的輸入?yún)?shù)是數(shù)字的話，那么索引列會發(fā)生隱式類型轉(zhuǎn)換，由于隱式類型轉(zhuǎn)換是通過 CAST 函數(shù)實現(xiàn)的，等同于對索引列使用了函數(shù)，所以就會導致索引失效。 (5)聯(lián)合索引要能正確使用需要遵循最左匹配原則，也就是按照最左優(yōu)先的方式進行索引的匹配，否則就會導致索引失效。 (6)在 WHERE 子句中，如果在 OR 前的條件列是索引列，而在 OR 后的條件列不是索引列，那么索引會失效。 (7)查詢條件中有 is null (8)查詢條件中有<> / not in / not exists --14、消息隊列用到了哪些 --15、數(shù)據(jù)遷移的過程是怎么處理的 --16、索引的底層原理 ------------>原文鏈接：https://blog.csdn.net/xxxcAxx/article/details/128197710 (1)索引是排好序的快速幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。 (2)優(yōu)點： ①提高數(shù)據(jù)檢索的效率，減少數(shù)據(jù)庫IO的成本； ②通過索引列對數(shù)據(jù)進行排序，降低數(shù)據(jù)排序的成本，降低CPU的消耗 (3)缺點： ①索引會占據(jù)磁盤空間 ②索引雖然會提高查詢效率，但是會降低更新表的效率。比如每次對表進行增刪改操作，MySQL不僅要保存數(shù)據(jù)，還有保存或者更新對應的索引文件。 ③創(chuàng)建索引和維護索引要耗費時間，這種時間隨著數(shù)據(jù)量的增加而增加 ④對表中的數(shù)據(jù)進行增、刪、改的時候，索引也要動態(tài)的維護，這就降低了整數(shù)的維護速度 ⑤如果某個數(shù)據(jù)列包含許多重復的內(nèi)容，為它建立索引就沒有太大的實際效果。 ⑥對于非常小的表，大部分情況下簡單的全表掃描更高效。 (4)索引的分類 根據(jù)索引的具體用途，MySQL 中的索引在邏輯上分為以下 5 類： ①普通索引（索引名：index） 普通索引是 MySQL 中最基本的索引類型，它沒有任何限制，唯一任務就是加快系統(tǒng)對數(shù)據(jù)的訪問速度。普通索引允許在定義索引的列中插入重復值和空值。 ②唯一索引（索引名：unique） 顧名思義，唯一索引就是專門為具有唯一約束字段創(chuàng)建的索引。當一個字段被設置唯一約束時，MySql會自動為此字段創(chuàng)建唯一索引。唯一索引列的值必須唯一，但允許有空值。 ③主鍵索引（索引名：primary key） 顧名思義，主鍵索引就是專門為主鍵字段創(chuàng)建的索引。當一個字段被設置為主鍵時，MySql會自動為此字段創(chuàng)建主鍵索引。主鍵索引是一種特殊的唯一索引，不允許值重復或者值為空。 ④全文索引（索引名：fulltext） 全文索引主要用來查找文本中的關(guān)鍵字，只能在 CHAR、VARCHAR 或 TEXT 類型的列上創(chuàng)建。在 MySQL 中只有 MyISAM 存儲引擎支持全文索引。 ⑤空間索引（索引名：spatial） 空間索引是對地理空間數(shù)據(jù)類型 GEOMETRY的字段建立的索引。創(chuàng)建空間索引的列必須將其聲明為 NOT NULL，空間索引只能在存儲引擎為 MyISAM 的表中創(chuàng)建。對于初學者來說，這類索引很少會用到。 --17、redis的優(yōu)勢 (1)單線程 (2)純內(nèi)存 KV (3)高效的數(shù)據(jù)結(jié)構(gòu)及合理的數(shù)據(jù)編碼 (4)同步非阻塞I/O——多路復用 --18、ob數(shù)據(jù)庫的底層原理 ------------>原文鏈接：https://blog.csdn.net/songyun333/article/details/125393117 (1)OB是分布式的關(guān)系型數(shù)據(jù)庫。 (2)部分節(jié)點故障后內(nèi)部自動切換恢復服務，不需要運維人員或工具產(chǎn)品介入。切換恢復時間在30s以內(nèi), 絕對不丟數(shù)據(jù)。 (3)有多（租戶）實例管理能力，集群資源作為一個池子，分出多個（租戶）實例給不同業(yè)務使用。 (4)極致的彈性伸縮能力。租戶擴容和縮容一個命令搞定，集群擴容和縮容也是一個命令搞定。彈性伸縮涉及到的負載均衡和數(shù)據(jù)遷移等事情都是數(shù)據(jù)庫內(nèi)部異步完成。 運維很方便。 (5)對硬件要求低。普通PC服務器，普通SSD盤（OB對SSD寫很友好，即隨機寫很少），千兆或萬兆網(wǎng)卡。不需要存儲、光纖，不需要小機。 (6)OB的數(shù)據(jù)壓縮能力也很強，16T的數(shù)據(jù)大概會壓縮到3T左右

總結(jié)

以上是生活随笔為你收集整理的阶段复盘与总结（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。