最近做項目，使用的是echarts显示圖表數據，但是數據量比較多的時候，有卡頓的情況。後來同事拿echarts和HighCharts做了對比，僅供大家參考。同時感謝同事做的工作。

一、查詢1天的源數據，屬性1、屬性2、屬性3、屬性4

       Echarts查詢3.61s，渲染0.786s（約8.6M數據）

       HighCharts查詢3.10s，渲染0.768s（約8.7M數據）

二、查詢7天的源數據，屬性1、屬性2、屬性3、屬性4

      Echarts查詢21.67秒，渲染5.38秒。（約60.7M數據）。渲染完成后

      HighCharts查詢22.18s，渲染5.39s。（約60.5M數據）

三、查詢14天的源數據，屬性1、屬性2、屬性3、屬性4

      Echarts渲染不出來，瀏覽器崩潰。

      HighCharts查詢41.42s，渲染10.82s。（約121M數據）

四、內存佔用對比：7天數據

      Echarts渲染后瀏覽器佔用內存約3280M。

      HighCharts渲染后瀏覽器佔用內存約637M。

五、操作對比

圖表類型	1天數據	7天數據	14天數據
Echarts	卡頓	無法操作	瀏覽器崩潰
HighCharts	流暢	流暢	流暢

 

雲端操作系統：http://www.ineuos.net

【精選推薦文章】

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

SpringBoot系列文章簡介

SpringBoot源碼閱讀輔助篇：

　　Spring IoC容器與應用上下文的設計與實現

SpringBoot啟動流程源碼分析：

1. SpringBoot啟動流程分析（一）：SpringApplication類初始化過程
2. SpringBoot啟動流程分析（二）：SpringApplication的run方法
3. SpringBoot啟動流程分析（三）：SpringApplication的run方法之prepareContext()方法
4. SpringBoot啟動流程分析（四）：IoC容器的初始化過程
5. SpringBoot啟動流程分析（五）：SpringBoot自動裝配原理實現
6. SpringBoot啟動流程分析（六）：IoC容器依賴注入

筆者註釋版Spring Framework與SpringBoot源碼git傳送門：請不要吝嗇小星星

1. spring-framework-5.0.8.RELEASE
2. SpringBoot-2.0.4.RELEASE

一、前言

　　前一篇博客介紹了 SpringApplication 類的實例化過程，本章總結SpringBoot啟動流程最重要的部分run方法。通過rrun方法梳理出SpringBoot啟動的流程，然後後面的博客再一步步的分析啟動流程中各個步驟所做的具體的工作。深入分析後會發現SpringBoot也就是給Spring包了一層皮，事先替我們準備好Spring所需要的環境及一些基礎，具體通過源碼一步步深入分析後會發現Spring是真的很偉大。當然跟代碼的時候越深入越容易陷進去進而發現有些東西沒法通過博客詳細的梳理出來。當然在這個過程中還是立足於我們對SpringBoot的使用來說明源碼所做的工作。知其然才能知其所以然。加油

 

二、SpringBoot啟動流程梳理

　　首先擺上run方法的源碼

 1 /**
 2  * Run the Spring application, creating and refreshing a new
 3  * {@link ApplicationContext}.
 4  *
 5  * @param args the application arguments (usually passed from a Java main method)
 6  * @return a running {@link ApplicationContext}
 7  *
 8  * 運行spring應用，並刷新一個新的 ApplicationContext（Spring的上下文）
 9  * ConfigurableApplicationContext 是 ApplicationContext 接口的子接口。在 ApplicationContext
10  * 基礎上增加了配置上下文的工具。 ConfigurableApplicationContext是容器的高級接口
11  */
12 public ConfigurableApplicationContext run(String... args) {
13     //記錄程序運行時間
14     StopWatch stopWatch = new StopWatch();
15     stopWatch.start();
16     // ConfigurableApplicationContext Spring 的上下文
17     ConfigurableApplicationContext context = null;
18     Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
19     configureHeadlessProperty();
20     //從META-INF/spring.factories中獲取監聽器
21     //1、獲取並啟動監聽器
22     SpringApplicationRunListeners listeners = getRunListeners(args);
23     listeners.starting();
24     try {
25         ApplicationArguments applicationArguments = new DefaultApplicationArguments(
26                 args);
27         //2、構造應用上下文環境
28         ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
29         //處理需要忽略的Bean
30         configureIgnoreBeanInfo(environment);
31         //打印banner
32         Banner printedBanner = printBanner(environment);
33         ///3、初始化應用上下文
34         context = createApplicationContext();
35         //實例化SpringBootExceptionReporter.class，用來支持報告關於啟動的錯誤
36         exceptionReporters = getSpringFactoriesInstances(
37                 SpringBootExceptionReporter.class,
38                 new Class[]{ConfigurableApplicationContext.class}, context);
39         //4、刷新應用上下文前的準備階段
40         prepareContext(context, environment, listeners, applicationArguments, printedBanner);
41         //5、刷新應用上下文
42         refreshContext(context);
43         //刷新應用上下文後的擴展接口
44         afterRefresh(context, applicationArguments);
45         //時間記錄停止
46         stopWatch.stop();
47         if (this.logStartupInfo) {
48             new StartupInfoLogger(this.mainApplicationClass)
49                     .logStarted(getApplicationLog(), stopWatch);
50         }
51         //發布容器啟動完成事件
52         listeners.started(context);
53         callRunners(context, applicationArguments);
54     } catch (Throwable ex) {
55         handleRunFailure(context, ex, exceptionReporters, listeners);
56         throw new IllegalStateException(ex);
57     }
58 
59     try {
60         listeners.running(context);
61     } catch (Throwable ex) {
62         handleRunFailure(context, ex, exceptionReporters, null);
63         throw new IllegalStateException(ex);
64     }
65     return context;
66 }

 

　　具體的每一行代碼的含義請看註釋，我們在這先總結一下啟動過程中的重要步驟：（筆者傾向於將應用上下文同容器區分開來）

