目錄

源碼學習系列之WebMvc自動配置原理筆記

@

web的自動配置在SpringBoot項目中是一個很重要的方面，實現代碼在spring-boot-autoconfigure工程里：

按照官方文檔的說法，SpringBoot官方的說法，Springboot的SpringMVC自動配置，主要提供了如下自動配置：

WebMvcAutoConfiguration.java這個類很關鍵，這個就是SpringBoot Springmvc自動配置的一個很關鍵的配置類

@Configuration(proxyBeanMethods = false)//指定WebMvcAutoConfiguration不代理方法
@ConditionalOnWebApplication(type = Type.SERVLET)//在web環境(selvlet)才會起效
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class })//系統有有Servlet，DispatcherServlet(Spring核心的分發器)，WebMvcConfigurer的情況，這個自動配置類才起效
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)//系統沒有WebMvcConfigurationSupport這個類的情況，自動配置起效
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE + 10)
@AutoConfigureAfter({ DispatcherServletAutoConfiguration.class, TaskExecutionAutoConfiguration.class,
        ValidationAutoConfiguration.class })
public class WebMvcAutoConfiguration {
....
}

翻下源碼，可以看到WebMvcAutoConfiguration自動配置類里還有一個WebMvcConfigurer類型的配置類，2.2.1版本是implements WebMvcConfigurer接口，1.+版本是extends WebMvcConfigurerAdapter

@Configuration(proxyBeanMethods = false)//定義為配置類
    @Import(EnableWebMvcConfiguration.class)//spring底層註解,將EnableWebMvcConfiguration加到容器
    @EnableConfigurationProperties({ WebMvcProperties.class, ResourceProperties.class })//使WebMvcProperties、ResourceProperties配置類生效
    @Order(0)
    public static class WebMvcAutoConfigurationAdapter implements WebMvcConfigurer {
    ....
}

1、ContentNegotiatingViewResolver

如圖，是視圖解析器的自動配置，這個類起效的情況是系統沒有ContentNegotiatingViewResolver類的情況，就調用改方法自動創建ContentNegotiatingViewResolver類

關鍵的是ContentNegotiatingViewResolver類，翻下ContentNegotiatingViewResolver類，找到如下重要的初始化方法

@Override
    protected void initServletContext(ServletContext servletContext) {
    //調用Spring的BeanFactoryUtils掃描容器里的所有視圖解析器ViewResolver類
        Collection<ViewResolver> matchingBeans =
                BeanFactoryUtils.beansOfTypeIncludingAncestors(obtainApplicationContext(), ViewResolver.class).values();
        if (this.viewResolvers == null) {
            this.viewResolvers = new ArrayList<>(matchingBeans.size());
            //遍歷候選的viewResolvers，封裝到this.viewResolvers列表
            for (ViewResolver viewResolver : matchingBeans) {
                if (this != viewResolver) {
                    this.viewResolvers.add(viewResolver);
                }
            }
        }
        else {
            for (int i = 0; i < this.viewResolvers.size(); i++) {
                ViewResolver vr = this.viewResolvers.get(i);
                if (matchingBeans.contains(vr)) {
                    continue;
                }
                String name = vr.getClass().getName() + i;
                obtainApplicationContext().getAutowireCapableBeanFactory().initializeBean(vr, name);
            }

        }
        AnnotationAwareOrderComparator.sort(this.viewResolvers);
        this.cnmFactoryBean.setServletContext(servletContext);
    }

所以ContentNegotiatingViewResolver類的作用就是組合所有的視圖解析器，自動配置了ViewResolver(視圖解析器作用，根據方法返回值得到視圖對象view)

往下翻代碼，可以看到resolveViewName方法，裏面代碼是從this.viewResolvers獲取候選的視圖解析器，遍歷容器里所有視圖，然後通過如圖所標記的獲取候選視圖的方法，獲取候選的視圖列表，再通過getBestView獲取最合適的視圖

遍歷所有的視圖解析器對象，從視圖解析器里獲取候選的視圖，封裝成list保存

ok，跟了源碼就是只要將視圖解析器丟到Spring容器里，就可以加載到

寫個簡單的視圖解析類

DispatcherServlet是Spring核心分發器，找到doDispatch方法，debug，可以看到加的視圖解析器加載到了

2、靜態資源

也就是官方說的，如下圖所示：

翻譯過來就是支持靜態資源包括webjars的自動配置，webjars，就是以maven等等方式打成jar包的靜態資源，可以去看看文檔：

使用的話，直接去webjars官網負責對應的配置，加到項目里就可以

