Matplotlib是一個用Python實現的繪圖庫。現在很多機器學習，深度學習教學資料中都用它來繪製函數圖形。在學習算法過程中，Matplotlib是一個非常趁手的工具。

一般概念

圖形(figure)
類似於畫布，它包含一個或多個子坐標系(axes)。至少有一個坐標系才能有用。

下面是一段簡單的示例代碼，只是創建了一個子坐標系

import matplotlib.pyplot as plt
import numpy as np

fig = plt.figure() #空figure,沒有坐標系.
fig.suptitle("No Axes on this figure") #設置頂部標題

fig, ax_lst = plt.subplots(2, 2) #一個2 x 2 網格的的坐標系

坐標系(Axes): figure的繪圖區域。一個figure只能有可以有多個Axes，但一個Axes只能位於一個figure中。一個Axes包含兩個(在3D情況下有3個)坐標軸(Axis)，Axis的主要作用是限制數據的範圍(可使用Axes的set_xlim()和set_ylim()方法設限制)。每個坐標系有一個標題(title)，使用set_title()設置，一個x軸標籤(x-label，使用set_xlabel()設置)，一個y軸標籤(y-label，使用set_ylabel()設置)。

坐標軸(Axis): 類似於数字線( number-line-like)的對象，可設置圖表的限制並生成刻度和刻度標籤。Locator對象用來決定刻度的位置。刻度標籤字符串使用Formattor格式化。恰當的Locator和Formattor組合可以有效地控制刻度位置可刻度標籤。

畫家(Artist): 一般來說，所有你能在figure中看到的都使用一個畫家(Artist)(包括Figure, Axes和Axis對象)，這其中包含:文本對象(Text), 2D線條(line2D), 集合對象，點(Path)對象等等。當一個figure被渲染時，所有的Artist都會在畫布上回繪圖。大多數Artist被綁定在一個Axes上，不能被多個Axes共享，或從一個Axes移動到另一個。

繪圖函數的輸入類型

所有的繪圖函數期待的輸入類型是np.array或np.ma.masked_array。看起來像數組的類比如np.martrix可能能正常使用。

Matplotlib,pyplot和pylab之間的關係

Matplotlib是整個包，matplotlib.pyplot是Matplotlib中的一個模塊。
對pyplot模塊中的函數來說，總是有一個”當前的”figure和axes。例如在下面的例子中，第一次調用pyplot.plot會創建一個axes，接下來的一系列pyplot.plot調用迴向同一個axes中添加多條線，plt.xlabel, plt.ylabel, plt.title and plt.legend調用回在這個axes中添加標籤，標題和圖例。

x = np.linspace(0, 2, 100)

plt.plot(x, x, label='linear')
plt.plot(x, x**2, label='quadratic')
plt.plot(x, x**3, label='cubic')

plt.xlabel('x label')
plt.ylabel('y label')

plt.title("Simple Plot")

plt.legend()

plt.show()

這段代碼輸出的圖形如下。可以把最後一行的plt.show(),改成plt.savefig("simplePlot.png")，把圖形輸出成png格式的文件。

pylab是一個可方便地把matplotlib.pyplot和numpy批量導入到一個獨立命名空間的模塊，現已被棄用，建議使用pyplot代替。

 

 

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

※USB CONNECTOR 掌控什麼技術要點? 帶您認識其相關發展及效能

※高價3c回收,收購空拍機,收購鏡頭,收購 MACBOOK-更多收購平台討論專區

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

※收購3c瘋!各款手機、筆電、相機、平板,歡迎來詢價!

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

一、前言

在某些情況下，由於網速慢，用戶操作有誤(連續點擊兩下提交按鈕)，頁面卡頓等原因，可能會出現表單數據重複提交造成數據庫保存多條重複數據。

存在如上問題可以交給前端解決，判斷多長時間內不能再次點擊保存按鈕，當然，如果存在聰明的用戶能夠繞過前端驗證，後端更應該去進行攔截處理，下面小編將基於SpringBoot 2.1.8.RELEASE環境通過AOP切面+ 自定義校驗註解+ Redis緩存來解決這一問題。

二、Spring Boot 校驗表單重複提交操作

1、pom.xml中引入所需依賴

<!-- ==================  校驗表單重複提交所需依賴 ===================== -->
<!-- AOP依賴 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>
<!-- Redis -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

2、application.yml中引入Redis配置

spring:
  redis:
    # Redis數據庫索引（默認為0）
    database: 0
    # Redis服務器地址
    host: 127.0.0.1
    # Redis服務器連接端口
    port: 6379
    timeout: 6000
    # Redis服務器連接密碼（默認為空）
    #      password:
    jedis:
      pool:
        max-active: 1000  # 連接池最大連接數（使用負值表示沒有限制）
        max-wait: -1      # 連接池最大阻塞等待時間（使用負值表示沒有限制）
        max-idle: 10      # 連接池中的最大空閑連接
        min-idle: 5       # 連接池中的最小空閑連接

3、自定義註解 @NoRepeatSubmit

// 作用到方法上
@Target(ElementType.METHOD)
// 運行時有效
@Retention(RetentionPolicy.RUNTIME)
public @interface NoRepeatSubmit {
    /**
     * 默認時間3秒
     */
    int time() default 3 * 1000;
}

4、AOP 攔截處理

注：這裏redis存儲的key值可由個人具體業務靈活發揮，這裏只是示例
ex：單用戶登錄情況下可以組合token + url請求路徑,多個用戶可以同時登錄的話，可以再加上ip地址

@Slf4j
@Aspect
@Component
public class NoRepeatSubmitAop {

    @Autowired
    RedisUtil redisUtil;

    /**
     * <p> 【環繞通知】 用於攔截指定方法，判斷用戶表單保存操作是否屬於重複提交 <p>
     *
     *      定義切入點表達式： execution(public * (…))
     *      表達式解釋： execution：主體    public:可省略   *：標識方法的任意返回值  任意包+類+方法(…) 任意參數
     *
     *      com.zhengqing.demo.modules.*.api ： 標識AOP所切服務的包名，即需要進行橫切的業務類
     *      .*Controller ： 標識類名，*即所有類
     *      .*(..) ： 標識任何方法名，括號表示參數，兩個點表示任何參數類型
     *
     * @param pjp：切入點對象
     * @param noRepeatSubmit:自定義的註解對象
     * @return: java.lang.Object
     */
    @Around("execution(* com.zhengqing.demo.modules.*.api.*Controller.*(..)) && @annotation(noRepeatSubmit)")
    public Object doAround(ProceedingJoinPoint pjp, NoRepeatSubmit noRepeatSubmit) {
        try {
            HttpServletRequest request = ((ServletRequestAttributes) Objects.requireNonNull(RequestContextHolder.getRequestAttributes())).getRequest();

            // 拿到ip地址、請求路徑、token
            String ip = IpUtils.getIpAdrress(request);
            String url = request.getRequestURL().toString();
            String token = request.getHeader(Constants.REQUEST_HEADERS_TOKEN);

            // 現在時間
            long now = System.currentTimeMillis();

            // 自定義key值方式
            String key = "REQUEST_FORM_" + ip;
            if (redisUtil.hasKey(key)) {
                // 上次表單提交時間
                long lastTime = Long.parseLong(redisUtil.get(key));
                // 如果現在距離上次提交時間小於設置的默認時間 則 判斷為重複提交  否則 正常提交 -> 進入業務處理
                if ((now - lastTime) > noRepeatSubmit.time()) {
                    // 非重複提交操作 - 重新記錄操作時間
                    redisUtil.set(key, String.valueOf(now));
                    // 進入處理業務
                    ApiResult result = (ApiResult) pjp.proceed();
                    return result;
                } else {
                    return ApiResult.fail("請勿重複提交!");
                }
            } else {
                // 這裡是第一次操作
                redisUtil.set(key, String.valueOf(now));
                ApiResult result = (ApiResult) pjp.proceed();
                return result;
            }
        } catch (Throwable e) {
            log.error("校驗表單重複提交時異常: {}", e.getMessage());
            return ApiResult.fail("校驗表單重複提交時異常!");
        }

    }

}

5、其中用到的Redis工具類

由於太多，這裏就不直接貼出來了，可參考文末給出的案例demo源碼

三、測試

在需要校驗的方法上加上自定義的校驗註解@NoRepeatSubmit即可

@RestController
public class IndexController extends BaseController {

    @NoRepeatSubmit
    @GetMapping(value = "/index", produces = "application/json;charset=utf-8")
    public ApiResult index() {
        return ApiResult.ok("Hello World ~ ");
    }

}

這裏重複訪問此indexapi請求以模擬提交表單測試

第一次訪問

多次刷新此請求，則提示請勿重複提交!

四、總結

實現思路

1. 首先利用AOP切面在進入方法前攔截進行表單重複提交校驗邏輯處理
2. 通過Redis的key-value鍵值對存儲需要的邏輯判斷數據【ex：key存儲用戶提交表單的api請求路徑，value存儲提交時間】
3. 邏輯處理：
   第一次提交時存入相應數據到redis中
   當再次提交保存時從redis緩存中取出上次提交的時間與當前操作時間做判斷，
   如果當前操作時間距離上次操作時間在我們設置的’判斷為重複提交的時間(3秒內)’則為重複提交直接返回重複提交提示語句或其它處理，
   否則為正常提交，進入業務方法處理…

補充

如果api遵從的是嚴格的Restful風格即@PostMapping用於表單提交操作，則可不用自定義註解方式去判斷需要校驗重複提交的路徑，直接在aop切面攔截該請求路徑後，通過反射拿到該方法上的註解是否存在@PostMapping如果存在則是提交表單的api，即進行校驗處理，如果不存在即是其它的@GetMapping、@PutMapping、@DeleteMapping操作…