第一步：獲取並啟動監聽器
第二步：構造應用上下文環境
第三步：初始化應用上下文
第四步：刷新應用上下文前的準備階段
第五步：刷新應用上下文
第六步：刷新應用上下文後的擴展接口

　　OK，下面SpringBoot的啟動流程分析，我們就根據這6大步驟進行詳細解讀。最總要的是第四，五步。我們會着重的分析。

 

三、第一步：獲取並啟動監聽器

　　事件機制在Spring是很重要的一部分內容，通過事件機制我們可以監聽Spring容器中正在發生的一些事件，同樣也可以自定義監聽事件。Spring的事件為Bean和Bean之間的消息傳遞提供支持。當一個對象處理完某種任務后，通知另外的對象進行某些處理，常用的場景有進行某些操作后發送通知，消息、郵件等情況。

1 private SpringApplicationRunListeners getRunListeners(String[] args) {
2     Class<?>[] types = new Class<?>[]{SpringApplication.class, String[].class};
3     return new SpringApplicationRunListeners(logger, getSpringFactoriesInstances(
4             SpringApplicationRunListener.class, types, this, args));
5 }

　　在這裏面是不是看到一個熟悉的方法：getSpringFactoriesInstances()，可以看下下面的註釋，前面的博文我們已經詳細介紹過該方法是怎麼一步步的獲取到META-INF/spring.factories中的指定的key的value，獲取到以後怎麼實例化類的。

 1 /**
 2  * 通過指定的classloader 從META-INF/spring.factories獲取指定的Spring的工廠實例
 3  * @param type
 4  * @param parameterTypes
 5  * @param args
 6  * @param <T>
 7  * @return
 8  */
 9 private <T> Collection<T> getSpringFactoriesInstances(Class<T> type,
10                                                       Class<?>[] parameterTypes, Object... args) {
11     ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
12     // Use names and ensure unique to protect against duplicates
13     //通過指定的classLoader從 META-INF/spring.factories 的資源文件中，
14     //讀取 key 為 type.getName() 的 value
15     Set<String> names = new LinkedHashSet<>(SpringFactoriesLoader.loadFactoryNames(type, classLoader));
16     //創建Spring工廠實例
17     List<T> instances = createSpringFactoriesInstances(type, parameterTypes,
18             classLoader, args, names);
19     //對Spring工廠實例排序（org.springframework.core.annotation.Order註解指定的順序）
20     AnnotationAwareOrderComparator.sort(instances);
21     return instances;
22 }

 　　回到refresh方法，debug這個代碼 SpringApplicationRunListeners listeners = getRunListeners(args); 看一下獲取的是哪個監聽器：

　　EventPublishingRunListener監聽器是Spring容器的啟動監聽器。

　　 listeners.starting(); 開啟了監聽事件。

 

四、第二步：構造應用上下文環境

　　應用上下文環境包括什麼呢？包括計算機的環境，Java環境，Spring的運行環境，Spring項目的配置（在SpringBoot中就是那個熟悉的application.properties/yml）等等。

　　首先看一下prepareEnvironment()方法。

 1 private ConfigurableEnvironment prepareEnvironment(
 2         SpringApplicationRunListeners listeners,
 3         ApplicationArguments applicationArguments) {
 4     // Create and configure the environment
 5     //創建並配置相應的環境
 6     ConfigurableEnvironment environment = getOrCreateEnvironment();
 7     //根據用戶配置，配置 environment系統環境
 8     configureEnvironment(environment, applicationArguments.getSourceArgs());
 9     // 啟動相應的監聽器，其中一個重要的監聽器 ConfigFileApplicationListener 就是加載項目配置文件的監聽器。
10     listeners.environmentPrepared(environment);
11     bindToSpringApplication(environment);
12     if (this.webApplicationType == WebApplicationType.NONE) {
13         environment = new EnvironmentConverter(getClassLoader())
14                 .convertToStandardEnvironmentIfNecessary(environment);
15     }
16     ConfigurationPropertySources.attach(environment);
17     return environment;
18 }

 　　看上面的註釋，方法中主要完成的工作，首先是創建並按照相應的應用類型配置相應的環境，然後根據用戶的配置，配置系統環境，然後啟動監聽器，並加載系統配置文件。

 

4.1、 ConfigurableEnvironment environment = getOrCreateEnvironment(); 

　　看看getOrCreateEnvironment()幹了些什麼。

 1 private ConfigurableEnvironment getOrCreateEnvironment() {
 2     if (this.environment != null) {
 3         return this.environment;
 4     }
 5     //如果應用類型是 SERVLET 則實例化 StandardServletEnvironment
 6     if (this.webApplicationType == WebApplicationType.SERVLET) {
 7         return new StandardServletEnvironment();
 8     }
 9     return new StandardEnvironment();
10 }

 　　通過代碼可以看到根據不同的應用類型初始化不同的系統環境實例。前面咱們已經說過應用類型是怎麼判斷的了，這裏就不在贅述了。

　　

　　從上面的繼承關係可以看出，StandardServletEnvironment是StandardEnvironment的子類。這兩個對象也沒什麼好講的，當是web項目的時候，環境上會多一些關於web環境的配置。

 

4.2、 configureEnvironment(environment, applicationArguments.getSourceArgs()); 

1 protected void configureEnvironment(ConfigurableEnvironment environment,
2                                     String[] args) {
3     // 將main 函數的args封裝成 SimpleCommandLinePropertySource 加入環境中。
4     configurePropertySources(environment, args);
5     // 激活相應的配置文件
6     configureProfiles(environment, args);
7 }

　　在執行完方法中的兩行代碼后，debug的截圖如下

　　如下圖所示，我在spring的啟動參數中指定了參數：–spring.profiles.active=prod（關於這個參數的用法，點我，其實就是啟動多個實例用的）

 

　　在configurePropertySources(environment, args);中將args封裝成了SimpleCommandLinePropertySource並加入到了environment中。