路徑都是在META-INF/webjars/**

WebMvcAutoConfiguration.addResourceHandlers，這個是比較重要的資源配置方法

@Override
        public void addResourceHandlers(ResourceHandlerRegistry registry) {
            if (!this.resourceProperties.isAddMappings()) {
                logger.debug("Default resource handling disabled");
                return;
            }
            Duration cachePeriod = this.resourceProperties.getCache().getPeriod();
            //CacheControl是Spring框架提供的http緩存
            CacheControl cacheControl = this.resourceProperties.getCache().getCachecontrol().toHttpCacheControl();
            //讀取到webjars資源，將classpath:/META-INF/resources/webjars/的webjars資源都掃描出來
            if (!registry.hasMappingForPattern("/webjars/**")) {
                customizeResourceHandlerRegistration(registry.addResourceHandler("/webjars/**")
                        .addResourceLocations("classpath:/META-INF/resources/webjars/")
                        .setCachePeriod(getSeconds(cachePeriod)).setCacheControl(cacheControl));
            }
            String staticPathPattern = this.mvcProperties.getStaticPathPattern();
            if (!registry.hasMappingForPattern(staticPathPattern)) {
                customizeResourceHandlerRegistration(registry.addResourceHandler(staticPathPattern)
                        .addResourceLocations(getResourceLocations(this.resourceProperties.getStaticLocations()))
                        .setCachePeriod(getSeconds(cachePeriod)).setCacheControl(cacheControl));
            }
        }

ok，通過源碼可以知道，Springboot支持webjars和其它等等靜態資源，其它的靜態資源要放在如下目錄里，Springboot就能自動加載到

• classpath:/META-INF/resources/
• classpath:/resources/
• classpath:/static/
• classpath:/public/
• classpath:/

3、自動註冊 Converter, GenericConverter, and Formatter beans.

翻譯過來就是自動註冊了 Converter, GenericConverter, and Formatter beans.

• Converter：轉換器 ，作用就是能自動進行類型轉換
  eg： public String hello(User user)，這是一個方法，然後前端視圖傳來的參數通過轉換器能夠根據屬性進行映射，然後進行屬性類型轉換
• Formatter ：格式化器，eg：比如對前端傳來的日期2019/11/25，進行格式化處理

源碼在這裏，WebMvcAutoConfiguration.addFormatters方法是添加格式化器的方法

同理，也是從Spring容器里將這幾種類拿過來

當然，還有其它的，比如WebMvcAutoConfiguration.localeResolver方法是實現i18n國際化語言支持的自動配置

@Bean
        @ConditionalOnMissingBean//沒有自定義localeResolver的情況
        @ConditionalOnProperty(prefix = "spring.mvc", name = "locale")//application.properties有配置了spring.mvc.locale
        public LocaleResolver localeResolver() {
            if (this.mvcProperties.getLocaleResolver() == WebMvcProperties.LocaleResolver.FIXED) {
                return new FixedLocaleResolver(this.mvcProperties.getLocale());
            }
            //默認使用AcceptHeaderLocaleResolver 
            AcceptHeaderLocaleResolver localeResolver = new AcceptHeaderLocaleResolver();
            localeResolver.setDefaultLocale(this.mvcProperties.getLocale());
            return localeResolver;
        }

具體的源碼參考我之前博客：，博客裏面有涉及源碼的

4、支持HttpMessageConverters

HttpMessageConverters ：消息轉換器，Springmvc中用來轉換http請求和響應的

源碼里是通過configureMessageConverters方法實現，很顯然也是從容器里獲取的

官方文檔里也進行了比較詳細描述，Springboot已經為我們自動配置了json的、xml的自動轉換器，當然你也可以自己添加

5、支持MessageCodesResolver

MessageCodesResolver：是消息解析器，WebMvcAutoConfiguration.getMessageCodesResolver是實現Exception異常信息格式的

WebMvcProperties配置文件定義的一個異常枚舉值

格式為如圖所示，定了了錯誤代碼是生成規則：

6、首頁支持

Springboot默認的首頁是index.html，也就是你在classpath路徑丟個index.html文件，就被Springboot默認為首頁，或者說歡迎頁

如圖示代碼，就是遍歷靜態資源文件，然後獲取index.html作為歡迎頁面

7、網站logo設置

Springboot1.+版本，是有默認的logo圖標的，2.2.1版本，經過全局搜索，沒有發現給自定義的圖標，使用的話，是直接丟在classpath路徑，文件命名為favicon.ico，不過在2.2.1代碼並沒有找到相應的配置代碼，1.+版本是有的，不過文檔還是有描述了

8、ConfigurableWebBindingInitializer 初始綁定器

跟下源碼，也是從Spring容器里獲取的，然後注意到，如果沒有這個ConfigurableWebBindingInitializer ，代碼就會調用基類的getConfigurableWebBindingInitializer

源碼，這裏也是創建一個getConfigurableWebBindingInitializer

ConfigurableWebBindingInitializer 是Springboot為系統自動配置的，當然我們也可以自己定義一個ConfigurableWebBindingInitializer ，然後加載到容器里即可

初始化綁定的方法，ok，本博客簡單跟一下源碼

注意：
ok，Springboot官方文檔里還有這樣的描述，如圖所示

意思是，在使用webmvcConfigurer配置的時候，不要使用@EnableWebMvc註解，為什麼不要使用呢？因為使用了@EnableWebMvc，就是實現全面接管SpringMVC自動配置，也就是說其它的自動配置都會失效，全部自己配置

原理是為什麼？可以簡單跟一下源碼，如圖，SpringMVC自動配置類，有這個很關鍵的註解，這個註解的意思是@WebMvcConfigurationSupport註解不在系統時候自動配置才起效

然後為什麼加了@EnableWebMvc自動配置就可以被全面接管？點一下@EnableWebMvc源碼

很顯然，DelegatingWebMvcConfiguration類extends WebMvcConfigurationSupport類，所以這也就是為什麼@EnableWebMvc註解能實現全面接管自動配置的原理

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

ceph中rbd的增量備份和恢復

ceph的文檔地址：

​ 在調研OpenStack中虛機的備份和恢復時，發現OpenStack和ceph緊密結合，使用ceph做OpenStack的後端簡直是不要太爽，於是調研了使用ceph中的塊設備rbd來對虛機進行增量備份和恢復。以下是虛機備份和恢復的實驗步驟：

1. 前言：

​ 快照的功能一般是基於時間點做一個標記，然後在某些需要的時候，將狀態恢復到標記的那個點，這個有一個前提是底層的數據沒有破壞，舉個簡單的例子，Vmware 裏面對虛擬機做了一個快照，然後做了一些系統的操作，想恢復快照，前提是存儲快照的存儲系統沒用破壞，一旦破壞了是無法恢復的。

​ ceph也有快照功能，同樣，在這裏的快照是用來保存存儲系統上的狀態的，數據的快照能成功恢復的前提是存儲系統是好的，而一旦存儲系統壞了，快照同時會失效的，所以最好是能夠將數據備份下來。本篇博客主要是調研使用ceph的rbd命令來對存儲設備進行基於快照的增量備份。

2. ceph中rbd的常用命令：

2.1列出存儲池

ceph osd pool ls

2.2 查看存儲池的內容

rbd ls --pool pool_name
例子
rbd ls --pool volumes

2.3 打快照

rbd snap create {pool-name}/{image-name}@{snap-name}
例如
rbd snap create volumes/volume-c18b9782-dc71-4ddc-bb7f-bc0037105ac3@v1

2.4 羅列快照

rbd snap ls {pool-name}/{image-name}
例如：
rbd snap ls volumes/volume-c18b9782-dc71-4ddc-bb7f-bc0037105ac3

2.5 創建image

rbd create --size {pool-name}/{image-name}

3. Nova實例的備份與恢復

以ceph做後端，在創建實例時，需要選擇一個系統盤，系統盤即是我們的目標數據盤。

備份實驗步驟：

1. 創建虛機。
2. 在時間點v1對虛機打快照。
3. 導出從開始創建image到快照v1那個時間點的差異數據，可以視為全量備份。
4. 使用dd命令寫入文件test.txt
5. 在時間點v2對虛機打快照。
6. 導出從開始創建image到快照v2那個時間點的差異數據，可以視為全量備份。
7. 導出了從v1快照時間點到v2快照時間點的差異數據，可以視為增量備份。

上文實驗過程的數據：

v1時間點數據 + v1_v2之間數據 = v2 時間點數據

虛機的備份

1. 實例第一次快照：

rbd snap create volumes/volume-c18b9782-dc71-4ddc-bb7f-bc0037105ac3@v1

2. 第一次全量備份：

rbd export-diff volumes/volume-c18b9782-dc71-4ddc-bb7f-bc0037105ac3@v1 testimage_v1

這個命令是導出了從開始創建image到快照v1那個時間點的差異數據導出來了testimage_v1，導出成本地文件testimage_v1

3. 寫入文件

dd

寫入文件，以此显示出v1和v2之間的數據變化，並沒有其他作用。

4. 實例第二次快照

rbd snap create volumes/volume-c18b9782-dc71-4ddc-bb7f-bc0037105ac3@v2

5. 第二次全量備份：

rbd export-diff volumes/volume-c18b9782-dc71-4ddc-bb7f-bc0037105ac3@v2  testimage_v2

這個命令是導出了從開始創建image到快照v2那個時間點的差異數據導出來了testimage_v2，導出成本地文件testimage_v2

6. 增量備份

增量備份（第二次和第一次的差異文件）：

rbd export-diff volumes/volume-c18b9782-dc71-4ddc-bb7f-bc0037105ac3@v2 --from-snap v1 testimage_v1_v2

這個命令是導出了從v1快照時間點到v2快照時間點的差異數據，導出成本地文件testimage_v1_v2

注意：

rbd export-diff rbd/testimage testimage_now

這個是導出了從image創建到當前的時間點的差異數據。

虛機恢復

虛機的恢復過程使用的是剛剛上面提到的備份到本地的那些文件。

1.創建塊設備映像

2.將testimage_v1融入塊設備，恢復v1時間的狀態

3.將testimage_v2融入塊設備，恢復v2時間狀態

4.在2基礎上將v1_v2融入塊設備，恢復至v2時間狀態

上述實驗是全量恢復和增量恢復的兩種狀態。下文將詳細總結項目中增量備份和恢復的使用過程。

1. 創建塊設備映像image

首先隨便創建一個image,名稱大小都不限制，因為後面恢復的時候會覆蓋掉大小的信息

rbd create --size 2048 backups/testbacknew

2. 基於v2的時間點的快照做恢復

2.1 基於V2恢復

直接基於v2的時間點的快照做恢復

rbd import-diff testimage_v2 rbd/testbacknew

2.2 基於v1+ v1_v2數據恢復

直接基於v1的時間點的數據，和後面的增量的v1_v2數據(要按順序導入)

rbd import-diff testimage_v1 backups/testbacknew
rbd import-diff testimage_v1_v2 backups/testbacknew

​ 實際項目當中就是，定期做快照，然後導出某個時間點快照的數據，然後導出增量的快照的數據，就可以了

4. 實際使用

​ 在實際項目中使用就是，定期做快照，然後導出某個時間點快照的數據，然後導出增量的快照的數據。

例如：

備份：

​ 對所有的rbd的image做一個基礎快照，然後導出這個快照的數據，然後設置每天定時做快照，導出快照時間點之間的數據，這樣每天導出來的就是一個增量的數據了。

​ 設置循環周期，比如三天為一個周期。每三天循環一次，自動刪除三天前的備份。

恢復：

​ 從第一個快照導入，然後按照順序導入增量的快照即可。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

1. goroutine的使用

　　在Go語言中，表達式go f(x, y, z)會啟動一個新的goroutine運行函數f(x, y, z)，創建一個併發任務單元。即go關鍵字可以用來開啟一個goroutine(協程))進行任務處理。

　　創建單個goroutine

 1 package main
 2 
 3 import (
 4     "fmt"
 5 )
 6 
 7 func HelloWorld() {
 8     fmt.Println("Hello goroutine")
 9 }
10 
11 func main() {
12     go HelloWorld()      // 開啟一個新的併發運行
       time.Sleep(1*time.Second)
13     fmt.Println("后輸出消息！")
14 }

　　輸出

1 Hello goroutine
2 后輸出消息！

　　這裏的sleep是必須的，否則你可能看不到goroutine裡頭的輸出,或者裏面的消息后輸出。因為當main函數返回時，所有的gourutine都是暴力終結的，然後程序退出。

　　創建多個goroutine時

 1 package main
 2 
 3 import (
 4     "fmt"
 5     "time"
 6 )
 7 
 8 func DelayPrint() {
 9     for i := 1; i <= 3; i++ {
10         time.Sleep(500 * time.Millisecond)
11         fmt.Println(i)
12     }
13 }
14 
15 func HelloWorld() {
16     fmt.Println("Hello goroutine")
17 }
18 
19 func main() {
20     go DelayPrint()     // 第一個goroutine
21     go HelloWorld()     // 第二個goroutine
22     time.Sleep(10*time.Second)
23     fmt.Println("main func")
24 }

　　輸出

1 Hello  goroutine
2 1
3 2
4 3
5 4
6 
7 main func

　　當去掉 DelayPrint() 函數里的sleep之後，輸出為：

1 1
2 2
3 3
4 4
5 Hello goroutine
6 main function

　　說明第二個goroutine不會因為第一個而堵塞或者等待。事實是當程序執行go FUNC()的時候，只是簡單的調用然後就立即返回了，並不關心函數裡頭發生的故事情節，所以不同的goroutine直接不影響，main會繼續按順序執行語句。

goroutine阻塞

　　場景一：

1 package main
2 
3 func main() {
4     ch := make(chan int)
5     <- ch // 阻塞main goroutine, 通道被鎖
6 }

　　運行程序會報錯：

1 fatal error: all goroutines are asleep - deadlock!
2 
3 goroutine 1 [chan receive]:
4 main.main()

　　場景二

 1 package main
 2 
 3 func main() {
 4     ch1, ch2 := make(chan int), make(chan int)
 5 
 6     go func() {
 7         ch1 <- 1 // ch1通道的數據沒有被其他goroutine讀取走，堵塞當前goroutine
 8         ch2 <- 0
 9     }()
10 
11     <- ch2 // ch2 等待數據的寫
12 }

　　非緩衝通道上如果只有數據流入，而沒有流出，或者只流出無流入，都會引起阻塞。 goroutine的非緩衝通道裡頭一定要一進一出，成對出現。 上面例子，一：流出無流入；二：流入無流出。

　　處理方式：

　　1. 讀取通道數據

 1 package main
 2 
 3 func main() {
 4     ch1, ch2 := make(chan int), make(chan int)
 5 
 6     go func() {
 7         ch1 <- 1 // ch1通道的數據沒有被其他goroutine讀取走，堵塞當前goroutine
 8         ch2 <- 0
 9     }()
10 
11     <- ch1 // 取走便是
12     <- ch2 // chb 等待數據的寫
13 }

　　2. 創建緩衝通道

 1 package main
 2 
 3 func main() {
 4     ch1, ch2 := make(chan int, 3), make(chan int)
 5 
 6     go func() {
 7         ch1 <- 1 // cha通道的數據沒有被其他goroutine讀取走，堵塞當前goroutine
 8         ch2 <- 0
 9     }()
10 
11     <- ch2 // ch2 等待數據的寫
12 }

2. goroutine調度器相關結構

　　goroutine的調度涉及到幾個重要的數據結構，我們先逐一介紹和分析這幾個數據結構。這些數據結構分別是結構體G，結構體M，結構體P，以及Sched結構體。前三個的定義在文件runtime/runtime.h中，而Sched的定義在runtime/proc.c中。Go語言的調度相關實現也是在文件proc.c中。

2.1 結構體G

　　g是goroutine的縮寫，是goroutine的控制結構，是對goroutine的抽象。看下它內部主要的一些結構：

 1 type g struct {
 2    //堆棧參數。
 3      //堆棧描述了實際的堆棧內存：[stack.lo，stack.hi）。
 4      // stackguard0是在Go堆棧增長序言中比較的堆棧指針。
 5      //通常是stack.lo + StackGuard，但是可以通過StackPreempt觸發搶佔。
 6      // stackguard1是在C堆棧增長序言中比較的堆棧指針。
 7      //它是g0和gsignal堆棧上的stack.lo + StackGuard。
 8      //在其他goroutine堆棧上為〜0，以觸發對morestackc的調用（並崩潰）。

 9   //當前g使用的棧空間，stack結構包括 [lo, hi]兩個成員
10     stack       stack   // offset known to runtime/cgo

11   // 用於檢測是否需要進行棧擴張，go代碼使用
12     stackguard0 uintptr // offset known to liblink

13   // 用於檢測是否需要進行棧擴展，原生代碼使用的
14     stackguard1 uintptr // offset known to liblink

15   // 當前g所綁定的m
16     m              *m      // current m; offset known to arm liblink

17   // 當前g的調度數據，當goroutine切換時，保存當前g的上下文，用於恢復
18     sched          gobuf

19     // goroutine運行的函數
20     fnstart        *FuncVal        
21     // g當前的狀態
22     atomicstatus   uint32
23   // 當前g的id
24     goid           int64

25      // 狀態Gidle,Grunnable,Grunning,Gsyscall,Gwaiting,Gdead
26     status   int16

27   // 下一個g的地址，通過guintptr結構體的ptr set函數可以設置和獲取下一個g，通過這個字段和sched.gfreeStack sched.gfreeNoStack 可以把 free g串成一個鏈表
28     schedlink      guintptr

29   // 判斷g是否允許被搶佔
30     preempt        bool       // preemption signal, duplicates stackguard0 = stackpreempt

31     // g是否要求要回到這個M執行, 有的時候g中斷了恢復會要求使用原來的M執行
32     lockedm        muintptr

33     // 用於傳遞參數，睡眠時其它goroutine設置param，喚醒時此goroutine可以獲取
       param  *void

34    // 創建這個goroutine的go表達式的pc
35    uintptr    gopc
36 }

　　其中包含了棧信息stackbase和stackguard，有運行的函數信息fnstart。這些就足夠成為一個可執行的單元了，只要得到CPU就可以運行。goroutine切換時，上下文信息保存在結構體的sched域中。goroutine切換時，上下文信息保存在結構體的sched域中。goroutine是輕量級的線程或者稱為協程，切換時並不必陷入到操作系統內核中，很輕量級。

　　結構體G中的Gobuf，其實只保存了當前棧指針，程序計數器，以及goroutine自身。

1 struct Gobuf
2 {
3     //這些字段的偏移是libmach已知的（硬編碼的）。
4     sp   uintper;
5     pc   *byte;
6     g    *G;
7     ...
8 };

　　記錄g是為了恢復當前goroutine的結構體G指針，運行時庫中使用了一個常駐的寄存器extern register G* g，這是當前goroutine的結構體G的指針。這種結構是為了快速地訪問goroutine中的信息，比如，Go的棧的實現並沒有使用%ebp寄存器，不過這可以通過g->stackbase快速得到。”extern register”是由6c，8c等實現的一個特殊的存儲，在ARM上它是實際的寄存器。在linux系統中，對g和m使用的分別是0(GS)和4(GS)。鏈接器還會根據特定操作系統改變編譯器的輸出，每個鏈接到Go程序的C文件都必須包含runtime.h頭文件，這樣C編譯器知道避免使用專用的寄存器。

2.2 結構體P

　　P是Processor的縮寫。結構體P的加入是為了提高Go程序的併發度，實現更好的調度。M代表OS線程。P代表Go代碼執行時需要的資源。

 1 type p struct {
 2    lock mutex
 3 
 4    id          int32
 5    // p的狀態，稍後介紹
 6    status      uint32 // one of pidle/prunning/...
 7 
 8    // 下一個p的地址，可參考 g.schedlink
 9    link        puintptr
10    // p所關聯的m
11    m           muintptr   // back-link to associated m (nil if idle)
12 
13    // 內存分配的時候用的，p所屬的m的mcache用的也是這個
14    mcache      *mcache
15   
16    // Cache of goroutine ids, amortizes accesses to runtime·sched.goidgen.
17    // 從sched中獲取並緩存的id，避免每次分配goid都從sched分配
18      goidcache    uint64
19      goidcacheend uint64
20 
21    // Queue of runnable goroutines. Accessed without lock.
22    // p 本地的runnbale的goroutine形成的隊列
23    runqhead uint32
24    runqtail uint32
25    runq     [256]guintptr
26 
27    // runnext，如果不是nil，則是已準備好運行的G
28    //當前的G，並且應該在下一個而不是其中運行
29    // runq，如果運行G的時間還剩時間
30    //切片。它將繼承當前時間剩餘的時間
31    //切片。如果一組goroutine鎖定在
32    //交流等待模式，該計劃將其設置為
33    //單位並消除（可能很大）調度
34    //否則會由於添加就緒商品而引起的延遲
35    // goroutines到運行隊列的末尾。
36 
37    // 下一個執行的g，如果是nil，則從隊列中獲取下一個執行的g
38    runnext guintptr
39 
40    // Available G's (status == Gdead)
41    // 狀態為 Gdead的g的列表，可以進行復用
42    gfree    *g
43    gfreecnt int32
44 }

　　跟G不同的是，P不存在waiting狀態。MCache被移到了P中，但是在結構體M中也還保留着。在P中有一個Grunnable的goroutine隊列，這是一個P的局部隊列。當P執行Go代碼時，它會優先從自己的這個局部隊列中取，這時可以不用加鎖，提高了併發度。如果發現這個隊列空了，則去其它P的隊列中拿一半過來，這樣實現工作流竊取的調度。這種情況下是需要給調用器加鎖的。

2.3 結構體M

　　M是machine的縮寫，是對機器的抽象，每個m都是對應到一條操作系統的物理線程。

 1 type m struct {
 2      // g0是用於調度和執行系統調用的特殊g
 3    g0      *g             // goroutine with scheduling stack
 4      // m當前運行的g
 5    curg    *g             // current running goroutine
 6    // 當前擁有的p
 7    p        puintptr      // attached p for executing go code (nil if not executing go code)

 8    // 線程的 local storage
 9    tls      [6]uintptr    // thread-local storage
10    // 喚醒m時，m會擁有這個p
11    nextp         puintptr
12    id            int64
13    // 如果 !="", 繼續運行curg
14    preemptoff    string   // if != "", keep curg running on this m

15    // 自旋狀態，用於判斷m是否工作已結束，並尋找g進行工作
16    spinning      bool     // m is out of work and is actively looking for work

17    // 用於判斷m是否進行休眠狀態
18    blocked       bool     // m is blocked on a note
19    // m休眠和喚醒通過這個，note裏面有一個成員key，對這個key所指向的地址進行值的修改，進而達到喚醒和休眠的目的
20    park          note

21    // 所有m組成的一個鏈表
22    alllink       *m       // on allm
23    // 下一個m，通過這個字段和sched.midle 可以串成一個m的空閑鏈表
24    schedlink     muintptr
25    // mcache，m擁有p的時候，會把自己的mcache給p
26    mcache        *mcache
27    // lockedm的對應值
28    lockedg       guintptr
29    // 待釋放的m的list，通過sched.freem 串成一個鏈表
30    freelink      *m      // on sched.freem
31 }

　　和G類似，M中也有alllink域將所有的M放在allm鏈表中。lockedg是某些情況下，G鎖定在這個M中運行而不會切換到其它M中去。M中還有一個MCache，是當前M的內存的緩存。M也和G一樣有一個常駐寄存器變量，代表當前的M。同時存在多個M，表示同時存在多個物理線程。

2.4 Sched結構體

　　Sched是調度實現中使用的數據結構，該結構體的定義在文件proc.c中。

 1 type schedt struct {
 2    // 全局的go id分配
 3    goidgen  uint64
 4    // 記錄的最後一次從i/o中查詢g的時間
 5    lastpoll uint64
 6 
 7    lock mutex
 8 
 9    //當增加nmidle，nmidlelocked，nmsys或nmfreed時，應
10    //確保調用checkdead（）。
11 
12      // m的空閑鏈表，結合m.schedlink 就可以組成一個空閑鏈表了
13    midle        muintptr // idle m's waiting for work
14    nmidle       int32    // number of idle m's waiting for work
15    nmidlelocked int32    // number of locked m's waiting for work
16    // 下一個m的id，也用來記錄創建的m數量
17    mnext        int64    // number of m's that have been created and next M ID
18    // 最多允許的m的數量
19    maxmcount    int32    // maximum number of m's allowed (or die)
20    nmsys        int32    // number of system m's not counted for deadlock
21    // free掉的m的數量，exit的m的數量
22    nmfreed      int64    // cumulative number of freed m's
23 
24    ngsys uint32 // 系統goroutine的數量；原子更新
25 
26    pidle      puintptr // 閑置的
27    npidle     uint32
28    nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.
29 
30    // Global runnable queue.
31    // 這個就是全局的g的隊列了，如果p的本地隊列沒有g或者太多，會跟全局隊列進行平衡
32    // 根據runqhead可以獲取隊列頭的g，然後根據g.schedlink 獲取下一個，從而形成了一個鏈表
33    runqhead guintptr
34    runqtail guintptr
35    runqsize int32
36 
37    // freem是m等待被釋放時的列表
38    //設置了m.exited。通過m.freelink鏈接。
39 
40    // 等待釋放的m的列表
41    freem *m
42 }

　　大多數需要的信息都已放在了結構體M、G和P中，Sched結構體只是一個殼。可以看到，其中有M的idle隊列，P的idle隊列，以及一個全局的就緒的G隊列。Sched結構體中的Lock是非常必須的，如果M或P等做一些非局部的操作，它們一般需要先鎖住調度器。

3. G、P、M相關狀態

g.status

• _Gidle: goroutine剛剛創建還沒有初始化
• _Grunnable: goroutine處於運行隊列中，但是還沒有運行，沒有自己的棧
• _Grunning: 這個狀態的g可能處於運行用戶代碼的過程中，擁有自己的m和p
• _Gsyscall: 運行systemcall中
• _Gwaiting: 這個狀態的goroutine正在阻塞中，類似於等待channel
• _Gdead: 這個狀態的g沒有被使用，有可能是剛剛退出，也有可能是正在初始化中
• _Gcopystack: 表示g當前的棧正在被移除，新棧分配中

goroutine的狀態變化

　　在newproc1中新建的goroutine被設置為Grunnable狀態，投入運行時設置成Grunning。Grunning狀態的goroutine會在entersyscall的時候goroutine的狀態被設置為Gsyscall，到出系統調用時根據它是從阻塞系統調用中出來還是非阻塞系統調用中出來，又會被設置成Grunning或者Grunnable的狀態。在goroutine最終退出的runtime.exit函數中，goroutine被設置為Gdead狀態。還會在進行I/O時可能會進入waiting狀態，主動讓出CPU，此時會被移到所屬P中的其他G後面，等待下一次輪到執行。

p.status

• _Pidle: 空閑狀態，此時p不綁定m
• _Prunning: m獲取到p的時候，p的狀態就是這個狀態了，然後m可以使用這個p的資源運行g
• _Psyscall: 當go調用原生代碼，原生代碼又反過來調用go的時候，使用的p就會變成此態
• _Pdead: 當運行中，需要減少p的數量時，被減掉的p的狀態就是這個了

m.status

m的status沒有p、g的那麼明確，但是在運行流程的分析中，主要有以下幾個狀態

• 運行中: 拿到p，執行g的過程中
• 運行原生代碼: 正在執行原聲代碼或者阻塞的syscall
• 休眠中: m發現無待運行的g時，進入休眠，並加入到空閑列表中
• 自旋中(spining): 當前工作結束，正在尋找下一個待運行的g

4. G、P、M的調度關係

　　一個G就是一個gorountine，保存了協程的棧、程序計數器以及它所在M的信息。P全稱是Processor，處理器，它的主要用途就是用來執行goroutine的。M代表內核級線程，一個M就是一個線程，goroutine就是跑在M之上的。程序啟動時，會創建一個主G，而每使用一次go關鍵字也創建一個G。go func()創建一個新的G后，放到P的本地隊列里，或者平衡到全局隊列，然後檢查是否有可用的M，然後喚醒或新建一個M，M獲取待執行的G和空閑的P，將調用參數保存到g的棧，將sp，pc等上下文環境保存在g的sched域，這樣整個goroutine就準備好了，只要等分配到CPU，它就可以繼續運行，之後再清理現場，重新進入調度循環。

4.1 調度實現

　　圖中有兩個物理線程，M0、M1每一個M都擁有一個處理器P，每一個P都有一個正在運行的G。P的數量可以通過GOMAXPROCS()來設置，它其實也代表了真正的併發度，即有多少個goroutine可以同時運行。圖中灰色goroutine都是處於ready的就緒態，正在等待被調度。由P維護這個就緒隊列（runqueue），go function每啟動一個goroutine，runqueue隊列就在其末尾加入一個goroutine，在下一個調度點，就從runqueue中取出一個goroutine執行。

　　當一個OS線程M0陷入阻塞時，P轉而在M1上運行G，圖中的M1可能是正被創建，或者從線程緩存中取出。當MO返回時，它嘗試取得一個P來運行goroutine，一般情況下，它會從其他的OS線程那裡拿一個P過來執行，像M1獲取P一樣；如果沒有拿到的話，它就把goroutine放在一個global runqueue（全局運行隊列）里，然後自己睡眠（放入線程緩存里）。所有的P會周期性的檢查全局隊列並運行其中的goroutine，否則其上的goroutine永遠無法執行。

　　另一種情況是P上的任務G很快就執行完了（分配不均），這個處理器P很忙，但是其他的P還有任務，此時如果global runqueue也沒有G了，那麼P就會從其他的P里拿一些G來執行。一般來說，如果一般就拿run queue的一半，這就確保了每個OS線程都能充分的使用。

　　golang採用了m:n線程模型，即m個gorountine（簡稱為G）映射到n個用戶態進程（簡稱為P）上，多個G對應一個P，一個P對應一個內核線程（簡稱為M）。

4.2 P、M的數量

　　P的數量：由啟動時環境變量$GOMAXPROCS或者是由runtime的方法GOMAXPROCS()決定（默認是1）。這意味着在程序執行的任意時刻都只有$GOMAXPROCS個goroutine在同時運行。在確定了P的最大數量n后，運行時系統會根據這個數量創建n個P。

 　　M的數量：go語言本身的限制：go程序啟動時，會設置M的最大數量，默認10000.但是內核很難支持這麼多的線程數，所以這個限制可以忽略。runtime/debug中的SetMaxThreads函數，設置M的最大數量。一個M阻塞了，會創建新的M。

　　M與P的數量沒有絕對關係，一個M阻塞，P就會去創建或者切換另一個M，所以，即使P的默認數量是1，也有可能會創建很多個M出來。

4.2 P、G的調度細節

　　P上G的調度：如果一個G不主動讓出cpu或被動block，所屬P中的其他G會一直等待順序執行。

　　一個G執行IO時可能會進入waiting狀態，主動讓出CPU，此時會被移到所屬P中的其他G後面，等待下一次輪到執行。 　　一個G調用了runtime.Gosched()會進入runnable狀態，主動讓出CPU，並被放到全局等待隊列中。 　　一個G調用了runtime.Goexit()，該G將會被立即終止，然後把已加載的defer（有點類似析構）依次執行完。 　　一個G調用了允許block的syscall，此時G及其對應的P、其他G和M都會被block起來，監控線程M會定時掃描所有P，一旦發現某個P處於block syscall狀態，則通知調度器讓另一個M來帶走P（這裏的另一個M可能是新創建的，因此隨着G被不斷block，M數量會不斷增加，最終M數量可能會超過P數量），這樣P及其餘下的G就不會被block了，等被block的M返回時發現自己的P沒有了，也就不能再處理G了，於是將G放入全局等待隊列等待空閑P接管，然後M自己sleep。 　　通過實驗，當一個G運行了很久（比如進入死循環），會被自動切到其他CPU核，可能是因為超過時間片后G被移到全局等待隊列中，後面被其他CPU核上的M處理。

　　M上P和G的調度：每當一個G要開始執行時，調度器判斷當前M的數量是否可以很好處理完G：如果M少G多且有空閑P，則新建M或喚醒一個sleep M，並指定使用某個空閑P；如果M應付得來，G被負載均衡放入一個現有P+M中。

　　當M處理完其身上的所有G后，會再去全局等待隊列中找G，如果沒有就從其他P中分一半的G（以便保證各個M處理G的負載大致相等），如果還沒有，M就去sleep了，對應的P變為空閑P。 在M進入sleep期間，調度器可能會給其P不斷放入G，等M醒后（比如超時）：如果G數量不多，則M直接處理這些G；如果M覺得G太多且有空閑P，會先主動喚醒其他sleep的M來分擔G，如果沒有其他sleep的M，調度器創建新M來分擔。

協程特點

　　協程擁有自己的寄存器上下文和棧。協程調度切換時，將寄存器上下文和棧保存到其他地方，在切回來的時候，恢復先前保存的寄存器上下文和棧。因此，協程能保留上一次調用時的狀態（即所有局部狀態的一個特定組合），每次過程重入時，就相當於進入上一次調用的狀態，換種說法：進入上一次離開時所處邏輯流的位置。線程和進程的操作是由程序觸發系統接口，最後的執行者是系統；協程的操作執行者則是用戶自身程序，goroutine也是協程。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

前段時間小冰在工作中遇到了一系列關於數據持久化的問題，在排查問題時發現自己對 Java 後端的數據持久化框架的原理都不太了解，只有不斷試錯，因此走了很多彎路。於是下定決心，集中精力學習了持久化相關框架的原理和實現，總結出這個系列。

上圖是我根據相關源碼和網上資料總結的有關 Java 數據持久化的架構圖(只代表本人想法，如有問題，歡迎留言指出)。最下層就是今天要講的 JDBC，上一層是數據庫連接池層，包括 HikariCP 和 Druid等；再上一層是分庫分表中間件，比如說 ShardingJDBC；再向上是對象關係映射層，也就是 ORM，包括 Mybatis 和 JPA；最上邊是 Spring 的事務管理。

本系列的文章會依次講解圖中各個開源框架的基礎使用，然後描述其原理和代碼實現，最後會着重分析它們之間是如何相互集成和配合的。

廢話不多說，我們先來看 JDBC。

JDBC 定義

JDBC是Java Database Connectivity的簡稱，它定義了一套訪問數據庫的規範和接口。但它自身不參与數據庫訪問的實現。因此對於目前存在的數據庫（譬如Mysql、Oracle）來說，要麼數據庫製造商本身提供這些規範與接口的實現，要麼社區提供這些實現。

如上圖所示，Java 程序只依賴於 JDBC API，通過 DriverManager 來獲取驅動，並且針對不同的數據庫可以使用不同的驅動。這是典型的橋接的設計模式，把抽象 Abstraction 與行為實現Implementation 分離開來，從而可以保持各部分的獨立性以及應對他們的功能擴展。

JDBC 基礎代碼示例

單純使用 JDBC 的代碼邏輯十分簡單，我們就以最為常用的MySQL 為例，展示一下使用 JDBC 來建立數據庫連接、執行查詢語句和遍歷結果的過程。

public static void connectionTest(){

    Connection connection = null;
    Statement statement = null;
    ResultSet resultSet = null;

    try {
        // 1. 加載並註冊 MySQL 的驅動
        Class.forName("com.mysql.cj.jdbc.Driver").newInstance();

        // 2. 根據特定的數據庫連接URL，返回與此URL的所匹配的數據庫驅動對象
        Driver driver = DriverManager.getDriver(URL);
        // 3. 傳入參數，比如說用戶名和密碼
        Properties props = new Properties();
        props.put("user", USER_NAME);
        props.put("password", PASSWORD);

        // 4. 使用數據庫驅動創建數據庫連接 Connection
        connection = driver.connect(URL, props);

        // 5. 從數據庫連接 connection 中獲得 Statement 對象
        statement = connection.createStatement();
        // 6. 執行 sql 語句，返回結果
        resultSet = statement.executeQuery("select * from activity");
        // 7. 處理結果，取出數據
        while(resultSet.next())
        {
            System.out.println(resultSet.getString(2));
        }

        .....
    }finally{
        // 8.關閉鏈接，釋放資源  按照JDBC的規範，使用完成后管理鏈接，
        // 釋放資源，釋放順序應該是： ResultSet ->Statement ->Connection
        resultSet.close();
        statement.close();
        connection.close();
    }
}

代碼中有詳細的註釋描述每一步的過程，相信大家也都對這段代碼十分熟悉。

唯一要提醒的是使用完之後的資源釋放順序。按照 JDBC 規範，應該依次釋放 ResultSet，Statement 和 Connection。當然這隻是規範，很多開源框架都沒有嚴格的執行，但是 HikariCP卻嚴格准守了，它可以帶來很多優勢，這些會在之後的文章中講解。

上圖是 JDBC 中核心的 5 個類或者接口的關係，它們分別是 DriverManager、Driver、Connection、Statement 和 ResultSet。

DriverManager 負責管理數據庫驅動程序，根據 URL 獲取與之匹配的 Driver 具體實現。Driver 則負責處理與具體數據庫的通信細節，根據 URL 創建數據庫連接 Connection。

Connection 表示與數據庫的一個連接會話，可以和數據庫進行數據交互。Statement 是需要執行的 SQL 語句或者存儲過程語句對應的實體，可以執行對應的 SQL 語句。ResultSet 則是 Statement 執行后獲得的結果集對象，可以使用迭代器從中遍曆數據。

不同數據庫的驅動都會實現各自的 Driver、Connection、Statement 和 ResultSet。而更為重要的是，眾多數據庫連接池和分庫分表框架也都是實現了自己的 Connection、Statement 和 ResultSet，比如說 HikariCP、Druid 和 ShardingJDBC。我們接下來會經常看到它們的身影。

接下來，我們依次看一下這幾個類及其涉及的操作的原理和源碼實現。

載入 Driver 實現

可以直接使用 Class#forName的方式來載入驅動實現，或者在 JDBC 4.0 后則基於 SPI 機制來導入驅動實現，通過在 META-INF/services/java.sql.Driver 文件中指定實現類的方式來導入驅動實現，下面我們就來看一下兩種方式的實現原理。

Class#forName 作用是要求 JVM 查找並加載指定的類，如果在類中有靜態初始化器的話，JVM 會執行該類的靜態代碼段。加載具體 Driver 實現時，就會執行 Driver 中的靜態代碼段，將該 Driver 實現註冊到 DriverManager 中。我們來看一下 MySQL 對應 Driver 的具體代碼。它就是直接調用了 DriverManager的 registerDriver 方法將自己註冊到其維護的驅動列表中。

public class Driver extends NonRegisteringDriver implements java.sql.Driver {
    public Driver() throws SQLException {
    }

    static {
        // 直接調用 DriverManager的 registerDriver 將自己註冊到其中
        DriverManager.registerDriver(new Driver());
    }
}

SPI 機制使用 ServiceLoader 類來提供服務發現機制，動態地為某個接口尋找服務實現。當服務的提供者提供了服務接口的一種實現之後，必須根據 SPI 約定在 META-INF/services 目錄下創建一個以服務接口命名的文件，在該文件中寫入實現該服務接口的具體實現類。當服務調用 ServiceLoader 的 load 方法的時候，ServiceLoader 能夠通過約定的目錄找到指定的文件，並裝載實例化，完成服務的發現。

DriverManager 中的 loadInitialDrivers 方法會使用 ServiceLoader 的 load 方法加載目前項目路徑下的所有 Driver 實現。

public class DriverManager {
    // 程序中已經註冊的Driver具體實現信息列表。registerDriver類就是將Driver加入到這個列表
    private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();
    // 使用ServiceLoader 加載具體的jdbc driver實現
    static {
        loadInitialDrivers();
    }
    private static void loadInitialDrivers() {
        // 省略了異常處理
        // 獲得系統屬性 jdbc.drivers 配置的值
        String drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
            public String run() {
                return System.getProperty("jdbc.drivers");
            }
        });

        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {

                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();
                // 通過 ServiceLoader 獲取到Driver的具體實現類，然後加載這些類，會調用其靜態代碼塊
                while(driversIterator.hasNext()) {
                    driversIterator.next();
                }
                return null;
            }
        });

        String[] driversList = drivers.split(":");
        // for 循環加載系統屬性中的Driver類。
        for (String aDriver : driversList) {
            println("DriverManager.Initialize: loading " + aDriver);
            Class.forName(aDriver, true,
                    ClassLoader.getSystemClassLoader());
        }
    }
}

比如說，項目引用了 MySQL 的 jar包 mysql-connector-java，在這個 jar 包的 META-INF/services 文件夾下有一個叫 java.sql.Driver 的文件，文件的內容為 com.mysql.cj.jdbc.Driver。而 ServiceLoader 的 load 方法找到這個文件夾下的文件，讀取文件的內容，然後加載出文件內容所指定的 Driver 實現。而正如之前所分析的，這個 Driver 類被加載時，會調用 DriverManager 的 registerDriver 方法，從而完成了驅動的加載。

Connection、Statement 和 ResultSet

當程序加載完具體驅動實現后，接下來就是建立與數據庫的連接，執行 SQL 語句並且處理返回結果了，其過程如下圖所示。

建立 Connection

創建 Connection 連接對象，可以使用 Driver 的 connect 方法，也可以使用 DriverManager 提供的 getConnection 方法，此方法通過 url 自動匹配對應的驅動 Driver 實例，然後還是調用對應的 connect 方法返回 Connection 對象實例。

建立 Connection 會涉及到與數據庫進行網絡請求等大量費時的操作，為了提升性能，往往都會引入數據庫連接池，也就是說復用 Connection，免去每次都創建 Connection 所消耗的時間和系統資源。

Connection 默認情況下，對於創建的 Statement 執行的 SQL 語句都是自動提交事務的，即在 Statement 語句執行完后，自動執行 commit 操作，將事務提交，結果影響到物理數據庫。為了滿足更好地事務控制需求，我們也可以手動地控制事務，手動地在Statement 的 SQL 語句執行後進行 commit 或者rollback。

connection = driver.connect(URL, props);
// 將自動提交關閉
connection.setAutoCommit(false);

statement = connection.createStatement();
statement.execute("INSERT INTO activity (activity_id, activity_name, product_id, start_time, end_time, total, status, sec_speed, buy_limit, buy_rate) VALUES (1, '香蕉大甩賣', 1, 530871061, 530872061, 20, 0, 1, 1, 0.20);");
// 執行後手動 commit
statement.getConnection().commit();

Statement

Statement 的功能在於根據傳入的 SQL 語句，將傳入 SQL 經過整理組合成數據庫能夠識別的執行語句(對於靜態的 SQL 語句，不需要整理組合；而對於預編譯SQL 語句和批量語句，則需要整理)，然後傳遞 SQL 請求，之後會得到返回的結果。對於查詢 SQL，結果會以 ResultSet 的形式返回。

當你創建了一個 Statement 對象之後，你可以用它的三個執行方法的任一方法來執行 SQL 語句。

• boolean execute(String SQL) : 如果 ResultSet 對象可以被檢索，則返回的布爾值為 true ，否則返回 false 。當你需要使用真正的動態 SQL 時，可以使用這個方法來執行 SQL DDL 語句。
• int executeUpdate(String SQL) : 返回執行 SQL 語句影響的行的數目。使用該方法來執行 SQL 語句，是希望得到一些受影響的行的數目，例如，INSERT，UPDATE 或 DELETE 語句。
• ResultSet executeQuery(String SQL) : 返回一個 ResultSet 對象。當你希望得到一個結果集時使用該方法，就像你使用一個 SELECT 語句。

對於不同類型的 SQL 語句，Statement 有不同的接口與其對應。

接口 | 介紹
-|-| Statement | 適合運行靜態 SQL 語句，不接受動態參數 PreparedStatement | 計劃多次使用並且預先編譯的 SQL 語句，接口需要傳入額外的參數 CallableStatement | 用於訪問數據庫存儲過程

Statement 主要用於執行靜態SQL語句，即內容固定不變的SQL語句。Statement每執行一次都要對傳入的SQL語句編譯一次，效率較差。而 PreparedStatement則解決了這個問題，它會對 SQL 進行預編譯，提高了執行效率。

PreparedStatement pstmt = null;
    try {
        String SQL = "Update activity SET activity_name = ? WHERE activity_id = ?";
        pstmt = connection.prepareStatement(SQL);
        pstmt.setString(1, "測試");
        pstmt.setInt(2, 1);
        pstmt.executeUpdate();
    }
    catch (SQLException e) {
    }
    finally {
        pstmt.close();
    }
}

除此之外， PreparedStatement 還可以預防 SQL 注入，因為 PreparedStatement 不允許在插入參數時改變 SQL 語句的邏輯結構。

PreparedStatement 傳入任何數據不會和原 SQL 語句發生匹配關係，無需對輸入的數據做過濾。如果用戶將”or 1 = 1”傳入賦值給佔位符，下述SQL 語句將無法執行：select * from t where username = ? and password = ?。

ResultSet

當 Statement 查詢 SQL 執行后，會得到 ResultSet 對象，ResultSet 對象是 SQL語句查詢的結果集合。ResultSet 對從數據庫返回的結果進行了封裝，使用迭代器的模式可以逐條取出結果集中的記錄。

while(resultSet.next()) {
    System.out.println(resultSet.getString(2));
}

ResultSet 一般也建議使用完畢直接 close 掉，但是需要注意的是關閉 ResultSet 對象不關閉其持有的 Blob、Clob 或 NClob 對象。 Blob、Clob 或 NClob 對象在它們被創建的的事務期間會一直持有效，除非其 free 函數被調用。

參考

• https://blog.csdn.net/wl044090432/article/details/60768342
• https://blog.csdn.net/luanlouis/article/details/29850811

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

drf組件之jwt認證模塊

一、認證規則

全稱：json web token
解釋：加密字符串的原始數據是json，後台產生，通過web傳輸給前台存儲
格式：三段式 – 頭.載荷.簽名 – 頭和載荷用的是base64可逆加密，簽名用md5不可逆加密
內容：
頭(基礎信息,也可以為空)：加密方式、公司信息、項目組信息、…
載荷(核心信息)：用戶信息、過期時間、…
簽名(安全保障)：頭加密結果+載荷加密結果+服務器秘鑰 的md5加密結果

認證規則：
後台一定要保障 服務器秘鑰 的安全性(它是jwt的唯一安全保障)
後台簽發token（login接口 ） -> 前台存儲 -> 發送需要認證的請求帶着token -> 後台校驗得到合法的用戶 -> 權限管理

為什麼要有jwt認證：
1)服務器壓力小， 後台不需要存儲token，只需要存儲簽發與校驗token的算法，效率遠遠大於後台存儲和取出token完成校驗
2) jwt算法認證，更適合服務器集群部署

二、認證模塊

安裝：pip install djangorestframework-jwt
模塊包：rest_framework_jwt

採用drf-jwt框架，後期任務只需要書寫登錄
為什麼要重寫登錄：drf-jwt只完成了賬號密碼登錄，我們還需要手機登錄，郵箱登錄
為什麼不需要重寫認證類：因為認證規則已經完成且固定不變，變得只有認證字符串的前綴，前綴可以在配置文件中配置

三、JWT使用

jwt配置；

在settings.py文件中配置，如果不配置，默認走jwt默認的

jwt插件的三個接口：

在urls.py中配置

在postman中測試一下籤發token

注意：上面三個接口都是發送POST請求

四、利用JWT實現多方式登錄

注：APIResponse 為自定義Response對象

# views.py
from rest_framework.views import APIView
from . import models,serializers
from utils.response import APIResponse

class LoginAPIView(APIView):
    # 登錄接口應該禁用所有的認證和、權限，因為不管是誰都應該能進來
    authentication_classes = []
    permission_classes = []
    def post(self, request, *args, **kwargs):
        # 將數據傳到序列化組件進行校驗
        user_ser = serializers.LoginSerializer(data=request.data)
        user_ser.is_valid(raise_exception=True)

        return APIResponse(msg='login success', data={
            'username': user_ser.user.username,
            'token': user_ser.token
        })

注意：

通過user對象生成payload載荷
payload = jwt_payload_handler(user)

通過payload簽發token
token = jwt_encode_handler(payload)

# serializer.py
from rest_framework.serializers import ModelSerializer, CharField, ValidationError, SerializerMethodField
from . import models
from django.contrib.auth import authenticate
import re
from rest_framework_jwt.serializers import jwt_payload_handler, jwt_encode_handler

class LoginSerializer(ModelSerializer):
    username = CharField(write_only=True)
    password = CharField(write_only=True)
    class Meta:
        model = models.User
        fields = ('username', 'password')

    def validate(self, attrs):
        # user_obj = authenticate(**attrs)
        # if not user_obj:
        #     raise ValidationError('用戶名或密碼錯誤')

        # 賬號密碼登錄 ==》 多方式登錄
        user = self._many_method_login(**attrs)

        # 通過user對象生成payload載荷
        payload = jwt_payload_handler(user)
        # 通過payload簽發token
        token = jwt_encode_handler(payload)

        # 將user和token存放在序列化對象中,方便返回到前端去
        self.user = user
        self.token = token

        return attrs

    # 多方式登錄 （用戶名、郵箱、手機號三種方式登錄）
    def _many_method_login(self, **attrs):
        username = attrs.get('username')
        password = attrs.get('password')
        # 利用正則匹配判斷用戶輸入的信息
        # 1.判斷郵箱登錄
        if re.match(r'.*@.*', username):
            user = models.User.objects.filter(email=username).first()  # type: models.User
        # 2.判斷手機號登錄
        elif re.match(r'^1[3-9][0-9]{9}$',username):
            user = models.User.objects.filter(mobile=username).first()
        # 3.用戶名登錄
        else:
            user = models.User.objects.filter(username=username).first()

        if not user:
            raise ValidationError({'username': '賬號有誤'})

        if not user.check_password(password):
            raise ValidationError({'password': '密碼錯誤'})

        return user

使用postman測試代碼：

五、前後台分離模式下信息交互規則

"""
1）任何人都能直接訪問的接口
    請求不是是get、還是post等，不需要做任何校驗

2）必須登錄后才能訪問的接口
    任何請求方式都可能做該方式的限制，請求必須在請求頭中攜帶認證信息 - authorization
    
3）前台的認證信息獲取只能通過登錄接口
    前台提供賬號密碼等信息，去後台換認證信息token
    
4）前台如何完成登錄註銷
    前台登錄成功一般在cookie中保存認證信息token，分離註銷就是前台主動清除保存的token信息
"""

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益