本文案例demo源碼

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

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

※想要讓你的商品在網路上成為最夯、最多人討論的話題?

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

三層架構介紹

　　我們的開發架構一般都是基於兩種形式，一種C/S架構，也就是客戶端/服務器，另一種是B/S架構，也就是瀏覽器/服務器。在JavaEE開發中，幾乎全部都是基於B/S架構的開發。那麼在B/S架構中，系統標準的三層架構包括：表現層、業務層、持久層。三層架構在我們的實際開發中使用的非常多。

三層職責

表現層

　　也就是我們長說的web層。它負責接收客戶端請求，向客戶端響應結果，通常客戶端使用http協議請求web層，web需要接收http請求，完成http響應。

　　表現層包括展示層和控制層：控制層負責接收請求，展示層負責結果的展示。

　　表現層依賴業務層，接收到客戶端請求一般會調用業務層進行業務處理，並將處理結果響應給客戶端。

　　表現層的設計一般都是使用mvc模型。(mvc是表現層的設計模型，和其他層沒有關係)

業務層

　　也就是我們常說的 service層。它負責業務邏輯處理，和我們開發項目的需求息息相關。web層依賴業務層，但是業務層不依賴web層。

　　業務層在業務處理時可能會依賴持久層，如果要對數據持久化需要保證事務一致性。(也就是我們說的，事務應該放到業務層來控制)

持久層

　　也就是我們常說的dao層。負責數據持久化，包括數據層即數據庫和數據訪問層，數據庫是對數據進行持久化的載體，數據訪問層是業務層和持久層交互的接口，業務層需要通過數據訪問層將數據持久化到數據庫中。

　　通俗的講，持久層就是和數據交互，對數據庫表進行增刪改查的。

mvc設計模式介紹

　　mvc全名是Model View Controller，模型(Model)-視圖(View)-控制器(Controller)的縮寫，是一種用於設計創建web應用程序表現層的模式。mvc中每個部分各司其職：

Model(模型)

　　模型包含業務模型和數據模型，數據模型用於封裝數據，業務模型用於處理業務。

View(視圖)

　　通常指的就是我們的jsp或者html。作用一般就是展示數據的。

　　通過視圖是依據模型數據創建的。

Controller(控制器)

　　是應用程序中處理用戶交互的部分。作用一般就是處理程序邏輯的。

SpringMVC介紹

Spring MVC是什麼？

　　SpringMVC是一種基於Java的實現MVC設計模型的請求驅動類型的輕量級Web框架，屬於SpringFrameWork的後續產品，已經融合在Spring Web Flow裏面。Spring框架提供了構建Web應用程序的全功能MVC模塊。使用Spring可插入的MVC架構，從而在使用Spring進行Web開發時，可以選擇使用Spring的Spring MVC框架或集成其他MVC開發框架，如Struts1(現在一般不用)，Struts2等。

　　SpringMVC已經成為目前最主流的MVC框架之一，並隨着Spring3.0的發布，全面超越Struts2，成為最優秀的MVC框架。

　　它通過一套註解，讓一個簡單的Java類稱為處理請求的控制器，而無需實現任何接口。同時它還支持RESTful編程風格的請求。

總結

　　Spring MVC和Struts2一樣，都是為了解決表現層問題的web框架，他們都是基於MCC設計模式的。而這些表現層框架的主要職責就是處理前端HTTP請求。

 Spring MVC由來？

 Spring MVC全名叫Spring Web MVC，它是Spring家族Web模塊的一個重要成員。這一點，我們可以從Spring的整體結構中看的出來：

 

 

 為什麼學習SpringMVC？

 　　也許你會問，為什麼要學習Spring MVC呢？struts2不才是主流嘛？看SSH的概念有多火？

　　其實很多初學者混淆了一個概念，SSH實際上指的是Struts1.x+Spring+Hibernate。這個概念已經有十幾年的歷史了。在Struts1.x時代，它是當之無愧的霸主，但是在新的MVC框架湧現的時代，形式已經不是這樣了，Struts2.x藉助了Struts1.x的好名聲，讓國內開發人員認為Struts2.x是霸主繼任者(其實兩者在技術上無任何關係)，導致國內程序員大多數學習基於Struts2.x的框架，又一個貌似很多的概念出來了S2SH(Struts2+Spring+Hibernate)整合開發。

 SpringMVC如何處理請求？

 　　SpringMVC是基於MVC設計模型的，MVC模式指的就是Model(業務模型)、View(視圖)、Controller(控制器)。SpringMVC處理請求就是通過MVC這三個角色來實現的。

注：不要把MVC設計模式和工程的三層架構混淆，三層結構指的是表現層、業務層、數據持久層。而MVC只針對表現層進行設計。

　　下面讓我們看看處理流程吧

 

 

 第一個MVC程序

達到效果

1. 學會如果配置前端控制器
2. 如何開發處理器

任務需求

　　訪問/queryItem，返回商品列表頁面，商品數據暫時使用靜態數據(不從數據庫查詢並返回)。

 實現

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.cyb</groupId>
    <artifactId>springmvc-demo01</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>war</packaging>
    <dependencies>
        <!-- spring ioc組件需要的依賴包 -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-beans</artifactId>
            <version>5.2.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>5.2.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.2.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-expression</artifactId>
            <version>5.2.1.RELEASE</version>
        </dependency>

        <!-- 基於AspectJ的aop依賴 -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-aspects</artifactId>
            <version>5.2.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>aopalliance</groupId>
            <artifactId>aopalliance</artifactId>
            <version>1.0</version>
        </dependency>

        <!-- spring MVC依賴包 -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>5.2.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-web</artifactId>
            <version>5.2.1.RELEASE</version>
        </dependency>

        <!-- jstl -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>jstl</artifactId>
            <version>1.2</version>
        </dependency>
        
        <!-- servlet -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <!-- 配置Maven的JDK編譯級別 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.2</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.tomcat.maven</groupId>
                <artifactId>tomcat7-maven-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <port>8080</port>
                </configuration>
            </plugin>
            <!-- tomcat依賴包 -->
            <plugin>
                <groupId>org.apache.tomcat.maven</groupId>
                <artifactId>tomcat7-maven-plugin</artifactId>
                <version>2.2</version>
            </plugin>
        </plugins>
    </build>
</project>

注：

1、依賴添加完之後，項目上右鍵->maven->Update Maven Project

2、項目上右鍵->Java EE Tools->Generate Deployment Descriptor Stub

 web.xml

路徑：src/main/webapp/WEB-INF/web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    version="2.5">
    <!-- 學習前置條件 -->
    <!-- 問題1：web.xml中servelet、filter、listener、context-param加載順序 -->
    <!-- 問題2：load-on-startup標籤的作用，影響了Servlet對象創建的時機 -->
    <!-- 問題3：url-pattern:標籤的配置方式有四種：/dispatcherServlet、/servlet/*、*.do、/ 以上四種配置-->
    <!-- 問題4：url-pattern標籤的配置為什麼配置/就不攔截jsp請求，而配置/*，就會攔截jsp請求 -->
    <!-- 問題4原因：標籤配置為/*報錯，因為它攔截了jsp請求，但是又不能處理jsp請求。 -->
    <!-- 問題5：配置了springmvc去讀取spring配置文件之後，就產生了spring父子容器的問題 -->
    
    <!-- 配置前端控制器 -->
    <servlet>
        <servlet-name>springmvc</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <!-- 設置spring配置文件路徑 -->
        <!-- 如果不設置初始化參數，那麼DispatcherServlet會讀取默認路徑下的配置文件 -->
        <!-- 默認配置文件路徑：/WEB-INF/springmvc-servlet.xml -->
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>classpath:springmvc.xml</param-value>
        </init-param>
        <!-- 指定初始化時機，設置為2，表示Tomcat啟動時，它會跟隨着啟動，DispatcherServlet會跟隨着初始化 -->
        <!-- 如果沒有指定初始化時機，DispatcherServlet就會在第一次被請求的時候，才會初始化，而且只會被初始化一次(單例模式) -->
        <load-on-startup>2</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>springmvc</servlet-name>
        <!-- url-pattern的設置 -->
        <!-- 不要配置為/*，否則報錯 -->
        <!-- 通俗解釋：會攔截整個項目中的資源訪問，包含JSP和靜態資源的訪問,對於JS的訪問，springmvc提供了默認Handler處理器 -->
        <!-- 但是對於JSP來講，springmvc沒有提供默認的處理器，我們也沒有手動編寫對應的處理器，此時按照springmvc的處理流程分析得知，它down了 -->
        <url-pattern>/</url-pattern>
    </servlet-mapping>
</web-app>

springmvc.xml

路徑：src/main/resources/springmvc.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:mvc="http://www.springframework.org/schema/mvc"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/tx
        http://www.springframework.org/schema/tx/spring-tx.xsd
        http://www.springframework.org/schema/mvc
        http://www.springframework.org/schema/mvc/spring-mvc.xsd
        http://www.springframework.org/schema/aop
        http://www.springframework.org/schema/aop/spring-aop.xsd">
    <!-- 處理器類的掃描 -->
    <context:component-scan
        base-package="com.cyb.springmvc.controller"></context:component-scan>
    <!-- 註解映射器 @Controller和@RequestMapping組合這種方式的註解映射的解析 -->
    <!-- <bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping"></bean> -->
    <!-- 註解適配器 -->
    <!-- <bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter"></bean> -->
    <!-- 配置註釋的適配器和映射器，同時還注入其他很多的bean -->
    <!-- <mvc:annotation-driven></mvc:annotation-driven> -->
    <!-- 显示配置視圖解析器 -->
    <bean
        class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="prefix" value="/WEB-INF/jsp/"></property>
        <property name="suffix" value=".jsp"></property>
    </bean>
</beans>

ItemController.java

路徑：/src/main/java/com/cyb/springmvc/controller/ItemController.java

package com.cyb.springmvc.controller;

import java.util.ArrayList;
import java.util.List;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.ModelAndView;

import com.cyb.springmvc.po.item;

/**
 * 處理器的開發方式有多種，比如實現HttpRequestHandler接口、Controller接口的方式、還有註解的方式 企業中使用的一般都是註解的方式
 * 註解的注意事項
 *  1、類上加上@Controller註解(必須是Controller,可以通過源碼找到答案)
 *  2、類上或者方法上面要加上@RequestMapping(必須)
 * 
 * @author apple
 *
 */