　　configureProfiles(environment, args);根據啟動參數激活了相應的配置文件。

　　話不多說，debug一遍就明白了。

 

4.3、 listeners.environmentPrepared(environment); 

　　進入到方法一路跟下去就到了SimpleApplicationEventMulticaster類的multicastEvent()方法。

　　

　　查看getApplicationListeners(event, type)執行結果，發現一個重要的監聽器ConfigFileApplicationListener。

　　先看看這個類的註釋

 1 /**
 2  * {@link EnvironmentPostProcessor} that configures the context environment by loading
 3  * properties from well known file locations. By default properties will be loaded from
 4  * 'application.properties' and/or 'application.yml' files in the following locations:
 5  * <ul>
 6  * <li>classpath:</li>
 7  * <li>file:./</li>
 8  * <li>classpath:config/</li>
 9  * <li>file:./config/:</li>
10  * </ul>
11  * <p>
12  * Alternative search locations and names can be specified using
13  * {@link #setSearchLocations(String)} and {@link #setSearchNames(String)}.
14  * <p>
15  * Additional files will also be loaded based on active profiles. For example if a 'web'
16  * profile is active 'application-web.properties' and 'application-web.yml' will be
17  * considered.
18  * <p>
19  * The 'spring.config.name' property can be used to specify an alternative name to load
20  * and the 'spring.config.location' property can be used to specify alternative search
21  * locations or specific files.
22  * <p>
23  * 從默認的位置加載配置文件，並將其加入 上下文的 environment變量中
24  */

　　這個監聽器默認的從註釋中<ul>標籤所示的幾個位置加載配置文件，並將其加入 上下文的 environment變量中。當然也可以通過配置指定。

　　debug跳過 listeners.environmentPrepared(environment); 這一行，查看environment屬性，果真如上面所說的，配置文件的配置信息已經添加上來了。

　　

五、第三步：初始化應用上下文

　　在SpringBoot工程中，應用類型分為三種，如下代碼所示。

 1 public enum WebApplicationType {
 2     /**
 3      * 應用程序不是web應用，也不應該用web服務器去啟動
 4      */
 5     NONE,
 6     /**
 7      * 應用程序應作為基於servlet的web應用程序運行，並應啟動嵌入式servlet web（tomcat）服務器。
 8      */
 9     SERVLET,
10     /**
11      * 應用程序應作為 reactive web應用程序運行，並應啟動嵌入式 reactive web服務器。
12      */
13     REACTIVE
14 }

　　對應三種應用類型，SpringBoot項目有三種對應的應用上下文，我們以web工程為例，即其上下文為AnnotationConfigServletWebServerApplicationContext。

 1 public static final String DEFAULT_WEB_CONTEXT_CLASS = "org.springframework.boot."
 2         + "web.servlet.context.AnnotationConfigServletWebServerApplicationContext";
 3 public static final String DEFAULT_REACTIVE_WEB_CONTEXT_CLASS = "org.springframework."
 4         + "boot.web.reactive.context.AnnotationConfigReactiveWebServerApplicationContext";
 5 public static final String DEFAULT_CONTEXT_CLASS = "org.springframework.context."
 6         + "annotation.AnnotationConfigApplicationContext";
 7         
 8 protected ConfigurableApplicationContext createApplicationContext() {
 9     Class<?> contextClass = this.applicationContextClass;
10     if (contextClass == null) {
11         try {
12             switch (this.webApplicationType) {
13                 case SERVLET:
14                     contextClass = Class.forName(DEFAULT_WEB_CONTEXT_CLASS);
15                     break;
16                 case REACTIVE:
17                     contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS);
18                     break;
19                 default:
20                     contextClass = Class.forName(DEFAULT_CONTEXT_CLASS);
21             }
22         } catch (ClassNotFoundException ex) {
23             throw new IllegalStateException(
24                     "Unable create a default ApplicationContext, "
25                             + "please specify an ApplicationContextClass",
26                     ex);
27         }
28     }
29     return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass);
30 }

　　我們先看一下AnnotationConfigServletWebServerApplicationContext的設計。

 　　關於他的繼承體系，我們在前面的博客中<Spring IoC容器與應用上下文的設計與實現>已經詳細介紹了，在此不再贅述。

　　應用上下文可以理解成IoC容器的高級表現形式，應用上下文確實是在IoC容器的基礎上豐富了一些高級功能。

　　應用上下文對IoC容器是持有的關係。他的一個屬性beanFactory就是IoC容器（DefaultListableBeanFactory）。所以他們之間是持有，和擴展的關係。

　　接下來看GenericApplicationContext類

1 public class GenericApplicationContext extends AbstractApplicationContext implements BeanDefinitionRegistry {
2     private final DefaultListableBeanFactory beanFactory;
3     ...
4     public GenericApplicationContext() {
5         this.beanFactory = new DefaultListableBeanFactory();
6     }
7     ...
8 }

 　　beanFactory正是在AnnotationConfigServletWebServerApplicationContext實現的接口GenericApplicationContext中定義的。在上面createApplicationContext()方法中的， BeanUtils.instantiateClass(contextClass) 這個方法中，不但初始化了AnnotationConfigServletWebServerApplicationContext類，也就是我們的上下文context，同樣也觸發了GenericApplicationContext類的構造函數，從而IoC容器也創建了。仔細看他的構造函數，有沒有發現一個很熟悉的類DefaultListableBeanFactory，沒錯，DefaultListableBeanFactory就是IoC容器真實面目了。在後面的refresh()方法分析中，DefaultListableBeanFactory是無處不在的存在感。

　　debug跳過createApplicationContext()方法。

　　如上圖所示，context就是我們熟悉的上下文（也有人稱之為容器，都可以，看個人愛好和理解），beanFactory就是我們所說的IoC容器的真實面孔了。細細感受下上下文和容器的聯繫和區別，對於我們理解源碼有很大的幫助。在系列文章中，我們也是將上下文和容器嚴格區分開來的。

 

　　

