1. bootstrap.yml 用于配置nacos地址，用戶名，密碼，命名空間(相當(dāng)要先連接上nacos),然后才能拉去nacos上的配置文件信息; 
   
2. application.yml 文件用于配置在本地的配置文件(其實(shí)這個(gè)也可以放到nacos上)
   

   bootstrap配置文件是spring cloud新增的啟動(dòng)配置文件，需要引入spring-cloud-context依賴后，才會(huì)進(jìn)行加載(看spring cloud 2022版本以以前)。

   • bootstrap由父ApplicationContext加載，所以比application優(yōu)先加載

   • 因?yàn)閎ootstrap優(yōu)先于application加載，所以不會(huì)被覆蓋

   • 使用配置中心spring cloud config時(shí)，需要在bootstarp中配置配置中心的地址，從而實(shí)現(xiàn)父ApplicationContext加載時(shí)，從配置中心拉去相應(yīng)的配置到應(yīng)用中。

   它們加載順序：bootstrap.yaml文件生效后，去nacos拉去完配置信息后，與本地的application.yaml配置信息進(jìn)行合并，然后加載到spring容器中
   
   在springboot工程中使用基礎(chǔ)上使用兩個(gè)注釋：@RefreshScope 放在類上和@value 配置使用 
   
   要實(shí)現(xiàn)取值和動(dòng)態(tài)刷新通過實(shí)驗(yàn)證明使用@NacosValue是不行了，因?yàn)槭褂昧薙pring Cloud的依賴包，所以根據(jù)官方文檔顯示，要通過 Spring Cloud 原生注解 @RefreshScope + @Value 來實(shí)現(xiàn)配置自動(dòng)更新，我們可以用下面的方法達(dá)到同樣的效。
   nacos client 從服務(wù)端拉取配置信息會(huì)放到client 本地緩存起來 默認(rèn)目錄：${user}\nacos\config 下(拉到調(diào)試時(shí)候有用)
                           
   詳細(xì)文章 ：https://developer.aliyun.com/article/859891
   
   

InnoDB的鎖

InnoDB的行鎖：共享鎖、排他鎖、MDL鎖

共享鎖：又稱讀鎖、S鎖。一個(gè)事務(wù)獲取一個(gè)數(shù)據(jù)行的共享鎖，其他事務(wù)能獲取該行對(duì)應(yīng)的共享鎖，但不能獲得排他鎖；即一個(gè)事務(wù)在讀取一個(gè)數(shù)據(jù)行時(shí)，其他事務(wù)也可以讀，但不能對(duì)數(shù)據(jù)進(jìn)行增刪改查。

應(yīng)用：

1.自動(dòng)提交模式下的select查詢，不加任何鎖，直接返回查詢結(jié)果

2.通過select……lock in share mode在被讀取的行記錄或范圍上加一個(gè)讀鎖，其他事務(wù)可以讀，但是申請(qǐng)加寫鎖會(huì)被阻塞

排他鎖：又稱寫鎖、X鎖。一個(gè)事務(wù)獲取了一個(gè)數(shù)據(jù)行的寫鎖，其他事務(wù)就不能再獲取該行的其他鎖，寫鎖優(yōu)先級(jí)最高。

應(yīng)用：

1.一些DML操作會(huì)對(duì)行記錄加寫鎖

2.select for update會(huì)對(duì)讀取的行記錄上加一個(gè)寫鎖，其他任何事務(wù)都不能對(duì)鎖定的行加任何鎖，否則會(huì)被阻塞

MDL鎖：MySQL5.5引入，用于保證表中元數(shù)據(jù)的信息。在會(huì)話A中，表開啟了查詢事務(wù)后，會(huì)自動(dòng)獲得一個(gè)MDL鎖，會(huì)話B就不能執(zhí)行任何DDL語句的操作

行鎖實(shí)現(xiàn)方式