@Controller
public class ItemController {
    //@RequestMapping此時填寫的是url
    //ModelAndView：Model標識的是數據類型，View就是最終要展示給用戶的視圖
    @RequestMapping("queryItem")
    public ModelAndView queryItem() {
        //用靜態數據模型
        List<item> itemList=new ArrayList<item>();
        
        item item_1=new item();
        item_1.setName("蘋果手機");
        item_1.setPrice(5000);
        item_1.setDetail("iphoneX蘋果手機!");
        itemList.add(item_1);
        
        item item_2=new item();
        item_2.setName("華為手機");
        item_2.setPrice(6000);
        item_2.setDetail("華為5G網速就是快!");
        itemList.add(item_2);
        ModelAndView mvAndView=new ModelAndView();
        //設置數據模型,相當於request的setAttribute方法,實質上，底層確實也是轉成了request()
        //先將k/v數據放入map中，最終根據視圖對象不同，再進行後續處理
        mvAndView.addObject("itemList",itemList);
        //設置view視圖
        mvAndView.setViewName("/WEB-INF/jsp/item/item-list.jsp");
        return mvAndView;
    }
}

item.java

路徑：src/main/java/com/cyb/springmvc/po/item.java

package com.cyb.springmvc.po;

public class item {
    private String name;
    private double price;
    private String detail;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }

    public String getDetail() {
        return detail;
    }

    public void setDetail(String detail) {
        this.detail = detail;
    }
}

item-list.jsp

 路徑：src/webapp/WEB-INF/jsp/item/item-list.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>查詢商品列表</title>
</head>
<body>
    <form action="${pageContext.request.contextPath }/itemList.do"
        method="post">
        查詢條件：
        <table width="100%" border=1>
            <tr>
                <td><input type="submit" value="查詢" /></td>
            </tr>
        </table>
        商品列表：
        <table width="100%" border=1>
            <tr>
                <td>商品名稱</td>
                <td>商品價格</td>
                <td>商品描述</td>
                <td>操作</td>
            </tr>
            <c:forEach items="${itemList }" var="item">
                <tr>
                    <td>${item.name }</td>
                    <td>${item.price }</td>
                    <td>${item.detail }</td>
                    <td><a
                        href="${pageContext.request.contextPath }/itemEdit.do?id=${item.name}">修改</a></td>
                </tr>
            </c:forEach>

        </table>
    </form>
</body>

</html>

 項目結構圖

 運行

 完整項目

 SpringMVC 框架源碼分析

 框架結構

 程序入口

一、初始化Servlet

二、處理器映射，渲染頁面

 注：標記的方法體，跟蹤進去讀源碼就好啦！~~

默認配置文件

 

 

 

# Default implementation classes for DispatcherServlet's strategy interfaces.
# Used as fallback when no matching beans are found in the DispatcherServlet context.
# Not meant to be customized by application developers.

org.springframework.web.servlet.LocaleResolver=org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver

org.springframework.web.servlet.ThemeResolver=org.springframework.web.servlet.theme.FixedThemeResolver

org.springframework.web.servlet.HandlerMapping=org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,\
    org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping,\
    org.springframework.web.servlet.function.support.RouterFunctionMapping

org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\
    org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\
    org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter,\
    org.springframework.web.servlet.function.support.HandlerFunctionAdapter


org.springframework.web.servlet.HandlerExceptionResolver=org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver,\
    org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver,\
    org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver

org.springframework.web.servlet.RequestToViewNameTranslator=org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator

org.springframework.web.servlet.ViewResolver=org.springframework.web.servlet.view.InternalResourceViewResolver

org.springframework.web.servlet.FlashMapManager=org.springframework.web.servlet.support.SessionFlashMapManager

 

架構流程

1. 用戶發送請求至前端控制器DispatcherServlet
2. DispatcherServlet收到請求調用HandlerMapping處理器映射器
3. 處理器映射器根據請求url找到具體的處理器，生成處理器對象及處理器攔截器(如果有則生成)一併返回給DispatcherServlet
4. DispatcherServlet通過HandlerAdapter處理器適配器調用處理器
5. HandlerAdapter執行處理器(handler，也叫後端控制器)
6. Controller執行完成返回ModelAndView
7. HandlerAdapter將handler執行結果ModelAndView返回給DispatcherServlet
8. DispatcherServlet將ModelAndView傳給ViewReslover視圖解析器
9. ViewReslover解析后返回具體View對象
10. DispatcherServlet對View進行渲染視圖(即將模型數據填充至視圖種)
11. DispatcherServlet響應用戶

 組件說明

 DispatcherServlet：前端控制器

 　　用戶請求到達前端控制器，它就相當於mvc模式中的C，DispatcherServlet是整個流程控制的中心，由它調用其他組件處理用戶的請求，DispatcherServlet的存在降低了組件之間的耦合性。

HandlerMapping：處理器映射器

 　　HandlerMapping負責根據用戶請求找到Handler即處理器，springmvc提供了不同的映射器實現不同的映射方式，例如：配置文件方式，實現接口方式，註解方式等。

Handler：處理器

　　Handler是繼DispatcherServlet前端控制器的後端控制器，在DispatcherServlet的控制下，Handler對具體的用戶請求進行處理。

　　由於Handler涉及到具體的用戶業務請求，所以一般情況需要程序員根據業務需求開發Handler。

HandlerAdapter：處理器適配器

　　通過HandlerAdapter對處理器進行執行，這是適配器模式的應用，通過擴展適配器可以對更多類型的處理器進行執行。

 View Resolver：視圖解析器

　　View Resolver負責將處理結果生成View視圖，View Resolver首先根據邏輯視圖名解析成物理視圖名即具體的頁面地址，再生成View視圖對象，最後對View進行渲染將處理結果通過頁面展示給用戶。

View：視圖

　　springmvc框架提供了很多View視圖類型的支持，包括：jstlView、freemarkerView、pdfView等。我們最常用的視圖就是jsp。

　　一般情況下需要通過頁面標籤或頁面模板技術將模型數據通過頁面展示給用戶，需要由程序員根據業務需求開發具體的頁面。

說明

　　再springmvc的各個組件中，處理器映射器、處理器適配器、視圖解析器稱為springmvc的三大組件。需要用戶開發的組件有：處理器、視圖

三大組件配置(註解方式)

註解映射器和適配器

通過bean標籤配置

RequestMappingHandlerMapping:註解式處理器映射器

　　對類中標記@ResquestMapping的方式進行映射，根據ResquestMapping定義的url匹配ResquestMapping標記的方法，匹配成功返回HandlerMethod對象給前端控制器，HandlerMethod對象中封裝url對應的方法Method。

配置如下：

<!--註解映射器 -->
<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping"/>
<!--註解適配器 -->
<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter"/>

通過mvc標籤配置(推薦)

<mvc:annotation-drivern />

　　mvc:annotation-drivern標籤的作用，詳見AnnotationDrivenBeanDefinitionParser類的parse方法。分析源碼可知：mvc:annotation-drivern往spring容器中註冊以下的一些BeanDefinition

• ContentNegotiationManagerFactoryBean
• RequestMappingHandlerMapping
• ConfigurableWebBindingInitializer
• RequestMappingHandlerAdapter
• CompositeUriComponentsContributorFactoryBean
• ConversionServiceExposingInterceptor
• MappedInterceptor
• ExceptionHandlerExceptionResolver
• ResponseStatusExceptionResolver
• DefaultHandlerExceptionResolver
• BeanNameUrlHandlerMapping
• HttpRequestHandlerAdapter
• SimpleControllerHandlerAdapter
• HandlerMappingIntrospector

視圖解析器

再springmvc.xml文件配置如下：

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
            <!-- 該視圖解析器，默認的視圖類就是JstlView，可以不寫 -->
        <property name="viewClass"
            value="org.springframework.web.servlet.view.JstlView" />
        <property name="prefix" value="/WEB-INF/jsp/" />
        <property name="suffix" value=".jsp" />
    </bean>

• InternalResourceViewResolver：默認支持JSP視圖解析
•  viewClass：JstlView表示JSP模板頁面需要使用JSTL標籤庫，所以classpath中必須包含jstl的相關jar 包。此屬性可以不設置，默認為JstlView。
• prefix 和suffix：查找視圖頁面的前綴和後綴，最終視圖的址為：前綴+邏輯視圖名+後綴，邏輯視圖名需要在controller中返回的ModelAndView指定，比如邏輯視圖名為hello，則最終返回的jsp視圖地址 “WEB-INF/jsp/hello.jsp”

 

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

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

※想要讓你的商品在網路上成為最夯、最多人討論的話題?

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

一、HTTP概況

 

　　20世紀90年代初期，一個主要的新興應用即萬維網（World Wide Web）登上了舞台。Web是一個引起公眾注意的因特網應用。Web的應用層協議是超文本傳輸協議（HTTP），它是Web的核心。HTTP由兩個程序實現：一個客戶程序和一個服務器程序。客戶程序和服務器程序運行在不同的端系統中，通過交換HTTP報文進行會話。HTTP會話定義了這些報文的結構以及客戶和服務器進行報文交換的方式。