　　原創不易，轉載請註明出處。

　　如有錯誤的地方還請留言指正。

【精選推薦文章】

智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

帶您來看台北網站建置，台北網頁設計，各種案例分享

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

導航

• HTTP認證之基本認證——Basic（一）
• HTTP認證之基本認證——Basic（二）
• HTTP認證之摘要認證——Digest（一）
• HTTP認證之摘要認證——Digest（二）

一、概述

Digest認證是為了修復基本認證協議的嚴重缺陷而設計的，秉承“絕不通過明文在網絡發送密碼”的原則，通過“密碼摘要”進行認證，大大提高了安全性。

相對於基本認證，主要有如下改進：

• 絕不通過明文在網絡上發送密碼
• 可以有效防止惡意用戶進行重放攻擊
• 可以有選擇的防止對報文內容的篡改

需要注意的是，摘要認證除了能夠保護密碼之外，並不能保護其他內容，與HTTPS配合使用仍是一個良好的選擇。以下是摘要認證的具體流程圖：

看到上面出現了那麼多之前沒見過的參數，是不是有點慌（或是興奮）？別著急，這裏先給出一個概覽：

• WWW-Authentication：用來定義使用何種方式（Basic、Digest、Bearer等）去進行認證以獲取受保護的資源
• realm：表示Web服務器中受保護文檔的安全域（比如公司財務信息域和公司員工信息域），用來指示需要哪個域的用戶名和密碼
• qop：保護質量，包含auth（默認的）和auth-int（增加了報文完整性檢測）兩種策略，（可以為空，但是）不推薦為空值
• nonce：服務端向客戶端發送質詢時附帶的一個隨機數，這個數會經常發生變化。客戶端計算密碼摘要時將其附加上去，使得多次生成同一用戶的密碼摘要各不相同，用來防止重放攻擊
• nc：nonce計數器，是一個16進制的數值，表示同一nonce下客戶端發送出請求的數量。例如，在響應的第一個請求中，客戶端將發送“nc=00000001”。這個指示值的目的是讓服務器保持這個計數器的一個副本，以便檢測重複的請求
• cnonce：客戶端隨機數，這是一個不透明的字符串值，由客戶端提供，並且客戶端和服務器都會使用，以避免用明文文本。這使得雙方都可以查驗對方的身份，並對消息的完整性提供一些保護
• response：這是由用戶代理軟件計算出的一個字符串，以證明用戶知道口令
• Authorization-Info：用於返回一些與授權會話相關的附加信息
• nextnonce：下一個服務端隨機數，使客戶端可以預先發送正確的摘要
• rspauth：響應摘要，用於客戶端對服務端進行認證
• stale：當密碼摘要使用的隨機數過期時，服務器可以返回一個附帶有新隨機數的401響應，並指定stale=true，表示服務器在告知客戶端用新的隨機數來重試，而不再要求用戶重新輸入用戶名和密碼了

二、剖析

1.當打開需要認證的頁面時，會彈出一個對話框，要求用戶輸入用戶名和密碼

2.使用Fidder監聽請求，可以看到在未進行認證或認證失敗的情況下，服務端會返回401 Unauthorized給客戶端，並附帶Challenge

3.輸入正確的用戶名和密碼后，瀏覽器會生成密碼摘要以及其他信息發送給服務端，服務端認證成功后，返回一些與授權會話相關的附加信息，放在Authorization-Info中。

其中，客戶端選擇的保護質量策略為auth，response就是通過計算得到的密碼摘要，具體計算方式如下（使用默認的MD5加密算法）：

MD5(MD5(A1):<nonce>:<nc>:<cnonce>:<qop>:MD5(A2))

算法	A1
MD5（默認）	<username>:<realm>:<password>
MD5-sess	MD5(<username>:<realm>:<password>):<nonce>:<cnonce>

qop	A2
auth（默認）	<request-method>:<uri>
auth-int	<request-method>:<uri>:MD5(<request-entity-body>)

另外，rspauth使得客戶端可以對服務器進行認證，稱為響應摘要。響應摘要的計算與請求摘要類似，但由於響應中沒有方法，而且報文實體數據有所不同，所有隻有報文主題信息A2不同。具體區別如下：

qop	A2
auth（默認）	:<uri>
auth-int	:<uri>:MD5(<response-entity-body>)

4.當服務端隨機數過期時，再次請求認證，可以看到質詢中增加了stale=true，用戶無需再次輸入用戶名和密碼，瀏覽器會自動使用新的質詢參數進行密碼摘要的計算。

三、注意事項

1.預授權：服務端預先告知客戶端下一個隨機數是多少，使得客戶端可以直接生成正確的Authorization首部，避免了多次“請求/質詢”。常用的有一下三種方式：

• 服務器預先在Authorization-Info成功首部中發送下一個隨機數nextnonce。雖然這種機制加快了事務處理的速度，但是它也破壞了對同一台服務器的多次請求進行管道化的功能，可能會造成很大的損失。
• 服務器允許在一小段時間內使用同一個隨機數。這也就是我們上面剖析中使用的機制，在一定時間內使用同一個隨機數或限制某個隨機數的重用次數，當過期時，聲明stale=true。雖然這確實降低了安全性，但是重用的隨機數的生存周期是可控的，應該在安全和性能之間找到平衡。
• 客戶端和服務器使用同步的、可預測的隨機數生成算法。

2.RFC 2617建議採用這個假想的隨機數公式：

BASE64(timestamp MD5(timestamp “:” ETag “:” private-key))

其中，timestamp是服務器產生隨機數的時間或其他不重複的值，ETag是與所請求實體有關的HTTP ETag首部的值，private-key是只有服務器知道的私鑰。

【精選推薦文章】

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

裝飾器

什麼是裝飾器

裝飾器顧名思義就是一個有裝飾功能的工具，那麼裝飾器又是用來裝飾什麼的？為什麼要裝飾這個東西？裝飾的目的是什麼呢？本文會一一作答讓小弟一個一個說