InnoDB 行鎖是通過給索引上的索引項(xiàng)加鎖來實(shí)現(xiàn)的，這一點(diǎn) MySQL 與 Oracle 不同，后者是 通過在數(shù)據(jù)塊中對(duì)相應(yīng)數(shù)據(jù)行加鎖來實(shí)現(xiàn)的。InnoDB 這種行鎖實(shí)現(xiàn)特點(diǎn)意味著:只有通過 索引條件檢索數(shù)據(jù)，InnoDB 才使用行級(jí)鎖，否則，InnoDB 將使用表鎖! 在實(shí)際應(yīng)用中，要特別注意 InnoDB 行鎖的這一特性，不然的話，可能導(dǎo)致大量的鎖沖突， 從而影響并發(fā)性能。

行鎖的三種算法

InnoDB 存儲(chǔ)引擎有三種行鎖的算法，其分別是：

• Record Lock: 單個(gè)行記錄上的鎖
• Gap Lock: 間隙鎖，鎖定一個(gè)范圍，但不包含記錄本身
• Next-Key 鎖: Gap Lock + Record Lock，鎖定一個(gè)范圍，并且會(huì)鎖定記錄本身

RC模式下只采用Record Lock，RR模式下采用了Next-Key

加鎖場(chǎng)景分析

• 主鍵索引

如果我們加鎖的行上存在主鍵索引，那么就會(huì)在這個(gè)主鍵索引上添加一個(gè) Record Lock。

• 輔助索引

如果我們加鎖的行上存在輔助索引，那么我們就會(huì)在這行的輔助索引上添加 Next-Key Lock，并在這行之后的輔助索引上添加一個(gè) Gap Lock

輔助索引上的 Next-Key Lock 和 Gap Lock 都是針對(duì) Repeatable Read 隔離模式存在的，這兩種鎖都是為了防止幻讀現(xiàn)象的發(fā)生。

• 唯一的輔助索引

這里有一個(gè)特殊情況，如果輔助索引是唯一索引的話，MySQL 會(huì)將 Next-Key Lock 降級(jí)為 Record Lock，只會(huì)鎖定當(dāng)前記錄的輔助索引。

如果唯一索引由多個(gè)列組成的，而我們只鎖定其中一個(gè)列的話，那么此時(shí)并不會(huì)進(jìn)行鎖降級(jí)，還會(huì)添加 Next-Key Lock 和 Gap Lock。

• Insert 語句

在 InnoDB 存儲(chǔ)引擎中，對(duì)于 Insert 的操作，其會(huì)檢查插入記錄的下一條記錄是否被鎖定，若已經(jīng)被鎖定，則不允許查詢。

意向鎖

意向鎖可以分為意向共享鎖(Intention Shared Lock, IS)和意向排他鎖(Intention eXclusive Lock, IX)。但它的鎖定方式和共享鎖和排他鎖并不相同，意向鎖上鎖只是表示一種“意向”,并不會(huì)真的將對(duì)象鎖住，讓其他事物無法修改或訪問。例如事物T1想要修改表test中的行r1，它會(huì)上兩個(gè)鎖:

1. 在表test上意向排他鎖
2. 在行r1上排他鎖

事物T1在test表上上了意向排他鎖，并不代表其他事物無法訪問test了，它上的鎖只是表明一種意向，它將會(huì)在db中的test表中的某幾行記錄上上一個(gè)排他鎖。

一致性非鎖定讀

一致性非鎖定讀是指 InnoDB 存儲(chǔ)引擎通過行多版本控制(multi version)的方式來讀取當(dāng)前執(zhí)行時(shí)間數(shù)據(jù)庫中行的數(shù)據(jù)。具體來說就是如果一個(gè)事務(wù)讀取的行正在被鎖定，那么它就會(huì)去讀取這行數(shù)據(jù)之前的快照數(shù)據(jù)，而不會(huì)等待這行數(shù)據(jù)上的鎖釋放。這個(gè)讀取流程如圖1所示:

行的快照數(shù)據(jù)是通過undo段來實(shí)現(xiàn)的，而undo段用來回滾事務(wù)，所以快照數(shù)據(jù)本身沒有額外的開銷。此外，讀取快照數(shù)據(jù)時(shí)不需要上鎖的，因?yàn)闆]有事務(wù)會(huì)對(duì)快照數(shù)據(jù)進(jìn)行更改。