　　Web頁面（也叫文檔）是由對象組成的。一個對象只是一個文件，諸如一個HTML文件、一個JPEG圖形、一個Java小程序或一個視頻片段這樣的文件，且他們可通過一個URL地址尋址。多數Web頁面含有一個HTML基本文件以及幾個引用對象。例如，如果一個Web頁面包含HTML基本文件和5個JPEG圖形，那麼這個Web頁面6個對象：一個HTML基本文件加5個圖形。HTML基本文件通過對象的URL地址引用頁面中的其他對象。每個URL地址由兩部分組成：存放對象的服務器主機名和對象的路徑名。Web瀏覽器實現了HTTP的客戶端，Web服務器實現了HTTP的服務器端，它用於存儲Web對象，每個對象由URL尋址。

　　HTTP定義了Web客戶向Web服務器請求Web頁面的方式，以及服務器向客戶傳送Web頁面的方式，其基本思想就是當用戶請求一個Web頁面（如點擊一個超鏈接）時，瀏覽器向服務器發出對該頁面中所包含對象的HTTP請求報文，服務器接收到請求並用包含這些對象的HTTP響應報文進行響應。

　　HTTP使用TCP作為它的支撐運輸協議（而不是在UDP上運行）。HTTP客戶首先發起一個與服務器的TCP連接。一旦連接建立，該瀏覽器和服務器進程就可以通過套接字接口訪問TCP。客戶向它的套接字接口發送HTTP請求報文並從它的套接字接口接收HTTP響應報文。類似的，服務器從它的套接字接口接收HTTP請求報文和向它的套接字接口發送HTTP響應報文。一旦客戶向他的套接字接口發送了一個請求報文，該報文就脫離了客戶控制並進入TCP的控制。TCP為HTTP提供可靠數據傳輸服務。這意味着，一個客戶進程發出的每個HTTP請求報文最終能完整地到達服務器；類似的，服務器進程發出的每個HTTP響應報文最終能完整地到達客戶。

　　注意到下列現象很重要：服務器向客戶發送被請求的文件，而不存儲任何關於該客戶的狀態信息。假如某個特定的客戶在短短的幾秒鐘內兩次請求同一個對象，服務器並不會因為剛剛為該客戶提供了該對象就不再做出反應，而是重新發送該對象，就像服務器已經完全忘記不久之前所做過的事一樣。因為HTTP服務器並不保存關於客戶的任何信息，所以我們說HTTP是一個無狀態協議。

 

二、非持續連接和持續連接

 

　　在許多因特網應用程序中，客戶和服務器在一個相當長的時間範圍內通信，其中客戶發出一系列請求並且服務器對每個請求進行響應。依據應用程序以及該應用程序的使用方式，這一系列請求可以以規則的間隔周期性的或者間斷性的一個接一個發出。當這種客戶-服務器的交互是經TCP進行的，應用程序的研製者就要做一個重要決定，即每個請求/響應對是經一個單獨的TCP連接發送，還是所有的請求及其相應經相同的TCP連接發送呢？採用前一種方法，該應用程序被稱為使用非持續連接；採用后一種方法，該應用程序被稱為使用持續連接。如HTTP既能夠使用非持續連接，也能夠使用持續連接。儘管HTTP在默認方式下使用持續連接，HTTP客戶和服務器也能配置成非持續連接。

1.採用非持續連接的HTTP

　　我們看看在非持續連接情況下，從服務器向客戶傳送一個Web頁面的步驟。假設該頁面含有一個HTML基本文件和10個JPEG圖形，並且這11個對象位於同一台服務器上。該HTML文件的URL為：。我們看看發生了什麼情況：

• HTTP客戶進程在端口號80發起一個到服務器的TCP連接，該端口號是HTTP的默認端口。在客戶和服務器上分別有一個套接字與該連接相關聯。

• HTTP客戶經它的套接字向該服務器發送一個HTTP請求報文。請求報文中包含了路徑名/someDepartment/home.index。

• HTTP服務器進程經它的套接字接收該請求報文，從其存儲器（RAM或磁盤）中檢索出對象，在一個HTTP響應報文中封裝對象，並通過其套接字向客戶發送響應報文。

• HTTP服務器進程通知TCP斷開該TCP連接。（但是直到TCP確認客戶已經完整的收到響應報文為止，它才會實際中斷連接。

• HTTP客戶接收響應報文，TCP連接關閉。該報文指出封裝的對象是一個HTML文件，客戶從響應報文中提取出該文件，檢查該HTML文件，得到對10個JPEG圖形的引用。

• 對每個引用的JPEG圖形對象重複前4個步驟。

　　上面的步驟舉例說明了非持續連接的使用，其中每個TCP連接在服務器發送一個對象后關閉，即該連接並不為其他的對象而持續下來。值得注意的是每個TCP來接只傳輸一個請求報文和響應報文。

　    在上面描述的步驟中，我們有意沒有明確客戶獲得這10個JPEG圖形對象是使用10個串行的TCP連接，還是某些JPEG對象使用了一些并行的TCP連接。事實上，用戶能配置現代瀏覽器以控制并行度。在默認方式下，大部分瀏覽器打開5~10個并行的TCP連接，而每條連接處理一個請求響應事務。如果用戶願意，最大并行連接數可以設置為1，這樣10條連接就會串行建立。

　　我們來簡單估算一下從客戶請求HTML基本文件起到該客戶收到整個文件止所花費的時間。為此，我們給出往返時間（Round-Trip Time，RTT）的定義，該時間是指一個短分組從客戶到服務器然後再返回客戶所花費的時間。RTT包括分組傳播時延、分組在中間路由器和交換機上的排隊時延以及分組處理時延。現在考慮當用戶點擊超鏈接時會發生什麼現象。如圖2-7所示，這引起瀏覽器在它和Web服務器之間發起一個TCP連接；這涉及一次“三次握手”過程。即客戶向服務器發送一個小TCP報文段，服務器用一個小TCP報文段做出確認和響應，最後，客戶向服務器返回確認。三次握手中前兩個部分所耗費的時間佔用了一個RTT。完成了三次握手的前兩個部分后，客戶結合三次握手的第三部分（確認）向該TCP連接發送一個HTTP請求報文。一旦該請求報文到達服務器，服務器就在該TCP連接上發送HTML文件。該HTTP請求/響應用去了另一個RTT。因此，粗略地將，總的響應時間就是兩個RTT加上服務器傳輸HTML文件的時間。

2.採用持續連接的HTTP

　　非持續連接有一些缺點。首先，必須為每一個請求的對象建立和維護一個全新的連接。對於每個這樣的連接，在客戶和服務器中都要分配TCP的緩衝區和保持TCP變量，這給Web服務器帶來了嚴重的負擔，因為一台Web服務器可能同時服務於數以百計不同的客戶的請求。第二，就像我們剛描述的那樣，每一個對象經受兩倍RTT的交付時延，即一個RTT用於創建TCP，另一個RTT用於請求和接收一個對象。

　　在採用持續連接的情況下，服務器在發送響應后保持該TCP連接打開。在相同的客戶與服務器之間的後續請求和響應報文能夠通過相同的連接進行傳送。特別是，一個完整的Web頁面（上例中的HTML基本文件加上10個圖形）可以用單個持續TCP連接進行傳送。更有甚者，位於同一台服務器的多個Web頁面在從該服務器發送給同一個客戶時，可以在單個持續TCP連接上進行。可以一個接一個地發出對對象的這些請求，而不必等待對未決請求（流水線）的回答。一般來說，如果一條連接經過一定的時間間隔（一個可配置的超時間隔）仍未被使用，HTTP服務器就關閉該連接。HTTP的默認模式是使用帶流水線的持續連接。

三、HTTP報文格式

　　HTTP報文有兩種：請求報文和響應報文。

1.HTTP請求報文

　　下面提供了一個典型的HTTP請求報文：

GET /somedir/page.html HTTP/1.1

Host:

Connection: close

User-agent: Mozilla/5.0

Accept-language: fr

　　通過仔細觀察這個簡單的請求報文，我們就能知道很多東西。首先，我們看到該報文是用普通的ASCII文本書寫的，我們看到該報文由5行組成，每行由一個回車和換行符結束。最後一行后再附加一個回車換行符。一個請求報文能夠具有更多的行或者至少為一行。請求行的方法字段可以取幾種不同的值，包括GET、POST、HEAD、PUT和DELETE。當瀏覽器請求一個對象時，使用GET方法，在URL字段帶有請求對象的標識，在本例中，該瀏覽器正在請求對象/somedir/page.html。其版本字段是自解釋的；在本例中，瀏覽器實現的是HTTP/1.1版本。現在我們看看本例的首部行。首部行Host: 指明了對象所在的主機。你也許認為該首部行是不必要的，因為在該主機中已經有一條TCP連接存在了，但是，該首部行提供的信息是Web代理高速緩存所要求的。通過包含Connection: close首部行，該瀏覽器告訴服務器不希望麻煩地使用持續連接，它要求服務器在發送完被請求的對象后就關閉這條連接。User-agent: 首部行用來指明用戶代理，即向服務器發送請求的瀏覽器類型。這裏瀏覽器類型是Mozilla/5.0，即Firefox瀏覽器。這個首部行是有用的，因為服務器可以有效地為不同類型的用戶代理實際發送相同對象的不同版本。（每個版本都由相同的URL尋址。）最後，Accept-language: 首部行表示用戶想得到該對象的法語版本。如果服務器中沒有這樣的對象的話，服務器應當發送它的默認版本。

　　接下來看看如圖2-8所示的一個請求報文的通用格式。你可能注意到了在首部行（和附加的回車和換行）後有一個“實體主體”。使用GET方法是實體主體為空，而使用POST方法時才使用該實體主體。當用戶提交表單時，HTTP客戶常常使用POST方法，例如當用戶向搜索引擎提供搜索關鍵詞時。使用POST報文時，用戶仍可以向服務器請求一個Web頁面，但Web頁面的特定內容依賴於用戶在表單字段中輸入的內容。如果方法字段的值為POST時，則實體主體中包含的就是用戶在表單字段中的輸入值。