開放封閉原則

談及裝飾器就要引申一個概念，那就是開放封閉原則，那麼問題又來了 什麼是開放封閉……好好好，直接說這個，開放封閉本來是兩個對立的概念，也就是說是一對反義詞，那麼為什麼要提出開放封閉原則呢？原因是在日常的開發工作中，一般最初上線的產品的功能是不盡完善的，就是說不夠完美但已經能夠支撐日常使用，其餘的功能可以日後擴展，舉例：N年前的QQ和現在的QQ（PS：雖然現在本人不怎麼用了）。在後期擴展功能時，因為函數已經是寫好的，而且存在大量調用，所以要直接去給函數增添新的功能顯然不現實，所以我們只能新建函數去給原來的函數擴展功能（其實這就是一個裝飾器啦）

那麼開放封閉原則到底是什麼? 答案是對源碼封閉，對新功能開放

• 封閉原則：不要改變源代碼

• 開放原則：能增加一些額外的功能

  如果還有客觀對開放封閉原則似知似解的話，沒關係接着往下看，不影響您食用本文，因為Python裝飾器本身就是對開放封閉原則完美的詮釋

裝飾器初識

不低調的說，裝飾器就是一個函數，名字本來很高大上，但本質就是一個函數，裝飾器函數的功能就是要裝飾一個函數，在不改變被裝飾函數的源代碼及調用方式的前提下，為其增加額外的功能。是不是有點門道了，是不是覺得這玩意也沒啥啦，真是優秀的同學。

代碼show（技術博客不寫代碼干白話說出去丟人）

def warpper(f):  #定義一個函數（裝飾器），傳入的參數是被修飾的函數的函數名
​
 def inner(*args,**kwargs):  #嵌套一個內存函數，這個函數主題才是執行被裝飾函數源碼的關鍵
​
     '''這塊可以加要在被裝飾函數執行之前的操作哈'''
​
     ret = f(*args,**kwargs) #這裏的形參我會在下面說明
​
     '''這裏可以寫被裝飾函數之後的，兄嘚，別客氣，想加啥方法加什麼'''
​
     return ret  #這裏的返回值如果我一會兒不忘的話也會在下面說明
​
 return inner
​
@warpper #這個叫語法糖，嗯……可以吃（可能老外命名的時候就是這麼想的），結構是@加函數名，作用下面會說明
def func():
   print('我就是那個被裝飾的函數')

簡單說明

因為本人比較懶，所以原諒我直接把代碼甩上去了，後面有註釋，看懂了的大佬可以say goodbye啦，想打我的接着聽我白話，那我就把備註再重複一遍，哈哈，你也看到了，裝飾器用到了函數的嵌套（再具體點就是閉包，要問什麼是閉包，百度吧，哈哈），首先外層函數接收到一個函數名，然後返回值是內層函數的函數名；再來內層函數可以接收參數，其中ret = f(*args,**kwargs)有兩個作用，一是執行了傳入的函數，也就是執行了被修飾的函數，二是將返回值賦給了一個變量，此處要說明一下，對被修飾的函數功能的擴展要寫在這裏哦，最後 ret作為內層函數的返回值返回給函數執行者。

語法糖

@warpper這東西和 func = wrapper(func)是一樣的，也就是說最後三行代碼可以這樣寫

#@warpper 
def func():
   print('我就是那個被裝飾的函數')
func = wrapper(func)   #注意奧，這玩意要寫在被裝飾函數的下邊，語法糖才寫上邊

至於為什麼要寫着東西，或者為什麼要用語法糖？請聽下回分解~~~，收起你滴拳頭，是這樣，我剛開始的時候談到了，裝飾器是要在不改變源碼和其調用方式的前提下給其增加新的功能，注意到了么 調用方式 嗯……沒錯就是調用方式，如果我不這樣寫那我是不是要wrapper(func)()這樣去調用啊，是不是有點繞了，但是我把wrapper(func)賦值給了一個和被裝飾函數同名的變量，那我此時要怎麼調用，是不是就是func()，這樣就滿足了開放封閉原則，完美！其實本質就是要把裝飾器“偽裝”成原函數，包括調用方式、參數、返回值，裝就要裝的像一點，對吧。

裝飾帶參數的函數

def wrapper(f):
 def inner(*args,**kwargs):
  f(*args,**kwargs)
 return inner
@wrapper
def func(a,b):
 print(a,b)

函數func中有兩個形參a和b，說一下這兩個參數在裝飾器中的旅程，函數inner的萬能參數接收到a和b打包，然後inner函數充當中間商將打包后的元組給了f，在f中打散又成了變量a和b，在裝飾器時就不會影響傳參了，這就是裝飾帶參數的函數

裝飾有返回值的函數

def wrapper(f):
 def inner():
  ret = f()
  return ret
 return inner
@wrapper
def func():
 return('我不管，我最帥')

哈哈，這段代碼中有我的心聲，你們都懂的，很簡單，裝飾有返回值的參數，在inner函數中將f()賦值給ret，這樣ret就接收到了返回值，再將ret返回給inner()，以此來達到“模擬”被裝飾函數的返回值，也可以說是通過這種方法來拿到被裝飾函數的返回值。

裝飾器帶參數

先舉個例子，當我們需要寫一個簡單的登陸認證功能的時候，我們的目的是要用裝飾器給調用的函數增加一個認證是否登陸過此網站的功能，也就是要驗證用戶名和密碼，但比如不同公司的網站數據庫肯定並非同一個，這個時候就需要帶參數的裝飾器啦，它可以實現我們要用一個裝飾器裝飾多個類似函數的目的

def wrapper_out(n):
    def wrapper(f):
        def inner(*args,**kwargs):
            with open(n,encoding='utf-8') as f1:
            '''此部分省略認證的詳細功能'''
            f(*args,**kwargs)
        return inner
    return wrapper
​
@wrapper_out('webpage1')
def wangzhi1():
    print('歡迎訪問網址1')
    