MySQL 中并不是每種隔離級(jí)別都采用非一致性非鎖定讀的讀取模式，而且就算是采用了一致性非鎖定讀，不同隔離級(jí)別的表現(xiàn)也不相同。在 READ COMMITTED 和 REPEATABLE READ 這兩種隔離級(jí)別下，InnoDB存儲(chǔ)引擎都使用一致性非鎖定讀。但是對(duì)于快照數(shù)據(jù)，READ COMMITTED 隔離模式中的事務(wù)讀取的是當(dāng)前行最新的快照數(shù)據(jù)，而 REPEATABLE READ 隔離模式中的事務(wù)讀取的是事務(wù)開始時(shí)的行數(shù)據(jù)版本。

一致性鎖定讀

在 InnoDB 存儲(chǔ)引擎中，select語句默認(rèn)采取的是一致性非鎖定讀的情況，但是有時(shí)候我們也有需求需要對(duì)某一行記錄進(jìn)行鎖定再來讀取，這就是一致性鎖定讀。

InnoDB 對(duì)于select語句支持以下兩種鎖定讀:

• select ... for update
• select ... lock in share mode

select ... for update會(huì)對(duì)讀取的記錄加一個(gè)X鎖，其他事務(wù)不能夠再來為這些記錄加鎖。select ... lock in share mode會(huì)對(duì)讀取的記錄加一個(gè)S鎖，其它事務(wù)能夠再為這些記錄加一個(gè)S鎖，但不能加X鎖。

對(duì)于一致性非鎖定讀，即使行記錄上加了X鎖，它也是能夠讀取的，因?yàn)樗x取的是行記錄的快照數(shù)據(jù)，并沒有讀取行記錄本身。

select ... for update和select ... lock in share mode這兩個(gè)語句必須在一個(gè)事務(wù)中，當(dāng)事務(wù)提交了，鎖也就釋放了。因此在使用這兩條語句之前必須先執(zhí)行begin, start transaction，或者執(zhí)行set autocommit = 0。

InnoDB 在不同隔離級(jí)別下的一致性讀及鎖的差異

consisten read //一致性讀
share locks //共享鎖
Exclusive locks //排他鎖

在了解 InnoDB 鎖特性后，用戶可以通過設(shè)計(jì)和 SQL 調(diào)整等措施減少鎖沖突和死鎖，包括:

• 盡量使用較低的隔離級(jí)別;
• 精心設(shè)計(jì)索引，并盡量使用索引訪問數(shù)據(jù)，使加鎖更精確，從而減少鎖沖突的機(jī)會(huì);
• 選擇合理的事務(wù)大小， 小事務(wù)發(fā)生鎖沖突的幾率也更小;
• 給記錄集顯示加鎖時(shí)，最好一次性請(qǐng)求足夠級(jí)別的鎖。比如要修改數(shù)據(jù)的話，最好直接申請(qǐng)排他鎖，而不是先申請(qǐng)共享鎖，修改時(shí)再請(qǐng)求排他鎖，這樣容易產(chǎn)生死鎖;
• 不同的程序訪問一組表時(shí)，應(yīng)盡量約定以相同的順序訪問各表，對(duì)一個(gè)表而言，盡可能以固定的順序存取表中的行。這樣可以大大減少死鎖的機(jī)會(huì);
• 盡量用相等條件訪問數(shù)據(jù)，這樣可以避免間隙鎖對(duì)并發(fā)插入的影響;
• 不要申請(qǐng)超過實(shí)際需要的鎖級(jí)別;除非必須，查詢時(shí)不要顯示加鎖;
• 對(duì)于一些特定的事務(wù)，可以使用表鎖來提高處理速度或減少死鎖的可能。

參考資料

1.https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-intention-locks  mysql官網(wǎng)開發(fā)手冊(cè)

2.《MySQL 技術(shù)內(nèi)幕 – InnoDB 存儲(chǔ)引擎》

3.《深入淺出MySQL》

4.https://www.modb.pro/db/33873

整體架構(gòu)

1、三種方法

2、一個(gè)新注解@FunctionInterface

JDK 8 中 CompletableFuture 是對(duì) Future 的增強(qiáng) 大大簡化了異步編程步驟,在Spring 框架中配合@EnableAsync @Async 更加事辦功倍。

