前言

一直想著復(fù)盤下知識(shí)點(diǎn)，剛好趁著最近的間隙時(shí)間，進(jìn)行一個(gè)簡單的階段系列小結(jié)，如下

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

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

總結(jié)

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

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