@wrapper_out('webpage2')
def wangzhi1():
    print('歡迎訪問網址2')

如果使用標準的裝飾器函數的話只能裝飾其中的一個函數，當裝飾另一個函數時會因為訪問不到正確的數據庫而報錯。

@wrapper_out('webpage1')這段代碼先執行wrapper_out('webpage1')這個函數先把參數webpage傳給n，並且返回一個wrapper，此時@和wrapper結合在一塊有沒有很眼熟，沒錯，這就是我們所熟悉的標準的裝飾器了，餘下的流程就和標準的裝飾器完全相同了。

多個裝飾器裝飾一個函數

這是一種特殊的情況，下面重點分析這種情況的結果是如何產生的，會有點繞。

def wrapper1(func1):
     def inner1():
         print('wrapper1 ,before func')
         func1()
         print('wrapper1 ,after func')
     return inner1
​
def wrapper2(func2): # func2 == inner1
     def inner2():
         print('wrapper2 ,before func')
         func2() # inner1
         print('wrapper2 ,after func')
     return inner2
​
@wrapper2  
@wrapper1  
def f():
 print('in f') # 3
​
f()  

結果：

wrapper2,before func
wrapper1,before func
in f
wrapper1,after func
wrapper2,after func

怎麼說？是不是和你預期的結果有所不同，下面來按步驟說一下為什麼會產生這樣的結果（我盡量表達清楚哈）

1. 函數定義不調用不執行直接pass
2.   @wrapper2
 @wrapper1  
 def f():
 單獨看下面這兩行，標準裝飾器哈 @wrapper1 等價於 f = wrapper1(f) = inner1（返回值哈）
3. @wrapper2
   @wrapper1   #注意哈 看步驟2 這裏現在是inner1咯、
   @wrapper2 等價於 inner1 = wrapper2(inner1) = inner2(返回值)
4. 此時的 f = inner2 執行f() 就從inner2()開始執行
5. 執行inner2 首先打印'wrapper2 ,before func'
6. 然後執行func2,由步驟3可知當前wrapper2中的參數是inner1 也就是執行inner1 所以打印wrapper1 ,before func
7. 然後執行func1 參考步驟2 可知這裏的func1()執行的是f()也就是真正的原函數，打印in f
8. 順序執行，打印wrapper1 ,after func
9. inner1執行完（其實就是func2執行完）還是順序執行 打印wrapper2 ,after func
10. 結果出來了、哈哈

這部分本人能力也只能寫成這樣了，各位看官看不懂那一定是小弟沒表述清楚，不過沒關係，在下再支一招，看圖

 

結合結果分析，相信各位老闆也能推導出正確的結果了，嗯、真帥！

好，到此對Python裝飾器應該有那麼一丟丟的認識了哈，我不管，就得有認識。下面的內容和文章關係不大哈

第一篇正經寫的文章，可能文章內容表達不盡如人意的正經哈，但初心是好的，就是分享知識，分享心得嘛，嗯，不管怎麼說，我還是很欣慰的對自己，哈哈，能有人從中有收穫就更perfect嘍

【精選推薦文章】

智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

帶您來看台北網站建置，台北網頁設計，各種案例分享

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

　　前面三篇文章中分別總結了標準Java IO系統中的File、RandomAccessFile、I/O流系統，對於I/O系統從其繼承體系入手，力求對類數量繁多的的I/O系統有一個清晰的認識，然後結合一些I/O的常規用法來加深對標準I/O系統的掌握，感興趣的同學可以看一下：

　　<<Java I/O系統學習系列一：File和RandomAccessFile>>

　　<<Java I/O系統學習系列二：輸入和輸出>>

　　<<Java I/O系統學習系列三：I/O流的典型使用方式>>

　　從本文開始我會開始總結NIO部分，Java NIO(注意，這裏的NIO其實叫New IO)是用來替換標準Java IO以及Java 網絡API的，其提供了一系列不同與標準IO API的方式來處理IO，從JDK1.4開始引入，其目的在於提高速度。

　　之所以能夠提高速度是因為其所使用的結構更接近於操作系統執行I/O的方式：通道和緩衝器。我們可以把它想象成一個煤礦，通道是一個包含煤層(數據)的礦藏，而緩衝器則是派送到礦藏的卡車。卡車滿載煤炭而歸，我們再從卡車上獲得煤炭。也就是說，我們並沒有直接和通道交互，而是和緩衝器交互，並把緩衝器派送到通道。通道要麼從緩衝器獲得數據，要麼向緩衝器發送數據。

 　　在標準IO的API中，使用字節流和字符流。而在Java NIO中是使用Channel(通道)和Buffer(緩衝區)，數據從channel中讀取到buffer中，或從buffer寫入到channel中。Java NIO類庫中的核心組件為：

• Buffer
• Channel
• Selector

　　本文中我們會着重總結Buffer相關的知識點(後面的文章中會繼續介紹Channel即Selector)，本文主要會圍繞如下幾個方面展開：

　　Buffer簡介

　　Buffer的內部結構　　

　　Buffer的主要API

　　ByteBuffer

　　Buffer類型

　　總結

 

1. Buffer簡介

　　Java NIO中的Buffer一般和Channel配對使用。可以從Channel中讀取數據到Buffer，或者寫數據到Channel中。一個Buffer其實就是代表一個內存塊，你可以往裡面寫數據或者從中讀取數據。這個內存塊被包裝成一個Buffer對象，並且提供了一系列方法使得操作內存塊更便捷。

　　通過Buffer來讀寫數據通常包括如下4步：

1. 寫數據到Buffer中；
2. 調用buffer.flip()；
3. 從Buffer讀取數據；
4. 調用buffer.clear()或buffer.compact()；

　　當往Buffer中寫數據時，Buffer能夠記錄寫了多少數據。當要從Buffer中讀取數據時，就需要通過調用flip()方法將Buffer從寫模式切換到讀模式。一旦讀完所有數據，需要清空Buffer，讓它再次處於寫狀態。可以通過調用clear()或compact()方法來完成這一步：