1:在JDK 8 之前實(shí)現(xiàn)多線必需實(shí)現(xiàn)兩個(gè)接口 Runnable 不帶返回值，另一個(gè)Callable帶返回值的接口,配合ThreadPoolTaskExecutor.submit(Callable callable) 返回一個(gè)Future對(duì)象。

使用Future獲得異步執(zhí)行結(jié)果時(shí)，要么調(diào)用阻塞方法get()，要么輪詢看isDone()是否為true，這兩種方法都不是很好，因?yàn)橹骶€程也會(huì)被迫等待，而CompletableFuture出現(xiàn)改變了這個(gè)問題，而且提供更多并且強(qiáng)大的其它功能。

2：CompletableFuture簡介

CompletableFuture<T> implements Future<T>, CompletionStage<T>

其實(shí)CompletableFuture 除了實(shí)現(xiàn)原來的Future 接口外，其它大部分方法都是在CompletionStage中


大致介紹下completableFuture的命名規(guī)則：

1:按功能分類的話：
xxx()：表示該方法將繼續(xù)在已有的線程中執(zhí)行；

xxxAsync()：表示將異步在線程池中執(zhí)行。

異步執(zhí)行方法默認(rèn)一個(gè)參數(shù)的話任務(wù)是在 ForkJoinPool.commonPool() 線程池中執(zhí)行的，帶executor 參數(shù)的使用 executor線程池異步執(zhí)行。

2:按邏輯和組織方式來分話(completableFuture 中大約有50個(gè)來方法)
一種是 then 的邏輯，即前一個(gè)計(jì)算完成的時(shí)候調(diào)度后一個(gè)計(jì)算

一種是 both 的邏輯，即等待兩個(gè)計(jì)算都完成之后執(zhí)行下一個(gè)計(jì)算，只要能組合一個(gè)和另一個(gè)，我們就可以無限復(fù)用這個(gè) +1 的邏輯組合任意多的計(jì)算

另一種是 either 的邏輯，即等待兩個(gè)計(jì)算的其中一個(gè)完成之后執(zhí)行下一個(gè)計(jì)算。注意這樣的計(jì)算可以說是非確定性的。因?yàn)楸唤M合的兩個(gè)計(jì)算中先觸發(fā)下一個(gè)計(jì)算執(zhí)行的那個(gè)會(huì)被作為前一個(gè)計(jì)算，而這兩個(gè)前置的計(jì)算到底哪一個(gè)先完成是不可預(yù)知的
3:從依賴關(guān)系和出入?yún)?shù)類型區(qū)別，基本分為三類：
apply 字樣的方式意味著組合方式是 Function，即接受前一個(gè)計(jì)算的結(jié)果，應(yīng)用函數(shù)之后返回一個(gè)新的結(jié)果

accept 字樣的方式意味著組合方式是 Consumer，即接受前一個(gè)計(jì)算的結(jié)果，執(zhí)行消費(fèi)后不返回有意義的值

run 字樣的方式意味著組合方式是 Runnable，即忽略前一個(gè)計(jì)算的結(jié)果，僅等待它完成后執(zhí)行動(dòng)作
其中出入?yún)?shù)主要有JDK8 Function，Consumer或Runnable三中函數(shù)型接口,每一種都決定了是怎么樣一種依賴關(guān)系,我有一篇文章詳細(xì)介紹了JDK8函數(shù)型接口用法，能有助理解completableFuture方法使用。
http://m.tkk7.com/zzzlyr/articles/435611.html
4:completableFuture 配合框架使用
  因?yàn)樽詮腏DK8以后增強(qiáng)了多線程的使用便捷程度：
  1：JDk8 的函數(shù)式接口和lambda表過式
  2：completableFuture 對(duì) Future 類的增強(qiáng)。
 這只是JDK 基礎(chǔ)包中的功能，現(xiàn)在大部分開發(fā)都在使用框架 java 現(xiàn)在基本上都在使用spring框架，因?yàn)镴DK基礎(chǔ)包中的功能還是不如框架使用方便，下邊文章詳細(xì)介紹 springboot中對(duì)JDK基礎(chǔ)包中多線程功能配置和使用。 
http://m.tkk7.com/zzzlyr/articles/435305.html