　　當然，如果不提“用表單生成的請求報文不是必須使用POST方法”這一點，那將是失職。HTML表單經常使用GET方法，並在（表單字段中）所請求的URL中包括輸入的數據。例如，一個表單使用GET方法，它有兩個字段，分別填寫的是“monkeys”和“bananas”，這樣，該URL結構為? monkeys&bananas。

　　HEAD方法類似GET方法。當服務器收到使用HEAD方法的請求時，將會用一個HTTP報文進行響應，但是並不返回請求對象。應用程序開發者常用HEAD方法進行調試跟蹤。PUT方法常與Web發行工具聯合使用，它允許用戶上傳對象到指定的Web服務器上指定的路徑（目錄）。PUT也被那些需要向Web服務器上傳對象的應用程序使用。DELETE方法允許用戶或者應用程序刪除Web服務器上的對象。

2.HTTP響應報文

　　下面我們提供了一條典型的HTTP響應報文。該響應報文可以是對剛剛討論的例子中請求報文的響應。

HTTP/1.1 200 OK

Connection: close

Date: Tue, 09 Aug 2011 15:44:04 GMT

Server: Apache/2.2.3 (CentOS)

Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT

Content-Length: 6821

Content-Type: text/html

(data data data data data …)

　　我們仔細看這個響應報文。實體主體部分是報文的主要部分，即它包含了所請求的對象本身（表示為data data data data data …）。我們現在來看看首部行。服務器用Connection：close首部行告訴客戶，發送完報文後將關閉該TCP連接。Date：首部行指示服務器產生併發送該響應報文的日期和時間。值得一提的是，這個時間不是指對象創建或者最後修改的時間；而是服務器從它的文件系統中檢索到該對象，插入到響應報文，併發送響應報文的時間。Server：首部行指示該報文是由一台Apache Web服務器產生的，它類似於HTTP請求報文中的User-agent：首部行，Last-Modified：首部行指示了對象創建或者最後修改的日期和時間。Last-Modified：首部行對極可能在本地客戶也可能在網絡緩存服務器（代理服務器）上的對象緩存來說非常重要。Content-Length：首部行知識了被發送對象中的字節數。Content-Type：首部行指示了實體主體中的對象是HTML文本。（該對象類型應該正式地由Content-Type：首部行而不是用文件擴展名來指示。）

　　看過一個例子后，我們再來查看響應報文的通用格式（如圖2-9所示）。我們補充說明一下狀態碼和它們對應的短語。狀態碼及其相應的短語指示了請求的結果。一些常見的狀態碼和相關的短語包括：

• 200 OK：請求成功，信息在返回的響應報文中。

• 301 Moved Permanently：請求的對象已經被永久轉移了，新的URL定義在響應報文的Location：首部行中。**客戶軟件將自動獲取新的URL。

• 400 Bad Request：一個通用差錯代碼，指示該請求不能被服務器理解。

• 404 Not Found：被請求的文檔不在服務器上。

• 505 HTTP Version Not Supported：服務器不支持請求報文使用的HTTP協議版本。

　　你想看一下真正的HTTP響應報文嗎？很容易做到。首先用Telnet登錄到你喜歡的Web服務器上，接下來輸入一個只有一行的請求報文去請求放在該服務器上的某些對象。

　　在linux終端輸入完telnet 80后，會是下面這種情況：

　　然後按下ctrl + ]呼出telnet命令行出現下面這種情況：

　　先按下回車鍵，再輸入HTTP請求，最終得到HTTP響應如下：

　　在telnet命令行上輸入quit退出telnet，如下圖：

 

 

 

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

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

※想要讓你的商品在網路上成為最夯、最多人討論的話題?

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

目錄

@(本文目錄)

1、拋出問題

一個新的消費組訂閱一個已存在的Topic主題時，消費組是從該Topic的哪條消息開始消費呢？

首先翻閱DefaultMQPushConsumer的API時，setConsumeFromWhere(ConsumeFromWhere consumeFromWhere)API映入眼帘，從字面意思來看是設置消費者從哪裡開始消費，正是解開該問題的”鑰匙“。ConsumeFromWhere枚舉類圖如下：

• CONSUME_FROM_MAX_OFFSET
  從消費隊列最大的偏移量開始消費。
• CONSUME_FROM_FIRST_OFFSET
  從消費隊列最小偏移量開始消費。
• CONSUME_FROM_TIMESTAMP
  從指定的時間戳開始消費，默認為消費者啟動之前的30分鐘處開始消費。可以通過DefaultMQPushConsumer#setConsumeTimestamp。

是不是點小激動，還不快試試。

需求：新的消費組啟動時，從隊列最後開始消費，即只消費啟動后發送到消息服務器后的最新消息。

1.1 環境準備

本示例所用到的Topic路由信息如下：

Broker的配置如下(broker.conf)

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH

storePathRootDir=E:/SH2019/tmp/rocketmq_home/rocketmq4.5_simple/store
storePathCommitLog=E:/SH2019/tmp/rocketmq_home/rocketmq4.5_simple/store/commitlog
namesrvAddr=127.0.0.1:9876
autoCreateTopicEnable=false
mapedFileSizeCommitLog=10240
mapedFileSizeConsumeQueue=2000

其中重點修改了如下兩個參數：

• mapedFileSizeCommitLog
  單個commitlog文件的大小，這裏使用10M，方便測試用。
• mapedFileSizeConsumeQueue
  單個consumequeue隊列長度，這裏使用1000，表示一個consumequeue文件中包含1000個條目。

1.2 消息發送者代碼

public static void main(String[] args) throws MQClientException, InterruptedException {
    DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
    producer.setNamesrvAddr("127.0.0.1:9876");
    producer.start();
    for (int i = 0; i < 300; i++) {
        try {
            Message msg = new Message("TopicTest" ,"TagA" , ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
            SendResult sendResult = producer.send(msg);
            System.out.printf("%s%n", sendResult);
        } catch (Exception e) {
            e.printStackTrace();
            Thread.sleep(1000);
        }
    }
    producer.shutdown();
}

通過上述，往TopicTest發送300條消息，發送完畢后，RocketMQ Broker存儲結構如下：

1.3 消費端驗證代碼

public static void main(String[] args) throws InterruptedException, MQClientException {
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("my_consumer_01");
    consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET);
    consumer.subscribe("TopicTest", "*");
    consumer.setNamesrvAddr("127.0.0.1:9876");
    consumer.registerMessageListener(new MessageListenerConcurrently() {
        @Override
        public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
            ConsumeConcurrentlyContext context) {
            System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        }
    });
    consumer.start();
    System.out.printf("Consumer Started.%n");
}

執行上述代碼后，按照期望，應該是不會消費任何消息，只有等生產者再發送消息后，才會對消息進行消費，事實是這樣嗎？執行效果如圖所示：

令人意外的是，竟然從隊列的最小偏移量開始消費了，這就“尷尬”了。難不成是RocketMQ的Bug。帶着這個疑問，從源碼的角度嘗試來解讀該問題，並指導我們實踐。

2、探究CONSUME_FROM_MAX_OFFSET實現原理

對於一個新的消費組，無論是集群模式還是廣播模式都不會存儲該消費組的消費進度，可以理解為-1,此時就需要根據DefaultMQPushConsumer#consumeFromWhere屬性來決定其從何處開始消費，首先我們需要找到其對應的處理入口。我們知道，消息消費者從Broker服務器拉取消息時，需要進行消費隊列的負載，即RebalanceImpl。

溫馨提示：本文不會詳細介紹RocketMQ消息隊列負載、消息拉取、消息消費邏輯，只會展示出通往該問題的簡短流程，如想詳細了解消息消費具體細節，建議購買筆者出版的《RocketMQ技術內幕》書籍。

RebalancePushImpl#computePullFromWhere

public long computePullFromWhere(MessageQueue mq) {
        long result = -1;                                                                                                                                                                                                                  // @1
        final ConsumeFromWhere consumeFromWhere = this.defaultMQPushConsumerImpl.getDefaultMQPushConsumer().getConsumeFromWhere();    
        final OffsetStore offsetStore = this.defaultMQPushConsumerImpl.getOffsetStore();
        switch (consumeFromWhere) {
            case CONSUME_FROM_LAST_OFFSET_AND_FROM_MIN_WHEN_BOOT_FIRST:
            case CONSUME_FROM_MIN_OFFSET:
            case CONSUME_FROM_MAX_OFFSET:
            case CONSUME_FROM_LAST_OFFSET: {                                                                                                                                                                // @2
               // 省略部分代碼
                break;
            }
            case CONSUME_FROM_FIRST_OFFSET: {                                                                                                                                                              // @3
                // 省略部分代碼
                break;
            }
            case CONSUME_FROM_TIMESTAMP: {                                                                                                                                                                  //@4
                // 省略部分代碼
                break;
            }
            default:
                break;
        }
        return result;                                                                                                                                                                                                                  // @5
    }

代碼@1：先解釋幾個局部變量。

• result
  最終的返回結果，默認為-1。
• consumeFromWhere
  消息消費者開始消費的策略，即CONSUME_FROM_LAST_OFFSET等。
• offsetStore
  offset存儲器，消費組消息偏移量存儲實現器。

代碼@2：CONSUME_FROM_LAST_OFFSET(從隊列的最大偏移量開始消費)的處理邏輯，下文會詳細介紹。

代碼@3：CONSUME_FROM_FIRST_OFFSET(從隊列最小偏移量開始消費)的處理邏輯，下文會詳細介紹。