• clear()方法會清空整個Buffer；
• compact()方法僅僅清空你已經從Buffer中讀取的數據，未讀數據會被移動到Buffer起始位置，可以緊接着未讀的數據寫入新的數據；

  如下是一個簡單的使用例子，通過FileChannel和ByteBuffer讀取pom.xml文件，並逐字節輸出：

public class BufferDemo {

    public static void main(String[] args) {
        try {
            RandomAccessFile raf = new RandomAccessFile("pom.xml","r");
            FileChannel channel = raf.getChannel();
            ByteBuffer buffer = ByteBuffer.allocate(48);
            int byteReaded = channel.read(buffer);
            while(byteReaded != -1) {
                buffer.flip();
                while(buffer.hasRemaining()) {
                    System.out.print((char)buffer.get());
                }
                buffer.clear();
                byteReaded = channel.read(buffer);
            }
            raf.close();
        }catch (Exception e) {
            e.printStackTrace();
        }
    }    
}

 

2. Buffer的內部結構

　　上面說到Buffer封裝了一塊內存塊，並提供了一系列的方法使得可以方便地操縱內存中的數據。至於如何操縱？Buffer提供了4個索引。要理解Buffer的工作原理，就需要從這些索引說起：

• capacity(容量)；
• position(位置)；
• limit(界限)；
• mark(標記)；

 　　其中position和limit的含義取決於Buffer是處於什麼模式(讀或者寫模式)，capacity的含義則和模式無關，而mark則只是一個標記，可以通過mark()方法進行設置。下圖描述了讀寫模式下三種屬性分別代表的含義，詳細解釋見下文：

2.1 Capacity

　　Buffer代表一個內存塊，所以其是有確定大小的，也叫“容量”。可以往buffer中寫入各種數據如byte、long、chars等，當Buffer被寫滿了則需要將其清空(可以通過讀取數據或者清空數據)之後才能繼續寫入數據。

2.2 Position

　　當往Buffer中寫數據時，寫入的地方就是所謂的position，其初始值為0，最大值為capacity-1。當往Buffer中寫入一個byte或者long的數據時，position會前移以指向下一個即將被插入的位置。

　　當從Buffer中讀取數據時，讀取數據的地方就是所謂的position。當執行flip將Buffer從寫模式切換到讀模式時，position會被重置為0。隨着不斷從Buffer讀取數據，position也會不斷後移指向下一個將被讀取的數據。

2.3 Limit

　　在寫模式下，Buffer的limit是指能夠往Buffer中寫入多少數據，其值等於Buffer的capacity。

　　在讀模式下，Buffer的limit是指能夠從Buffer讀取多少數據出來。因此當從寫模式切換到讀模式下時，limit就被設置為寫模式下的position的值(這很好理解，寫了多少才能讀到多少)。

 2.4 Mark

　　mark其實就是一個標記，可以通過mark()方法設置，設置值為當前的position。

 

　　下面是用於設置和複位索引以及查詢它們值的方法：

 