代碼@4：CONSUME_FROM_TIMESTAMP(從指定時間戳開始消費)的處理邏輯，下文會詳細介紹。

代碼@5：返回最後計算的偏移量，從該偏移量出開始消費。

2.1 CONSUME_FROM_LAST_OFFSET計算邏輯

case CONSUME_FROM_LAST_OFFSET: {
    long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);   // @1
    if (lastOffset >= 0) {                                                                                                             // @2
        result = lastOffset;
    }
    // First start,no offset
    else if (-1 == lastOffset) {                                                                                                  // @3
        if (mq.getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {               
            result = 0L;
        } else {
            try {
                result = this.mQClientFactory.getMQAdminImpl().maxOffset(mq);                     
            } catch (MQClientException e) {                                                                              // @4
                result = -1;
            }
        }
    } else {
        result = -1;    
    }
    break;
}

代碼@1：使用offsetStore從消息消費進度文件中讀取消費消費進度，本文將以集群模式為例展開。稍後詳細分析。

代碼@2：如果返回的偏移量大於等於0，則直接使用該offset，這個也能理解，大於等於0，表示查詢到有效的消息消費進度，從該有效進度開始消費，但我們要特別留意lastOffset為0是什麼場景，因為返回0，並不會執行CONSUME_FROM_LAST_OFFSET(語義)。

代碼@3：如果lastOffset為-1,表示當前並未存儲其有效偏移量，可以理解為第一次消費，如果是消費組重試主題，從重試隊列偏移量為0開始消費；如果是普通主題，則從隊列當前的最大的有效偏移量開始消費，即CONSUME_FROM_LAST_OFFSET語義的實現。

代碼@4：如果從遠程服務拉取最大偏移量拉取異常或其他情況，則使用-1作為第一次拉取偏移量。

分析，上述執行的現象，雖然設置的是CONSUME_FROM_LAST_OFFSET，但現象是從隊列的第一條消息開始消費，根據上述源碼的分析，只有從消費組消費進度存儲文件中取到的消息偏移量為0時，才會從第一條消息開始消費，故接下來重點分析消息消費進度存儲器(OffsetStore)在什麼情況下會返回0。

接下來我們將以集群模式來查看一下消息消費進度的查詢邏輯，集群模式的消息進度存儲管理器實現為：
RemoteBrokerOffsetStore,最終Broker端的命令處理類為：ConsumerManageProcessor。

ConsumerManageProcessor#queryConsumerOffset
private RemotingCommand queryConsumerOffset(ChannelHandlerContext ctx, RemotingCommand request) throws RemotingCommandException {
    final RemotingCommand response =
        RemotingCommand.createResponseCommand(QueryConsumerOffsetResponseHeader.class);
    final QueryConsumerOffsetResponseHeader responseHeader =
        (QueryConsumerOffsetResponseHeader) response.readCustomHeader();
    final QueryConsumerOffsetRequestHeader requestHeader =
        (QueryConsumerOffsetRequestHeader) request
            .decodeCommandCustomHeader(QueryConsumerOffsetRequestHeader.class);

    long offset =
        this.brokerController.getConsumerOffsetManager().queryOffset(
            requestHeader.getConsumerGroup(), requestHeader.getTopic(), requestHeader.getQueueId());    // @1

    if (offset >= 0) {                                                                                                                                          // @2
        responseHeader.setOffset(offset);
        response.setCode(ResponseCode.SUCCESS);
        response.setRemark(null);
    } else {                                                                                                                                                       // @3
        long minOffset =
            this.brokerController.getMessageStore().getMinOffsetInQueue(requestHeader.getTopic(),
                requestHeader.getQueueId());                                                                                                     // @4
        if (minOffset <= 0
            && !this.brokerController.getMessageStore().checkInDiskByConsumeOffset(                                // @5
            requestHeader.getTopic(), requestHeader.getQueueId(), 0)) {
            responseHeader.setOffset(0L);
            response.setCode(ResponseCode.SUCCESS);
            response.setRemark(null);
        } else {                                                                                                                                                 // @6
            response.setCode(ResponseCode.QUERY_NOT_FOUND);
            response.setRemark("Not found, V3_0_6_SNAPSHOT maybe this group consumer boot first");
        }
    }
    return response;
}

代碼@1：從消費消息進度文件中查詢消息消費進度。

代碼@2：如果消息消費進度文件中存儲該隊列的消息進度，其返回的offset必然會大於等於0，則直接返回該偏移量該客戶端，客戶端從該偏移量開始消費。

代碼@3：如果未從消息消費進度文件中查詢到其進度，offset為-1。則首先獲取該主題、消息隊列當前在Broker服務器中的最小偏移量(@4)。如果小於等於0(返回0則表示該隊列的文件還未曾刪除過)並且其最小偏移量對應的消息存儲在內存中而不是存在磁盤中，則返回偏移量0，這就意味着ConsumeFromWhere中定義的三種枚舉類型都不會生效，直接從0開始消費，到這裏就能解開其謎團了(@5)。

代碼@6：如果偏移量小於等於0，但其消息已經存儲在磁盤中，此時返回未找到，最終RebalancePushImpl#computePullFromWhere中得到的偏移量為-1。

看到這裏，大家應該能回答文章開頭處提到的問題了吧？

看到這裏，大家應該明白了，為什麼設置的CONSUME_FROM_LAST_OFFSET，但消費組是從消息隊列的開始處消費了吧，原因就是消息消費進度文件中並沒有找到其消息消費進度，並且該隊列在Broker端的最小偏移量為0，說的更直白點，consumequeue/topicName/queueNum的第一個消息消費隊列文件為00000000000000000000,並且消息其對應的消息緩存在Broker端的內存中(pageCache)，其返回給消費端的偏移量為0，故會從0開始消費，而不是從隊列的最大偏移量處開始消費。

為了知識體系的完備性，我們順便來看一下其他兩種策略的計算邏輯。

2.2 CONSUME_FROM_FIRST_OFFSET

case CONSUME_FROM_FIRST_OFFSET: {
    long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);   // @1
    if (lastOffset >= 0) {    // @2
        result = lastOffset;
    } else if (-1 == lastOffset) {  // @3
        result = 0L;
    } else {                                  
        result = -1;                    // @4
    }
    break;
}

從隊列的開始偏移量開始消費，其計算邏輯如下：
代碼@1：首先通過偏移量存儲器查詢消費隊列的消費進度。

代碼@2：如果大於等於0，則從當前該偏移量開始消費。

代碼@3：如果遠程返回-1，表示並沒有存儲該隊列的消息消費進度，從0開始。

代碼@4：否則從-1開始消費。

2.4 CONSUME_FROM_TIMESTAMP

從指定時戳后的消息開始消費。

case CONSUME_FROM_TIMESTAMP: {
    ong lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);   // @1
    if (lastOffset >= 0) {                                                                                                            // @2
        result = lastOffset;
    } else if (-1 == lastOffset) {                                                                                                 // @3
        if (mq.getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
            try {
                result = this.mQClientFactory.getMQAdminImpl().maxOffset(mq);
            } catch (MQClientException e) {
                result = -1;
            }
        } else {
            try {
                long timestamp = UtilAll.parseDate(this.defaultMQPushConsumerImpl.getDefaultMQPushConsumer().getConsumeTimestamp(),
                    UtilAll.YYYYMMDDHHMMSS).getTime();
                result = this.mQClientFactory.getMQAdminImpl().searchOffset(mq, timestamp);
            } catch (MQClientException e) {
                result = -1;
            }
        }
    } else {
        result = -1;
    }
    break;
}

其基本套路與CONSUME_FROM_LAST_OFFSET一樣：
代碼@1：首先通過偏移量存儲器查詢消費隊列的消費進度。

代碼@2：如果大於等於0，則從當前該偏移量開始消費。

代碼@3：如果遠程返回-1，表示並沒有存儲該隊列的消息消費進度，如果是重試主題，則從當前隊列的最大偏移量開始消費，如果是普通主題，則根據時間戳去Broker端查詢，根據查詢到的偏移量開始消費。

原理就介紹到這裏，下面根據上述理論對其進行驗證。

3、猜想與驗證

根據上述理論分析我們得知設置CONSUME_FROM_LAST_OFFSET但並不是從消息隊列的最大偏移量開始消費的“罪魁禍首”是因為消息消費隊列的最小偏移量為0，如果不為0，則就會符合預期，我們來驗證一下這個猜想。
首先我們刪除commitlog目錄下的文件，如圖所示：

其消費隊列截圖如下：

消費端的驗證代碼如下：

public static void main(String[] args) throws InterruptedException, MQClientException {
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("my_consumer_02");
    consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET);
    consumer.subscribe("TopicTest", "*");
    consumer.setNamesrvAddr("127.0.0.1:9876");
    consumer.registerMessageListener(new MessageListenerConcurrently() {
        @Override
        public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
            ConsumeConcurrentlyContext context) {
            System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        }
    });
    consumer.start();
    System.out.printf("Consumer Started.%n");
}

運行結果如下：

並沒有消息存在的消息，符合預期。

4、解決方案

如果在生產環境下，一個新的消費組訂閱一個已經存在比較久的topic，設置CONSUME_FROM_MAX_OFFSET是符合預期的，即該主題的consumequeue/{queueNum}/fileName，fileName通常不會是00000000000000000000，如是是上面文件名，想要實現從隊列的最後開始消費，該如何做呢？那就走自動創建消費組的路子，執行如下命令：

./mqadmin updateSubGroup -n 127.0.0.1:9876 -c DefaultCluster -g my_consumer_05

//克隆一個訂閱了該topic的消費組消費進度
./mqadmin cloneGroupOffset -n 127.0.0.1:9876 -s my_consumer_01 -d my_consumer_05 -t TopicTest