　　capacity()　　　　  返回緩衝區容量
　　clear()　　　　　　清空緩衝區，將position設置為0，limit設置為容量。我們可以調用此方法覆寫緩衝區
　　flip()　　　　　　　將limit設置為position，position設置為0。此方法用於準備從緩衝區讀取已經寫入的數據
　　limit()　　　　　　  返回limit值
　　limit(int lim)　　　　設置limit值
　　mark()　　　　　　 將mark設置為position
　　position()　　　　　返回position值
　　position(int pos)　　設置position值
　　remaining()　　　　返回(limit – position）
　　hasRemaining()　　若有介於position和limit之間的元素，則返回true

 

3. Buffer的主要API

　　除了如上和索引相關的方法之外，Buffer還提供了一些其他的方法用於寫入、讀取等操作。

3.1 給Buffer分配空間

　　要獲得一個Buffer對象就可以通過Buffer類的allocate()方法來實現，如下分別是分配一個48字節的ByteBuffer和1024字符的CharBuffer：

ByteBuffer buf = ByteBuffer.allocate(48);
CharBuffer buf = CharBuffer.allocate(1024);

3.2 往Buffer中寫數據

　　有兩種方式往Buffer中寫入數據：

• 從Channel中往Buffer寫數據；
• 通過Buffer的put()方法寫入數據；

int bytesRead = inChannel.read(buf); // read into buffer
buf.put(127);

　　put()方法有多個重載版本，比如從指定位置寫入數據，或寫入字節數組等。

3.3 flip()

　　flip()方法將Buffer從寫模式切換到讀模式。調用flip()方法會將position設為0，limit設為position之前的值。

3.4 從Buffer讀數據

　　也有兩種方法從Buffer讀取數據：

• 從Buffer中讀數據到Channel中；
• 調用Buffer的get()方法讀取數據；

int bytesWritten = inChannel.write(buf); // read from buffer into channel
byte aByte = buf.get();

3.5 rewind()

　　rewind()方法將position設置為0，可以從頭開始讀數據。

3.6 clear()和compact()

　　當從Buffer讀取數據結束之後要將其切換回寫模式，可以調用clear()、compact()這兩個方法，兩者之間的區別如下：

　　調用clear()，會將position設為0，limit設為capacity，也就是說Buffer被清空了，但是裏面的數據仍然存在，只是這時沒有標記可以告訴你哪些數據是已讀，哪些是未讀。

　　如果讀取到一半需要寫入數據，但是未讀的數據稍後還需要讀取，這時可以使用compact()，其會將所有未讀取的數據複製到Buffer的前面，將position設置到這些數據後面，limit設置為capacity，所以此時是從未讀的數據後面開始寫入新的數據。

3.7 mark()和reset()

　　調用mark()方法可以標誌一個指定的位置(即設置mark值)，之後調用reset()方法時position又會回到之前標記的位置。

 

4. ByteBuffer

 　　ByteBuffer是一個比較基礎的緩衝器，繼承自Buffer，是可以存儲未加工字節的緩衝器，並且也是唯一直接與通道交互的緩衝器。可以通過ByteBuffer的allocate()方法來分配一個固定大小的ByteBuffer，並且其還有一個方法選擇集，用於以原始的字節形式或基本類型輸出和讀取數據。但是，沒辦法輸出或讀取對象，即使是字符串對象也不行。這種處理雖然很低級，但卻正好，因為這是大多數操作系統中更有效的映射方式。

　　ByteBuffer也分為直接和非直接緩衝器，通過allocate()創建的就是非直接緩衝器，而通過allocateDirect()方法就可以創建出一個緩衝器直接緩衝器，這是一個與操作系統有更高耦合性的緩衝器，也就意味着它能夠帶來更高的速度，但是分配的開支也會更大。

　　儘管ByteBuffer只能保存字節類型的數據，但是它具有可以從其所容納的字節中產生出各種不同基本類型值的方法。下面的例子展示怎樣使用這些方法來插入和抽取各種數值：

public class GetData {    
    private static final int BSIZE = 1024;
    public static void main(String[] args){
        ByteBuffer bb = ByteBuffer.allocate(BSIZE);
        int i = 0;
        while(i++ < bb.limit())
            if(bb.get() != 0)
                System.out.println("nonzero");
        System.out.println("i = " + i);
        bb.rewind();
        // store and read a char array:
        bb.asCharBuffer().put("Howdy!");
        char c;
        while((c = bb.getChar()) != 0)
            System.out.print(c + " ");
        System.out.println();
        bb.rewind();
        // store and read a short:
        bb.asShortBuffer().put((short)471142);
        System.out.println(bb.getShort());
        bb.rewind();
        // sotre and read an int:
        bb.asIntBuffer().put(99471142);
        System.out.println(bb.getInt());
        bb.rewind();
        // store and read a long:
        bb.asLongBuffer().put(99471142);
        System.out.println(bb.getLong());
        bb.rewind();
        // store and read a float:
        bb.asFloatBuffer().put(99471142);
        System.out.println(bb.getFloat());
        bb.rewind();
        // store and read a double:
        bb.asDoubleBuffer().put(99471142);
        System.out.println(bb.getDouble());
        bb.rewind();
    }
}

 

5. Buffer類型

　　Java NIO中包含了如下幾種Buffer：

• ByteBuffer
• MappedByteBuffer
• CharBuffer
• DoubleBuffer
• FloatBuffer
• IntBuffer
• LongBuffer
• ShortBuffer

　　這些Buffer類型代表着不同的數據類型，使得可以通過Buffer直接操作如char、short等類型的數據而不是字節數據。其中MappedByteBuffer略有不同，後面會專門總結。

　　通過ByteBuffer我們只能往Buffer直接寫入或者讀取字節數組，但是通過對應類型的Buffer比如CharBuffer、DoubleBuffer等我們可以直接往Buffer寫入char、double等類型的數據。或者利用ByteBuffer的asCharBuffer()、asShorBuffer()等方法獲取其視圖，然後再使用其put()方法即可直接寫入基本數據類型，就像上面的例子。

　　這就是視圖緩衝器(view buffer)可以讓我們通過某個特定的基本數據類型的視窗查看其底層的ByteBuffer。ByteBuffer依然是實際存儲數據的地方，“支持”着前面的視圖，因此對視圖的任何修改都會映射成為對ByteBuffer中數據的修改。這使得我們可以很方便地向ByteBuffer插入數據。視圖還允許我們從ByteBuffer一次一個地(與ByteBuffer所支持的方式相同)或者成批地(通過放入數組中)讀取基本類型值。在下面的例子中，通過IntBuffer操縱ByteBuffer中的int型數據：

public class IntBufferDemo {    
    private static final int BSIZE = 1024;
    public static void main(String[] args){
        ByteBuffer bb = ByteBuffer.allocate(BSIZE);
        IntBuffer ib = bb.asIntBuffer();
        // store an array of int:
        ib.put(new int[]{11,42,47,99,143,811,1016});
        // absolute location read and write:
        System.out.println(ib.get(3));
        ib.put(3,1811);
        // setting a new limit before rewinding the buffer.
        ib.flip();
        while(ib.hasRemaining()){
            int i = ib.get();
            System.out.println(i);
        }
    }
}

　　上例中先用重載后的put()方法存儲一個整數數組。接着get()和put()方法調用直接訪問底層ByteBuffer中的某個整數位置。這些通過直接與ByteBuffer對話訪問絕對位置的方式也同樣適用於基本類型。

 

6. 總結

　　本文簡單總結了Java NIO(Java New IO)，其目的在於提高速度。Java NIO類庫中主要包括Buffer、Channel、Selector，本文主要總結了Buffer相關的知識點：

• Buffer叫緩衝器，她是和Channel(通道)交互的，可以從channel中讀數據到buffer中，或者從buffer往channel中寫數據；
• Buffer內部封裝了一塊內存，提供了一系列API使得可以方便地操作內存中的數據。其內部是通過capacity、position、limit、mark等變量來跟蹤標記封裝的數據的；
• ByteBuffer是最基本的Buffer，是唯一可以直接與通道交互的緩衝器，其可以直接操縱字節數據或字節數組；
• 除了ByteBuffer之外，Buffer還有許多別的類型如：MappedByteBuffer、CharBuffer、DoubleBuffer、FloatBuffer、IntBuffer、LongBuffer、ShortBuffer；
• 雖然只有ByteBuffer能夠直接和通道交互，但是可以從ByteBuffer獲取多種不同的視圖緩衝器，進而同時具備了直接操作基本數據類型和與通道交互的能力；

　　基礎知識的總結也許是比較枯燥的，但是如果你已經看到這裏說明你很有耐心，如果覺得對你有幫助的話，不妨點個贊關注一下吧^_^

 

【精選推薦文章】

智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

帶您來看台北網站建置，台北網頁設計，各種案例分享

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