//重置消費進度到當前隊列的最大值
./mqadmin resetOffsetByTime -n 127.0.0.1:9876 -g my_consumer_05 -t TopicTest -s -1

按照上上述命令后，即可實現其目的。

您都看到這裏了，麻煩幫忙點個贊，謝謝您的認可與鼓勵。

—

作者介紹：
丁威，《RocketMQ技術內幕》作者，RocketMQ 社區佈道師，公眾號： 維護者，目前已陸續發表源碼分析Java集合、Java 併發包(JUC)、Netty、Mycat、Dubbo、RocketMQ、Mybatis等源碼專欄。歡迎加入我的知識星球，構建一個高質量的技術交流社群。

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

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

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

※公開收購3c價格,不怕被賤賣!

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

目錄

@
在中主要講的是一些Spring的概述、Spring工廠、Spring屬性注入以及IOC入門，其中最重要的是IOC，上一篇中IOC大概講的小結一下：

然後呢這一篇中主要講一下Spring中除了IOC之外的另一個重要的核心：AOP，在Spring中IOC也好，AOP也好，都必須會二者的XML開發以及註解開發，也就是說IOC和AOP的XML開發以及註解開發都要掌握

1、 AOP 的概述

從專業的角度來講（千萬不要問我有多專業，度娘是我表鍋不對是表嫂QAQ）：

在軟件業，AOP為Aspect Oriented Programming的縮寫，意為：面向切面編程，通過預編譯方式和運行期動態代理實現程序功能的統一維護的一種技術。AOP是OOP的延續，是軟件開發中的一個熱點，也是Spring框架中的一個重要內容，是函數式編程的一種衍生范型。利用AOP可以對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度降低，提高程序的可重用性，同時提高了開發的效率。

從通俗易懂且不失風趣的角度來講：（來自武哥文章）

面向切面編程的目標就是分離關注點。什麼是關注點呢？就是你要做的事，就是關注點。假如你是個公子哥，沒啥人生目標，天天就是衣來伸手，飯來張口，整天只知道玩一件事！那麼，每天你一睜眼，就光想着吃完飯就去玩（你必須要做的事），但是在玩之前，你還需要穿衣服、穿鞋子、疊好被子、做飯等等等等事情，這些事情就是你的關注點，但是你只想吃飯然後玩，那麼怎麼辦呢？這些事情通通交給別人去干。在你走到飯桌之前，有一個專門的僕人A幫你穿衣服，僕人B幫你穿鞋子，僕人C幫你疊好被子，僕人C幫你做飯，然後你就開始吃飯、去玩（這就是你一天的正事），你幹完你的正事之後，回來，然後一系列僕人又開始幫你干這個干那個，然後一天就結束了！
AOP的好處就是你只需要干你的正事，其它事情別人幫你干。也許有一天，你想裸奔，不想穿衣服，那麼你把僕人A解僱就是了！也許有一天，出門之前你還想帶點錢，那麼你再雇一個僕人D專門幫你干取錢的活！這就是AOP。每個人各司其職，靈活組合，達到一種可配置的、可插拔的程序結構。
從Spring的角度看，AOP最大的用途就在於提供了事務管理的能力。事務管理就是一個關注點，你的正事就是去訪問數據庫，而你不想管事務（太煩），所以，Spring在你訪問數據庫之前，自動幫你開啟事務，當你訪問數據庫結束之後，自動幫你提交/回滾事務！

1、1 為什麼學習 AOP

Spring 的 AOP 的由來:AOP 最早由 AOP 聯盟的組織提出的,制定了一套規範.Spring 將 AOP 思想引入到框架中,必須遵守 AOP 聯盟的規範.

Aop解決實際開發中的一些問題:

• AOP 解決 OOP 中遇到的一些問題.是 OOP 的延續和擴展.

對程序進行增強:不修改源碼的情況下：

• AOP 可以進行權限校驗,日誌記錄,性能監控,事務控制.

1、2 AOP底層實現: 代理機制（了解）

Spring 的 AOP 的底層用到兩種代理機制：

• JDK 的動態代理 :針對實現了接口的類產生代理.
• Cglib 的動態代理 :針對沒有實現接口的類產生代理. 應用的是底層的字節碼增強的技術 生成當前類的子類對象

spring底層會完成自動代理，實現了接口的類默認使用的是JDK 的動態代理，相反的，沒有實現接口的類默認使用的是Cglib 的動態代理 ，底層代碼可以不懂但這個概念一定要知道，不然會被鄙視的，O(∩_∩)O哈哈~，下面是底層代碼，有興趣的可以了解了解。

JDK 動態代理增強一個類中方法:

public class MyJDKProxy implements InvocationHandler {
        private UserDao userDao;

        public MyJDKProxy(UserDao userDao) {
            this.userDao = userDao;
        }

        // 編寫工具方法：生成代理：
        public UserDao createProxy() {
            UserDao userDaoProxy = (UserDao) Proxy.newProxyInstance(userDao
                    .getClass().getClassLoader(), userDao.getClass()
                    .getInterfaces(), this);
            return userDaoProxy;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args)
                throws Throwable {
            if ("save".equals(method.getName())) {
                System.out.println("權限校驗================");
            }
            return method.invoke(userDao, args);
        }
    }

Cglib 動態代理增強一個類中的方法:

public class MyCglibProxy implements MethodInterceptor {
        private CustomerDao customerDao;

        public MyCglibProxy(CustomerDao customerDao) {
            this.customerDao = customerDao;
        }

        // 生成代理的方法:
        public CustomerDao createProxy() {
            // 創建 Cglib 的核心類:
            Enhancer enhancer = new Enhancer();
            // 設置父類:
            enhancer.setSuperclass(CustomerDao.class);
            // 設置回調:
            enhancer.setCallback(this);
            // 生成代理：
            CustomerDao customerDaoProxy = (CustomerDao) enhancer.create();
            return customerDaoProxy;
        }

        @Override
        public Object intercept(Object proxy, Method method, Object[] args,
                MethodProxy methodProxy) throws Throwable {
            if ("delete".equals(method.getName())) {
                Object obj = methodProxy.invokeSuper(proxy, args);
                System.out.println("日誌記錄================");
                return obj;
            }
            return methodProxy.invokeSuper(proxy, args);
        }
    }

2、 Spring 基於AspectJ 進行 AOP 的開發入門（XML 的方式）：

首先，Spring為什麼不直接進行Spring的AOP開發呢，而要基於Aspectj呢，是因為，Spring自己的AOP開發實現方式（傳統的AOP開發）繁瑣且複雜，效率極低，於是傳統的AOP開發基本上棄用了，相反Aspectj的AOP開發效率高，所以AOP開發一般是Spring 的基於 AspectJ 的 AOP 開發。

2.1 AOP 的開發中的相關術語:

Aop是一種非常高深的思想，當然會有非常專業的相關術語了（這彎繞的，你打幾分？）

從專業的角度角度概述定義(相對來說比較枯燥不易理解)：

Joinpoint(連接點):所謂連接點是指那些被攔截到的點。在 spring 中,這些點指的是方法,因為 spring 只
支持方法類型的連接點.
Pointcut(切入點):所謂切入點是指我們要對哪些 Joinpoint 進行攔截的定義.
Advice(通知/增強):所謂通知是指攔截到 Joinpoint 之後所要做的事情就是通知.通知分為前置通知,後置
通知,異常通知,最終通知,環繞通知(切面要完成的功能)
Introduction(引介):引介是一種特殊的通知在不修改類代碼的前提下, Introduction 可以在運行期為類
動態地添加一些方法或 Field.
Target(目標對象):代理的目標對象
Weaving(織入):是指把增強應用到目標對象來創建新的代理對象的過程.
spring 採用動態代理織入，而 AspectJ 採用編譯期織入和類裝在期織入
Proxy（代理）:一個類被 AOP 織入增強后，就產生一個結果代理類
Aspect(切面): 是切入點和通知（引介）的結合

基於專業的角度實例分析(相對來說易理解，什麼？畫質差？咳咳…1080p藍光畫質…哎哎哎..大哥..別打…別打…別打臉)：

2.2引入相應的 jar 包

引入jar包：基礎六個jar包、AOP聯盟jar包、spring的AOPjar包、aspectJ的jar包、spring整合aspectj的jar包

• spring 的傳統 AOP 的開發的包：
  spring-aop-4.2.4.RELEASE.jar
  com.springsource.org.aopalliance-1.0.0.jar

• aspectJ 的開發包:
  com.springsource.org.aspectj.weaver-1.6.8.RELEASE.jar
  spring-aspects-4.2.4.RELEASE.jar

  2.3 引入 Spring 的配置文件

  引入 AOP 約束:

 <beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation="
http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/aop 
http://www.springframework.org/schema/aop/spring-aop.xsd">
</beans>

2.4 編寫目標類

創建接口和類:

    public interface OrderDao {
        public void save();

        public void update();

        public void delete();

        public void find();
    }

    public class OrderDaoImpl implements OrderDao {
        @Override
        public void save() {
            System.out.println("保存訂單...");
        }

        @Override
        public void update() {
            System.out.println("修改訂單...");
        }

        @Override
        public void delete() {
            System.out.println("刪除訂單...");
        }

        @Override
        public void find() {
            System.out.println("查詢訂單...");
        }
    }

2.5 目標類的XML配置

<!-- 目標類配置:被增強的類 --> 
<bean id="orderDao" class="com.gx.spring.demo3.OrderDaoImpl"></bean>

2.6 整合 Junit 單元測試

前提：引入 spring-test.jar 測試的jar包，整合 Junit 單元測試之後就不需要每次都重複註冊工廠，只要固定格式在測試類上寫兩個註解，需要的屬性直接注入，之後只關心自己的測試類即可

//固定註解寫法（前提：引入 spring-test.jar 測試的jar包）
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration("classpath:applicationContext.xml")
    public class SpringDemo3 {
        @Resource(name = "orderDao")  //需要的屬性直接注入（前提：引入 spring-test.jar 測試的jar包）
        private OrderDao orderDao;

        @Test
        public void demo1() {
            orderDao.save();
            orderDao.update();
            orderDao.delete();
            orderDao.find();
        }
    }

運行demo出現如下效果：

2.7 通知類型

到這裏，就需要需要對通知類型了解一下（前三者常用）：

前置通知 ：在目標方法執行之前執行.

後置通知 ：在目標方法執行之後執行

如果要獲得後置通知中的返回值，必須注意的是：

環繞通知 ：在目標方法執行前和執行后執行

異常拋出通知：在目標方法執行出現 異常的時候 執行
最終通知 ：無論目標方法是否出現異常 最終通知都會 執行.

通知類型XML配置：

2.8 切入點表達式

execution(表達式)

表達式 : [方法訪問修飾符] 方法返回值 包名.類名.方法名(方法的參數)

切入點表達式所以就是execution( [方法訪問修飾符] 方法返回值 包名.類名.方法名(方法的參數))

其中 [ ] 中的方法訪問修飾符可有可無

切入點表達式各類型例子：

public * com.gx.spring.dao. * .*(..)
com.gx.spring.dao.*.*(..)
com.gx.spring.dao.UserDao+.*(..)
com.gx.spring.dao..*.*(..)

2.9 編寫一個切面類

好了，了解了通知類型以及切入點表達式之後就可以來 編寫一個切面類玩起來了QAQ

public class MyAspectXml {
    // 前置增強
    public void before(){
       System.out.println("前置增強===========");
} }

2.10 配置完成增強

<!-- 配置切面類 --> 
<bean id="myAspectXml" class="com.gx.spring.demo3.MyAspectXml"></bean>
<!-- 進行 aop 的配置 --> 
<aop:config>
<!-- 配置切入點表達式:哪些類的哪些方法需要進行增強 -->
 <aop:pointcut expression="execution(* com.gx.spring.demo3.OrderDao.save(..))" id="pointcut1"/>
<!-- 配置切面 --> 
<aop:aspect ref="myAspectXml"> 
    <aop:before method="before" pointcut-ref="pointcut1"/>
</aop:aspect>
</aop:config>

需要注意的點我都規劃出來了（不用誇我，我知道我長得帥QnQ）

2.11 其他的增強的配置：

<!-- 配置切面類 -->
 <bean id="myAspectXml" class="com.gx.demo3.MyAspectXml"></bean>
    <!-- 進行 aop 的配置 -->
 <aop:config>
    <!-- 配置切入點表達式:哪些類的哪些方法需要進行增強 -->
     <aop:pointcut expression="execution(* com.gx.spring.demo3.*Dao.save(..))" id="pointcut1"/>
     <aop:pointcut expression="execution(* com.gx.spring.demo3.*Dao.delete(..))" id="pointcut2"/>
     <aop:pointcut expression="execution(* com.gx.spring.demo3.*Dao.update(..))" id="pointcut3"/>
     <aop:pointcut expression="execution(* com.gx.spring.demo3.*Dao.find(..))" id="pointcut4"/>
    <!-- 配置切面 --> 
    <aop:aspect ref="myAspectXml">
       <aop:before method="before" pointcut-ref="pointcut1"/>
       <aop:after-returning method="afterReturing"pointcut-ref="pointcut2"/>
       <aop:around method="around" pointcut-ref="pointcut3"/>
       <aop:after-throwing method="afterThrowing" pointcut-ref="pointcut4"/>
       <aop:after method="after" pointcut-ref="pointcut4"/>
    </aop:aspect>
</aop:config>

3、Spring 基於AspectJ 進行 AOP 的開發入門（註解的方式）：

3.1創建項目，引入jar包

引入的jar包如下：

3.2引入配置文件

3.3編寫目標類並配置

編寫目標類：

package com.gx.spring.demo1;

public class OrderDao {

    public void save(){
        System.out.println("保存訂單...");
    }
    public void update(){
        System.out.println("修改訂單...");
    }
    public String delete(){
        System.out.println("刪除訂單...");
        return "鄢寒";
    }
    public void find(){
        System.out.println("查詢訂單...");
    }
}

XML配置：

<!-- 配置目標類 -->
    <bean id="orderDao" class="com.gx.spring.demo1.OrderDao">

    </bean>

3.4編寫切面類並配置

編寫切面類

package com.gx.spring.demo1;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

/**
 * 切面類：註解的切面類
 * @author jt
 */
public class MyAspectAnno {

    public void before(){
        System.out.println("前置增強===========");
    }
}

XML配置：

<!-- 配置切面類 -->
    <bean id="myAspect" class="com.gx.spring.demo1.MyAspectAnno">
    
    </bean>

3.5使用註解的AOP對象目標類進行增強

1、在配置文件中打開註解的AOP開發

<!-- 在配置文件中開啟註解的AOP的開發 -->
    <aop:aspectj-autoproxy/>

2、在切面類上使用註解
在類上使用@Aspect註解代表這是一個切面類
在方法上注入屬性@Before（execution表達式）代表前置增強

@Aspect
public class MyAspectAnno {

    @Before(value="execution(* com.gx.spring.demo1.OrderDao.save(..))")
    public void before(){
        System.out.println("前置增強===========");
    }
}

3.6編寫測試類

package com.gx.spring.demo1;

import javax.annotation.Resource;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

/**
 * Spring的AOP的註解開發
 *
 */
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:applicationContext.xml")
public class SpringDemo1 {
    @Resource(name="orderDao")
    private static OrderDao orderDao;
    
    public static void main(String[] args) {
        
            orderDao.save();
            orderDao.update();
            orderDao.delete();
            orderDao.find();
        
    }
    
}

測試結果：

4、Spring的註解的AOP的通知類型

4.1@Before ：前置通知

@Aspect
public class MyAspectAnno {

    @Before(value="execution(* com.gx.spring.demo1.OrderDao.save(..))")
    public void before(){
        System.out.println("前置增強===========");
    }
}

4.2@AfterReturning ：後置通知

後置通知可以獲取方法返回值

// 後置通知:
    @AfterReturning(value="execution(* com.gx.spring.demo1.OrderDao.save(..))")
    public void afterReturning(Object result){
        System.out.println("後置增強==========="+result);
    }

借用一下XML方式的圖，意思意思啦，意思還是那個意思QnQ

4.3@Around ：環繞通知

// 環繞通知:
    @Around(value="execution(* com.gx.spring.demo1.OrderDao.save(..))")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable{
        System.out.println("環繞前增強==========");
        Object obj  = joinPoint.proceed();
        System.out.println("環繞后增強==========");
        return obj;
    }

4.4@AfterThrowing ：異常拋出通知

測試前記得製造出個異常qnq

// 異常拋出通知:
    @AfterThrowing(value="execution(* com.gx.spring.demo1.OrderDao.save(..))" throwing="e")
    public void afterThrowing(Throwable e){
        System.out.println("異常拋出增強========="+e.getMessage());
    }

4.5@After ：最終通知

// 最終通知
    @After(value="execution(* com.gx.spring.demo1.OrderDao.save(..))")
    public void after(){
        System.out.println("最終增強============");
    }

5、Spring的註解的AOP的切入點的配置

首先，我們發現在Spring 基於AspectJ 進行 AOP 的開發入門（註解的方式）的過程中如果方法過多，通知過多並且作用於一個方法，需求一改變就需要更改相應的源代碼，為了更好的維護，於是有了AOP的切入點的配置，AOP的切入點的配置能很好地決絕改問題！只需要管理AOP的切入點的配置即可！

具體代碼如下：

package com.gx.spring.demo1;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

/**
 * 切面類：註解的切面類
 * @author jt
 */
@Aspect
public class MyAspectAnno {
    // 前置通知:
    @Before(value="MyAspectAnno.pointcut2()")
    public void before(){
        System.out.println("前置增強===========");
    }
    
    // 後置通知:
    @AfterReturning(value="MyAspectAnno.pointcut4()",returning="result")
    public void afterReturning(Object result){
        System.out.println("後置增強==========="+result);
    }
    
    // 環繞通知:
    @Around(value="MyAspectAnno.pointcut3()")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable{
        System.out.println("環繞前增強==========");
        Object obj  = joinPoint.proceed();
        System.out.println("環繞后增強==========");
        return obj;
    }
    
    // 異常拋出通知:
    @AfterThrowing(value="MyAspectAnno.pointcut1()",throwing="e")
    public void afterThrowing(Throwable e){
        System.out.println("異常拋出增強========="+e.getMessage());
    }
    
    // 最終通知
    @After(value="MyAspectAnno.pointcut1()")
    public void after(){
        System.out.println("最終增強============");
    }
    
    // 切入點註解：
    @Pointcut(value="execution(* com.gx.spring.demo1.OrderDao.find(..))")
    private void pointcut1(){}
    @Pointcut(value="execution(* com.gx.spring.demo1.OrderDao.save(..))")
    private void pointcut2(){}
    @Pointcut(value="execution(* com.gx.spring.demo1.OrderDao.update(..))")
    private void pointcut3(){}
    @Pointcut(value="execution(* com.gx.spring.demo1.OrderDao.delete(..))")
    private void pointcut4(){}
}

如果本文對你有一點點幫助，那麼請點個讚唄，謝謝~

最後，若有不足或者不正之處，歡迎指正批評，感激不盡！如果有疑問歡迎留言，絕對第一時間回復！

歡迎各位關注我的公眾號，一起探討技術，嚮往技術，追求技術，說好了來了就是盆友喔…

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

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

※想要讓你的商品在網路上成為最夯、最多人討論的話題?

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!