分類: 3C資訊

  • .NET進階篇06-async異步、thread多線程3

    .NET進階篇06-async異步、thread多線程3

    知識需要不斷積累、總結和沉澱,思考和寫作是成長的催化劑

    梯子

    一、任務Task

    System.Threading.Tasks在.NET4引入,前麵線程的API太多了,控制不方便,而ThreadPool控制能力又太弱,比如做線程的延續、阻塞、取消、超時等功能不太方便,所以Task就抽象了線程功能,在後台使用ThreadPool

    1、啟動任務

    可以使用TaskFactory類或Task類的構造函數和Start()方法,委託可以提供帶有一個Object類型的輸入參數,所以可以給任務傳遞任意數據,還漏了一個常用的Task.Run

    TaskFactory taskFactory = new TaskFactory();
    taskFactory.StartNew(() => 
    {
        Console.WriteLine($"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    Task.Factory.StartNew(() =>
    {
        Console.WriteLine($"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    Task task = new Task(() =>
    {
        Console.WriteLine($"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    task.Start();

    只有Task類實例方式需要Start()去啟動任務,當然可以RunSynchronously()來同步執行任務,主線程會等待,就是用主線程來執行這個task任務

    Task task = new Task(() =>
    {
        Thread.Sleep(10000);
        Console.WriteLine($"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    task.RunSynchronously();

    2、阻塞延續

    在Thread中我們使用join來阻塞等待,在多個Thread時進行控制就不太方便。Task中我們使用實例方法Wait阻塞單個任務或靜態方法WaitAll和WaitAny阻塞多個任務

    var task = new Task(() =>
    {
        Thread.Sleep(5*1000);
        Console.WriteLine($"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    var task2 = new Task(() =>
    {
        Thread.Sleep(10 * 1000);
        Console.WriteLine($"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    task.Start();
    task2.Start();
    //task.Wait();//單任務等待
    //Task.WaitAny(task, task2);//任何一個任務完成就繼續
    Task.WaitAll(task, task2);//任務都完成才繼續

    如果不希望阻塞主線程,實現當一個任務或幾個任務完成后執行別的任務,可以使用Task靜態方法WhenAll和WhenAny,他們將返回一個Task,但這個Task不允許你控制,將會在滿足WhenAll和WhenAny里任務完成時自動完成,然後調用Task的ContinueWith方法,就可以在一個任務完成后緊跟開始另一個任務

    Task.WhenAll(task, task2).ContinueWith((t) =>
    {
        Console.WriteLine($"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });

    Task.Factory工廠中也存在類似ContinueWhenAll和ContinueWhenAny

    3、任務層次結構

    不僅可以在一個任務結束后執行另一個任務,也可以在一個任務內啟動一個任務,這就啟動了一個父子層次結構

    var parentTask = new Task(()=> 
    {
        Console.WriteLine($"parentId={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
        Thread.Sleep(5*1000);
        var childTask = new Task(() =>
        {
            Thread.Sleep(10 * 1000);
            Console.WriteLine($"childId={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}")
        });
        childTask.Start();
    });
    parentTask.Start();

    如果父任務在子任務之前結束,父任務的狀態為WaitingForChildrenToComplete,當子任務也完成時,父任務的狀態就變為RanToCompletion,當然,在創建任務時指定TaskCreationOptions枚舉參數,可以控制任務的創建和執行的可選行為

    4、枚舉參數

    簡單介紹下創建任務中的TaskCreationOptions枚舉參數,創建任務時我們可以提供TaskCreationOptions枚舉參數,用於控制任務的創建和執行的可選行為的標誌

    1. AttachedToParent:指定將任務附加到任務層次結構中的某個父級,意思就是建立父子關係,父任務必須等待子任務完成才可以繼續執行。和WaitAll效果一樣。上面例子如果在創建子任務時指定TaskCreationOptions.AttachedToParent,那麼父任務wait時也會等子任務的結束
    2. DenyChildAttach:不讓子任務附加到父任務上
    3. LongRunning:指定是長時間運行任務,如果事先知道這個任務會耗時比較長,建議設置此項。這樣,Task調度器會創建Thread線程,而不使用ThreadPool線程。因為你長時間佔用ThreadPool線程不還,那它可能必要時會在線程池中開啟新的線程,造成調度壓力
    4. PreferFairness:盡可能公平的安排任務,這意味着較早安排的任務將更可能較早運行,而較晚安排運行的任務將更可能較晚運行。實際通過把任務放到線程池的全局隊列中,讓工作線程去爭搶,默認是在本地隊列中。

    另一個枚舉參數是ContinueWith方法中的TaskContinuationOptions枚舉參數,它除了擁有幾個和上面同樣功能的枚舉值外,還擁有控制任務的取消延續等功能

    1. LazyCancellation:在延續取消的情況下,防止延續的完成直到完成先前的任務。什麼意思呢?
    CancellationTokenSource source = new CancellationTokenSource();
    source.Cancel();
    var task1 = new Task(() => 
    {
        Console.WriteLine($"task1 id={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    var task2 = task1.ContinueWith(t =>
    {
        Console.WriteLine($"task2 id={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    },source.Token);
    var task3 = task2.ContinueWith(t =>
    {
        Console.WriteLine($"task3 id={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    });
    task1.Start();

    上面例子我們企圖task1->task2->task3順序執行,然後通過CancellationToken來取消task2的執行。結果會是怎樣呢?結果task1和task3會并行執行(task3也是會執行的,而且是和task1并行,等於原來的一條鏈變成了兩條鏈),然後我們嘗試使用LazyCancellation,

    var task2 = task1.ContinueWith(t =>
    {
        Console.WriteLine($"task2 id={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
    },source.Token,TaskContinuationOptions.LazyCancellation,TaskScheduler.Current);

    這樣,將會在task1執行完成后,task2才去判斷source.Token,為Cancel就不執行,接下來執行task3就保證了原來的順序

    1. ExecuteSynchronously:指定應同步執行延續任務,比如上例中,在延續任務task2中指定此參數,則task2會使用執行task1的線程來執行,這樣防止線程切換,可以做些共有資源的訪問。不指定的話就隨機,但也能也用到task1的線程
    2. NotOnRanToCompletion:延續任務必須在前面任務非完成狀態下執行
    3. OnlyOnRanToCompletion:延續任務必須在前面任務完成狀態才能執行
    4. NotOnFaulted,OnlyOnCanceled,OnlyOnFaulted等等

    5、任務取消

    在上篇使用Thread時,我們使用一個變量isStop標記是否取消任務,這種訪問共享變量的方式難免會出問題。task中提出CancellationTokenSource類專門處理任務取消,常見用法看下面代碼註釋

    CancellationTokenSource source = new CancellationTokenSource();//構造函數中也可指定延遲取消
    //註冊一個取消時調用的委託
    source.Token.Register(() =>
    {
        Console.WriteLine("當前source已經取消,可以在這裏做一些其他事情(比如資源清理)...");
    });
    var task1 = new Task(() => 
    {
        while (!source.IsCancellationRequested)
        {
            Console.WriteLine($"task1 id={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}");
        }
    },source.Token);
    task1.Start();
    //source.Cancel();//取消
    source.CancelAfter(1000);//延時取消

    6、任務結果

    讓子線程返回結果,可以將信息寫入到線程安全的共享變量中去,或則使用可以返回結果的任務。使用Task的泛型版本Task<TResult>,就可以定義返回結果的任務。Task是繼承自Task的,Result獲取結果時是要阻塞等待直到任務完成返回結果的,內部判斷沒有完成則wait。通過TaskStatus屬性可獲得此任務的狀態是啟動、運行、異常還是取消等

    var task = new Task<string>(() =>
    {
         return "hello ketty";
    });
    task.Start();
    string result = task.Result;

    7、異常

    可以使用AggregateException來接受任務中的異常信息,這是一個聚合異常繼承自Exception,可以遍歷獲取包含的所有異常,以及進行異常處理,決定是否繼續往上拋異常等

    var task = Task.Factory.StartNew(() =>
    {
        var childTask1 = Task.Factory.StartNew(() =>
        {
            throw new Exception("childTask1異常...");
        },TaskCreationOptions.AttachedToParent);
        var childTask12= Task.Factory.StartNew(() =>
        {
            throw new Exception("childTask2異常...");
        }, TaskCreationOptions.AttachedToParent);
    });
    try
    {
        try
        {
            task.Wait();
        }
        catch (AggregateException ex)
        {
            foreach (var item in ex.InnerExceptions)
            {
                Console.WriteLine($"message{item.InnerException.Message}");
            }
            ex.Handle(x =>
            {
                if (x.InnerException.Message == "childTask1異常...")
                {
                    return true;//異常被處理,不繼續往上拋了
                }
                return false;
            });
        }
    }
    catch (Exception ex)
    {
        throw;
    }

    二、并行Parallel

    1、Parallel.For()、Parallel.ForEach()

    在.NET4中,另一個新增的抽象的線程時Parallel類。這個類定義了并行的for和foreach的靜態方法。Parallel.For()和Parallel.ForEach()方法多次調用一個方法,而Parallel.Invoke()方法允許同時調用不同的方法。首先Parallel是會阻塞主線程的,它將讓主線程也參与到任務中
    Parallel.For()類似於for允許語句,并行迭代同一個方法,迭代順序沒有保證的

    ParallelLoopResult result = Parallel.For(010, i =>
    {
        Console.WriteLine($"{i} task:{Task.CurrentId} thread:{Thread.CurrentThread.ManagedThreadId}");
    });
    Console.WriteLine(result.IsCompleted);

    也可以提前中斷Parallel.For()方法。For()方法的一個重載版本接受Action<int,parallelloopstate style=”font-size: inherit; color: inherit; line-height: inherit; margin: 0px; padding: 0px;”>類型參數。一般不使用,像下面這樣,本想大於5就停止,但實際也可能有大於5的任務已經在跑了。可以通過ParallelOptions傳入允許最大線程數以及取消Token等

    ParallelLoopResult result = Parallel.For(010new ParallelOptions() { MaxDegreeOfParallelism = 8 },(i,loop) =>
    {
        Console.WriteLine($"{i} task:{Task.CurrentId} thread:{Thread.CurrentThread.ManagedThreadId}");
        if (i > 5)
        {
            loop.Break();
        }
    });

    2、Parallel.For<TLocal>

    For還有一個高級泛型版本,相當於并行的聚合計算

    ParallelLoopResult For<TLocal>(int fromInclusive, int toExclusive, Func<TLocal> localInit, Func<int, ParallelLoopStateTLocalTLocal> body, Action<TLocal> localFinally);

    像下面這樣我們求0…100的和,第三個參數更定一個種子初始值,第四個參數迭代累計,最後聚合

    int totalNum = 0;
    Parallel.For<int>(0100() => { return 0; }, (current, loop, total) =>
    {
        total += current;
        return total;
    }, (total) =>
    {
        Interlocked.Add(ref totalNum, total);
    });

    上面For用來處理數組數據,ForEach()方法用來處理非數組的數據任務,比如字典數據繼承自IEnumerable的集合等

    3、Parallel.Invoke()

    Parallel.Invoke()則可以并行調用不同的方法,參數傳遞一個Action的委託數組

    Parallel.Invoke(() => { Console.WriteLine($"方法1 thread:{Thread.CurrentThread.ManagedThreadId}"); }
        , () => { Console.WriteLine($"方法2 thread:{Thread.CurrentThread.ManagedThreadId}"); }
        , () => { Console.WriteLine($"方法3 thread:{Thread.CurrentThread.ManagedThreadId}"); });

    4、PLinq

    Plinq,為了能夠達到最大的靈活度,linq有了并行版本。使用也很簡單,只需要將原始集合AsParallel就轉換為支持并行化的查詢。也可以AsOrdered來順序執行,取消Token,強制并行等

    var nums = Enumerable.Range(0100);
    var query = from n in nums.AsParallel()
                select new
                {
                    thread=$"tid={Thread.CurrentThread.ManagedThreadId},datetime={DateTime.Now}"
                };

    三、異步等待AsyncAwait

    異步編程模型,可能還需要大篇幅來學習,這裏先介紹下基本用法,內在本質需要用ILSpy反編譯來看,以後可能要分專題總結。文末先給幾個參考資料,有興趣自己闊以先琢磨琢磨鴨

    1、簡單使用

    這是.NET4.5開始提供的一對語法糖,使得可以較簡便的使用異步編程。async用在方法定義前面,await只能寫在帶有async標記的方法中,任何方法都可以增加async,一般成對出現,只有async沒有意義,只有await會報錯,請先看下面的示例

    private static async void AsyncTest()
    {
        //主線程執行
        Console.WriteLine($"before await ThreadId={Thread.CurrentThread.ManagedThreadId}");
        TaskFactory taskFactory = new TaskFactory();
        Task task = taskFactory.StartNew(() =>
        {
            Thread.Sleep(3000);
            Console.WriteLine($"task ThreadId={Thread.CurrentThread.ManagedThreadId}");
        });
        await task;//主線程到這裏就返回了,執行主線程任務
        //子線程執行,其實是封裝成委託,在task之後成為回調(編譯器功能  狀態機實現) 後面相當於task.ContinueWith()
        //這個回調的線程是不確定的:可能是主線程  可能是子線程  也可能是其他線程,在winform中是主線程
        Console.WriteLine($"after await ThreadId={Thread.CurrentThread.ManagedThreadId}");
    }

    一般使用async都會讓方法返回一個Task的,像下面這樣複雜一點的

    private static async Task<stringAsyncTest2()
    {
        Console.WriteLine($"before await ThreadId={Thread.CurrentThread.ManagedThreadId}");
        TaskFactory taskFactory = new TaskFactory();
        string x = await taskFactory.StartNew(() =>
          {
              Thread.Sleep(3000);
              Console.WriteLine($"task ThreadId={Thread.CurrentThread.ManagedThreadId}");
              return "task over";
          });

        Console.WriteLine($"after await ThreadId={Thread.CurrentThread.ManagedThreadId}");
        return x;
    }

    通過var reslult = AsyncTest2().Result;調用即可。但注意如果調用Wait或Result的代碼位於UI線程,Task的實際執行在其他線程,其需要返回UI線程則會造成死鎖,所以應該Async all the way

    2、優雅

    從上面簡單示例中可以看出異步編程的執行邏輯:主線程A邏輯->異步任務線程B邏輯->主線程C邏輯
    異步方法的返回類型只能是void、Task、Task。示例中異步方法的返回值類型是Task,通常void也不推薦使用,沒有返回值直接用Task就是

    上一篇也大概了解到如果我們要在任務中更新UI,需要調用Invoke通知UI線程來更新,代碼看起來像下面這樣,在一個任務後去更新UI

    private void button1_Click(object sender, EventArgs e)
    {
        var ResultTask = Task.Run(() => {
            Thread.Sleep(5000);
            return "任務完成";
        });
        ResultTask.ContinueWith((r)=> 
        {
            textBox1.Invoke(() => {
                textBox1.Text = r.Result;
            });
        });
    }

    如果使用async/await會看起來像這樣,是不是優雅了許多。以看似同步編程的方式實現異步

    private async void button1_Click(object sender, EventArgs e)
    {
        var t = Task.Run(() => {
            Thread.Sleep(5000);
            return "任務完成";
        });
        textBox1.Text = await t;
    }

    3、最後

    在.NET 4.5中引入的Async和Await兩個新的關鍵字后,用戶能以一種簡潔直觀的方式實現異步編程。甚至都不需要改變代碼的邏輯結構,就能將原來的同步函數改造為異步函數。
    在內部實現上,Async和Await這兩個關鍵字由編譯器轉換為狀態機,通過System.Threading.Tasks中的并行類實現代碼的異步執行。

    字數有點多了,我的能力也就高考作文800字能寫的出奇好。看了很多異步編程,腦袋有點炸,等消化后再輸出一次,技藝不足,只能用輸出倒逼輸入了,下一篇會是線程安全集合、鎖問題、同步問題,基於事件的異步模式等

    Search the fucking web
    Read the fucking maunal

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

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

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

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

  • 利用Python學習線性代數 — 1.1 線性方程組

    利用Python學習線性代數 — 1.1 線性方程組

    利用Python學習線性代數 — 1.1 線性方程組

    系列,

    本節實現的主要功能函數,在源碼文件中,後續章節將作為基本功能調用。

    線性方程

    線性方程組由一個或多個線性方程組成,如
    \[ \begin{array}\\ x_1 – 2 x_2 &= -1\\ -x_1 + 3 x_2 &= 3 \end{array} \]

    求包含兩個變量兩個線性方程的方程組的解,等價於求兩條直線的交點。
    這裏可以畫出書圖1-1和1-2的線性方程組的圖形。
    通過改變線性方程的參數,觀察圖形,體會兩個方程對應直線平行、相交、重合三種可能。

    那麼,怎麼畫二元線性方程的直線呢?

    方法是這樣的:
    假如方程是 \(a x_1 + b x_2 = c\) 的形式,可以寫成 \(x_2 = (c – a x_1) / b\)
    在以 \(x_1\)\(x_2\)為兩個軸的直角坐標系中,\(x_1\)取一組值,如 \((-3, -2.9, -2.8, \dots, 2.9, 3.0)\)
    計算相應的 \(x_2\),然後把所有點 \((x_1, x_2)\) 連起來成為一條線。
    \(b\)\(0\) 時, 則在\(x_1 = c / a\)處畫一條垂直線。

    # 引入Numpy和 Matplotlib庫
    import numpy as np
    from matplotlib import pyplot as plt

    Matplotlib 是Python中使用較多的可視化庫,這裏只用到了它的一些基本功能。

    def draw_line(a, b, c, start=-4, 
                  stop=5, step=0.01):
        """根據線性方程參數繪製一條直線"""
        # 如果b為0,則畫一條垂線
        if np.isclose(b, 0):
            plt.vlines(start, stop, c / a)
        else: # 否則畫 y = (c - a*x) / b
            xs = np.arange(start, stop, step)
            plt.plot(xs, (c - a*xs)/b)
    # 1.1 圖1-1
    draw_line(1, -2, -1)
    draw_line(-1, 3, 3)

    def draw_lines(augmented, start=-4, 
                  stop=5, step=0.01):
        """給定增廣矩陣,畫兩條線."""
        plt.figure()
        for equation in augmented:
            draw_line(*equation, start, stop, step)
        plt.show()
    # Fig. 1-1
    # 增廣矩陣用二維數組表示 
    # [[1, -2, -1], [-1, 3, 3]]
    # 這些数字對應圖1-1對應方程的各項係數
    draw_lines([[1, -2, -1], [-1, 3, 3]])

    # Fig. 1-2
    draw_lines([[1, -2, -2], [-1, 2, 3]])
    # Fig. 1-3
    draw_lines([[1, -2, -1], [-1, 2, 1]])

    • 建議:改變這些係數,觀察直線,體會兩條直線相交、平行和重合的情況

    例如

    draw_lines([[1, -2, -2], [-1, 2, 9]])

    如果對Numpy比較熟悉,則可以採用更簡潔的方式實現上述繪圖功能。
    在計算多條直線方程時,可以利用向量編程的方式,用更少的代碼實現。

    def draw_lines(augmented, start=-4, 
                   stop=5, step=0.01):
        """Draw lines represented by augmented matrix on 2-d plane."""
        am = np.asarray(augmented)
        xs = np.arange(start, stop, step).reshape([1, -1])
        # 同時計算兩條直線的y值
        ys = (am[:, [-1]] - am[:, [1]]*xs) / am[:, [0]]
        for y in ys:
            plt.plot(xs[0], y)
        plt.show()

    矩陣記號

    矩陣是一個數表,在程序中通常用二維數組表示,例如

    # 嵌套列表表示矩陣
    matrix = [[1, -2, 1, 0],
              [0, 2, -8, 8],
              [5, 0, -5, 10]]
    matrix
    [[1, -2, 1, 0], [0, 2, -8, 8], [5, 0, -5, 10]]

    實際工程和研究實踐中,往往會採用一些專門的數值計算庫,簡化和加速計算。
    Numpy庫是Python中數值計算的常用庫。
    在Numpy中,多維數組類型稱為ndarray,可以理解為n dimensional array。
    例如

    # Numpy ndarray 表示矩陣
    matrix = np.array([[1, -2, 1, 0],
                        [0, 2, -8, 8],
                        [5, 0, -5, 10]])
    matrix
    array([[ 1, -2,  1,  0],
           [ 0,  2, -8,  8],
           [ 5,  0, -5, 10]])

    解線性方程組

    本節解線性方程組的方法是 高斯消元法,利用了三種基本行變換。

    1. 把某個方程換成它與另一個方程的倍數的和;
    2. 交換兩個方程的位置;
    3. 某個方程的所有項乘以一個非零項。

    假設線性方程的增廣矩陣是\(A\),其第\(i\)\(j\)列的元素是\(a_{ij}\)
    消元法的基本步驟是:

    • 增廣矩陣中有 \(n\) 行,該方法的每一步處理一行。
      1. 在第\(i\)步,該方法處理第\(i\)
        • \(a_{ii}\)為0,則在剩餘行 \(\{j| j \in (i, n]\}\)中選擇絕對值最大的行\(a_{ij}\)
          • \(a_{ij}\)為0,返回第1步。
          • 否則利用變換2,交換\(A\)的第\(i\)\(j\)行。
      2. 利用行變換3,第\(i\)行所有元素除以\(a_{ii}\),使第 \(i\) 個方程的第 \(i\)個 係數為1
      3. 利用行變換1,\(i\)之後的行減去第\(i\)行的倍數,使這些行的第 \(i\) 列為0

    為了理解這些步驟的實現,這裏先按書中的例1一步步計算和展示,然後再總結成完整的函數。
    例1的增廣矩陣是

    \[ \left[ \begin{array} &1 & -2 & 1 & 0\\ 0 & 2 & -8 & 8\\ 5 & 0 & -5 & 10 \end{array} \right] \]

    # 增廣矩陣
    A = np.array([[1, -2, 1, 0],
                  [0, 2, -8, 8],
                  [5, 0, -5, 10]])
    # 行號從0開始,處理第0行
    i = 0
    # 利用變換3,將第i行的 a_ii 轉成1。這裏a_00已經是1,所不用動
    # 然後利用變換1,把第1行第0列,第2行第0列都減成0。
    # 這裏僅需考慮i列之後的元素,因為i列之前的元素已經是0
    #   即第1行減去第0行的0倍
    #   而第2行減去第0行的5倍
    A[i+1:, i:] = A[i+1:, i:] - A[i+1:, [i]] * A[i, i:]
    A
    array([[  1,  -2,   1,   0],
           [  0,   2,  -8,   8],
           [  0,  10, -10,  10]])
    i = 1
    # 利用變換3,將第i行的 a_ii 轉成1。
    A[i] = A[i] / A[i, i]
    A
    array([[  1,  -2,   1,   0],
           [  0,   1,  -4,   4],
           [  0,  10, -10,  10]])
    # 然後利用變換1,把第2行第i列減成0。
    A[i+1:, i:] = A[i+1:, i:] - A[i+1:, [i]] * A[i, i:]
    A
    array([[  1,  -2,   1,   0],
           [  0,   1,  -4,   4],
           [  0,   0,  30, -30]])
    i = 2
    # 利用變換3,將第i行的 a_ii 轉成1。
    A[i] = A[i] / A[i, i]
    A
    array([[ 1, -2,  1,  0],
           [ 0,  1, -4,  4],
           [ 0,  0,  1, -1]])

    消元法的前向過程就結束了,我們可以總結成一個函數

    def eliminate_forward(augmented): 
        """
        消元法的前向過程.
        
        返回行階梯形,以及先導元素的坐標(主元位置)
        """
        A = np.asarray(augmented, dtype=np.float64)
        # row number of the last row
        pivots = []
        i, j = 0, 0
        while i < A.shape[0] and j < A.shape[1]:
            A[i] = A[i] / A[i, j]
            if (i + 1) < A.shape[0]: # 除最後一行外
                A[i+1:, j:] = A[i+1:, j:] - A[i+1:, [j]] * A[i, j:]
            pivots.append((i, j))
            i += 1
            j += 1
        return A, pivots

    這裡有兩個細節值得注意

    1. 先導元素 \(a_{ij}\),不一定是在主對角線位置,即 \(i\) 不一定等於\(j\).
    2. 最後一行只需要用變換3把先導元素轉為1,沒有剩餘行需要轉換
    # 測試一個增廣矩陣,例1
    A = np.array([[1, -2, 1, 0],
                  [0, 2, -8, 8],
                  [5, 0, -5, 10]])
    A, pivots = eliminate_forward(A)
    print(A)
    print(pivots)
    [[ 1. -2.  1.  0.]
     [ 0.  1. -4.  4.]
     [ 0.  0.  1. -1.]]
    [(0, 0), (1, 1), (2, 2)]

    消元法的後向過程則更簡單一些,對於每一個主元(這裏就是前面的\(a_{ii}\)),將其所在的列都用變換1,使其它行對應的列為0.

    for i, j in reversed(pivots):
        A[:i, j:] = A[:i, j:] - A[[i], j:] * A[:i, [j]] 
    A
    array([[ 1.,  0.,  0.,  1.],
           [ 0.,  1.,  0.,  0.],
           [ 0.,  0.,  1., -1.]])
    def eliminate_backward(simplified, pivots):
        """消元法的後向過程."""
        A = np.asarray(simplified)
        for i, j in reversed(pivots):
            A[:i, j:] = A[:i, j:] - A[[i], j:] * A[:i, [j]] 
        return A

    至此,結合 eliminate_forward 和eliminate_backward函數,可以解形如例1的線性方程。

    然而,存在如例3的線性方程,在eliminate_forward算法進行的某一步,主元為0,需要利用變換2交換兩行。
    交換行時,可以選擇剩餘行中,選擇當前主元列不為0的任意行,與當前行交換。
    這裏每次都採用剩餘行中,當前主元列絕對值最大的行。
    補上行交換的前向過程函數如下

    def eliminate_forward(augmented): 
        """消元法的前向過程"""
        A = np.asarray(augmented, dtype=np.float64)
        # row number of the last row
        pivots = []
        i, j = 0, 0
        while i < A.shape[0] and j < A.shape[1]:
            # if pivot is zero, exchange rows
            if np.isclose(A[i, j], 0):
                if (i + 1) < A.shape[0]:
                    max_k = i + 1 + np.argmax(np.abs(A[i+1:, i]))
                if (i + 1) >= A.shape[0] or np.isclose(A[max_k, i], 0):
                    j += 1
                    continue
                A[[i, max_k]] = A[[max_k, i]]
            A[i] = A[i] / A[i, j]
            if (i + 1) < A.shape[0]:
                A[i+1:, j:] = A[i+1:, j:] - A[i+1:, [j]] * A[i, j:]
            pivots.append((i, j))
            i += 1
            j += 1
        return A, pivots

    行交換時,有一種特殊情況,即剩餘所有行的主元列都沒有非零元素
    這種情況下,在當前列的右側尋找不為零的列,作為新的主元列。

    # 用例3測試eliminate_forward
    aug = [[0, 1, -4, 8],
           [2, -3, 2, 1],
           [4, -8, 12, 1]]
    echelon, pivots = eliminate_forward(aug)
    print(echelon)
    print(pivots)
    [[ 1.   -2.    3.    0.25]
     [ 0.    1.   -4.    0.5 ]
     [ 0.    0.    0.    1.  ]]
    [(0, 0), (1, 1), (2, 3)]

    例3化簡的結果與書上略有不同,由行交換策略不同引起,也說明同一個矩陣可能由多個階梯形。

    結合上述的前向和後向過程,即可以給出一個完整的消元法實現

    def eliminate(augmented):
        """
        利用消元法前向和後向步驟,化簡線性方程組.
        
        如果是矛盾方程組,則僅輸出前向化簡結果,並打印提示
        否則輸出簡化后的方程組,並輸出最後一列
        """
        print(np.asarray(augmented))
        A, pivots = eliminate_forward(augmented)
        print(" The echelon form is\n", A)
        print(" The pivots are: ", pivots)
        pivot_cols = {p[1] for p in pivots}
        simplified = eliminate_backward(A, pivots)
        if (A.shape[1]-1) in pivot_cols:
            print(" There is controdictory.\n", simplified)
        elif len(pivots) == (A.shape[1] -1):
            print(" Solution: ", simplified[:, -1])
            is_correct = solution_check(np.asarray(augmented), 
                                simplified[:, -1])
            print(" Is the solution correct? ", is_correct)
        else:
            print(" There are free variables.\n", simplified)
        print("-"*30)
    eliminate(aug)
    [[ 0  1 -4  8]
     [ 2 -3  2  1]
     [ 4 -8 12  1]]
     The echelon form is
     [[ 1.   -2.    3.    0.25]
     [ 0.    1.   -4.    0.5 ]
     [ 0.    0.    0.    1.  ]]
     The pivots are:  [(0, 0), (1, 1), (2, 3)]
     There is controdictory.
     [[ 1.  0. -5.  0.]
     [ 0.  1. -4.  0.]
     [ 0.  0.  0.  1.]]
    ------------------------------

    利用 Sympy 驗證消元法實現的正確性

    Python的符號計算庫Sympy,有化簡矩陣為行最簡型的方法,可以用來檢驗本節實現的代碼是否正確。

    # 導入 sympy的 Matrix模塊
    from sympy import Matrix
    Matrix(aug).rref(simplify=True)
    # 返回的是行最簡型和主元列的位置
    (Matrix([
     [1, 0, -5, 0],
     [0, 1, -4, 0],
     [0, 0,  0, 1]]), (0, 1, 3))
    echelon, pivots = eliminate_forward(aug)
    simplified = eliminate_backward(echelon, pivots)
    print(simplified, pivots)
    # 輸出與上述rref一致
    [[ 1.  0. -5.  0.]
     [ 0.  1. -4.  0.]
     [ 0.  0.  0.  1.]] [(0, 0), (1, 1), (2, 3)]

    綜合前向和後向步驟,並結果的正確性

    綜合前向和後向消元,就可以得到完整的消元法過程。
    消元結束,如果沒有矛盾(最後一列不是主元列),基本變量數與未知數個數一致,則有唯一解,可以驗證解是否正確。
    驗證的方法是將解與係數矩陣相乘,檢查與原方程的b列一致。

    def solution_check(augmented, solution):
        # 係數矩陣與解相乘
        b = augmented[:, :-1] @ solution.reshape([-1, 1])
        b = b.reshape([-1])
        # 檢查乘積向量與b列一致
        return all(np.isclose(b - augmented[:, -1], np.zeros(len(b))))
    def eliminate(augmented):
        from sympy import Matrix
        print(np.asarray(augmented))
        A, pivots = eliminate_forward(augmented)
        print(" The echelon form is\n", A)
        print(" The pivots are: ", pivots)
        pivot_cols = {p[1] for p in pivots}
        simplified = eliminate_backward(A, pivots)
        if (A.shape[1]-1) in pivot_cols: # 最後一列是主元列
            print(" There is controdictory.\n", simplified)
        elif len(pivots) == (A.shape[1] -1): # 唯一解
            is_correct = solution_check(np.asarray(augmented), 
                                simplified[:, -1])
            print(" Is the solution correct? ", is_correct)
            print(" Solution: \n", simplified)
        else: # 有自由變量
            print(" There are free variables.\n", simplified)
        print("-"*30)
        print("對比Sympy的rref結果")
        print(Matrix(augmented).rref(simplify=True))
        print("-"*30)

    測試書中的例子

    aug_1_1_1 = [[1, -2, 1, 0], 
                 [0, 2, -8, 8], 
                 [5, 0, -5, 10]]
    eliminate(aug_1_1_1)
    # 1.1 example 3
    aug_1_1_3 = [[0, 1, -4, 8],
                 [2, -3, 2, 1],
                 [4, -8, 12, 1]]
    eliminate(aug_1_1_3)
    eliminate([[1, -6, 4, 0, -1],
               [0, 2, -7, 0, 4],
               [0, 0, 1, 2, -3],
               [0, 0, 3, 1, 6]])
    eliminate([[0, -3, -6, 4, 9],
               [-1, -2, -1, 3, 1],
               [-2, -3, 0, 3, -1],
               [1, 4, 5, -9, -7]])
    
    eliminate([[0, 3, -6, 6, 4, -5],
               [3, -7, 8, -5, 8, 9],
               [3, -9, 12, -9, 6, 15]])
    [[ 1 -2  1  0]
     [ 0  2 -8  8]
     [ 5  0 -5 10]]
     The echelon form is
     [[ 1. -2.  1.  0.]
     [ 0.  1. -4.  4.]
     [ 0.  0.  1. -1.]]
     The pivots are:  [(0, 0), (1, 1), (2, 2)]
     Is the solution correct?  True
     Solution: 
     [[ 1.  0.  0.  1.]
     [ 0.  1.  0.  0.]
     [ 0.  0.  1. -1.]]
    ------------------------------
    對比Sympy的rref結果
    (Matrix([
    [1, 0, 0,  1],
    [0, 1, 0,  0],
    [0, 0, 1, -1]]), (0, 1, 2))
    ------------------------------
    [[ 0  1 -4  8]
     [ 2 -3  2  1]
     [ 4 -8 12  1]]
     The echelon form is
     [[ 1.   -2.    3.    0.25]
     [ 0.    1.   -4.    0.5 ]
     [ 0.    0.    0.    1.  ]]
     The pivots are:  [(0, 0), (1, 1), (2, 3)]
     There is controdictory.
     [[ 1.  0. -5.  0.]
     [ 0.  1. -4.  0.]
     [ 0.  0.  0.  1.]]
    ------------------------------
    對比Sympy的rref結果
    (Matrix([
    [1, 0, -5, 0],
    [0, 1, -4, 0],
    [0, 0,  0, 1]]), (0, 1, 3))
    ------------------------------
    [[ 1 -6  4  0 -1]
     [ 0  2 -7  0  4]
     [ 0  0  1  2 -3]
     [ 0  0  3  1  6]]
     The echelon form is
     [[ 1.  -6.   4.   0.  -1. ]
     [ 0.   1.  -3.5  0.   2. ]
     [ 0.   0.   1.   2.  -3. ]
     [-0.  -0.  -0.   1.  -3. ]]
     The pivots are:  [(0, 0), (1, 1), (2, 2), (3, 3)]
     Is the solution correct?  True
     Solution: 
     [[ 1.   0.   0.   0.  62. ]
     [ 0.   1.   0.   0.  12.5]
     [ 0.   0.   1.   0.   3. ]
     [-0.  -0.  -0.   1.  -3. ]]
    ------------------------------
    對比Sympy的rref結果
    (Matrix([
    [1, 0, 0, 0,   62],
    [0, 1, 0, 0, 25/2],
    [0, 0, 1, 0,    3],
    [0, 0, 0, 1,   -3]]), (0, 1, 2, 3))
    ------------------------------
    [[ 0 -3 -6  4  9]
     [-1 -2 -1  3  1]
     [-2 -3  0  3 -1]
     [ 1  4  5 -9 -7]]
     The echelon form is
     [[ 1.   1.5 -0.  -1.5  0.5]
     [-0.   1.   2.  -3.  -3. ]
     [-0.  -0.  -0.   1.  -0. ]
     [ 0.   0.   0.   0.   0. ]]
     The pivots are:  [(0, 0), (1, 1), (2, 3)]
     There are free variables.
     [[ 1.  0. -3.  0.  5.]
     [-0.  1.  2.  0. -3.]
     [-0. -0. -0.  1. -0.]
     [ 0.  0.  0.  0.  0.]]
    ------------------------------
    對比Sympy的rref結果
    (Matrix([
    [1, 0, -3, 0,  5],
    [0, 1,  2, 0, -3],
    [0, 0,  0, 1,  0],
    [0, 0,  0, 0,  0]]), (0, 1, 3))
    ------------------------------
    [[ 0  3 -6  6  4 -5]
     [ 3 -7  8 -5  8  9]
     [ 3 -9 12 -9  6 15]]
     The echelon form is
     [[ 1.         -2.33333333  2.66666667 -1.66666667  2.66666667  3.        ]
     [ 0.          1.         -2.          2.          1.33333333 -1.66666667]
     [ 0.          0.          0.          0.          1.          4.        ]]
     The pivots are:  [(0, 0), (1, 1), (2, 4)]
     There are free variables.
     [[  1.   0.  -2.   3.   0. -24.]
     [  0.   1.  -2.   2.   0.  -7.]
     [  0.   0.   0.   0.   1.   4.]]
    ------------------------------
    對比Sympy的rref結果
    (Matrix([
    [1, 0, -2, 3, 0, -24],
    [0, 1, -2, 2, 0,  -7],
    [0, 0,  0, 0, 1,   4]]), (0, 1, 4))
    ------------------------------

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

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

    ※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

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

  • 同步鎖基本原理與實現

      為充分利用機器性能,人們發明了多線程。但同時帶來了線程安全問題,於是人們又發明了同步鎖。

      這個問題自然人人知道,但你真的了解同步鎖嗎?還是說你會用其中的上鎖與解鎖功能?

      今天我們就一起來深入看同步鎖的原理和實現吧!

     

    一、同步鎖的職責

      同步鎖的職責可以說就一個,限制資源的使用(線程安全從屬)。

      它一般至少會包含兩個功能: 1. 給資源加鎖; 2. 給資源解鎖;另外,它一般還有 等待/通知 即 wait/notify 的功能;

      同步鎖的應用場景:多個線程同時操作一個事務必須保證正確性;一個資源只能同時由一線程訪問操作;一個資源最多只能接入k的併發訪問;保證訪問的順序性;

      同步鎖的實現方式:操作系統調度實現;應用自行實現;CAS自旋;

      同步鎖的幾個問題:

        為什麼它能保證線程安全?

        鎖等待耗CPU嗎?

        使用鎖后性能下降嚴重的原因是啥?

     

    二、同步鎖的實現一:lock/unlock

      其實對於應用層來說,非常多就是 lock/unlock , 這也是鎖的核心。

      AQS 是java中很多鎖實現的基礎,因為它屏蔽了很多繁雜而底層的阻塞操作,為上層抽象出易用的接口。

      我們就以AQS作為跳板,先來看一下上鎖的過程。為不至於陷入具體鎖的業務邏輯中,我們先以最簡單的 CountDownLatch 看看。

        // 先看看 CountDownLatch 的基礎數據結構,可以說是不能再簡單了,就繼承了 AQS,然後簡單覆寫了幾個必要方法。
        // java.util.concurrent.CountDownLatch.Sync
        /**
         * Synchronization control For CountDownLatch.
         * Uses AQS state to represent count.
         */
        private static final class Sync extends AbstractQueuedSynchronizer {
            private static final long serialVersionUID = 4982264981922014374L;
    
            Sync(int count) {
                setState(count);
            }
    
            int getCount() {
                return getState();
            }
    
            protected int tryAcquireShared(int acquires) {
                // 只有一種情況會獲取鎖成功,即 state == 0 的時候
                return (getState() == 0) ? 1 : -1;
            }
    
            protected boolean tryReleaseShared(int releases) {
                // Decrement count; signal when transition to zero
                for (;;) {
                    int c = getState();
                    if (c == 0)
                        return false;
                    // 原始的鎖數量是在初始化時指定的不可變的,每次釋放一個鎖標識
                    int nextc = c-1;
                    if (compareAndSetState(c, nextc))
                        // 只有一情況會釋放鎖成功,即本次釋放后 state == 0
                        return nextc == 0;
                }
            }
        }
        private final Sync sync;

     

    重點1,我們看看上鎖過程,即 await() 的調用。

        public void await() throws InterruptedException {
            // 調用 AQS 的接口,由AQS實現了鎖的骨架邏輯
            sync.acquireSharedInterruptibly(1);
        }
        
        // java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireSharedInterruptibly
        /**
         * Acquires in shared mode, aborting if interrupted.  Implemented
         * by first checking interrupt status, then invoking at least once
         * {@link #tryAcquireShared}, returning on success.  Otherwise the
         * thread is queued, possibly repeatedly blocking and unblocking,
         * invoking {@link #tryAcquireShared} until success or the thread
         * is interrupted.
         * @param arg the acquire argument.
         * This value is conveyed to {@link #tryAcquireShared} but is
         * otherwise uninterpreted and can represent anything
         * you like.
         * @throws InterruptedException if the current thread is interrupted
         */
        public final void acquireSharedInterruptibly(int arg)
                throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
            // 首先嘗試獲取鎖,如果成功就不用阻塞了
            // 而從上面的邏輯我們看到,獲取鎖相當之簡單,所以,獲取鎖本身並沒有太多的性能消耗喲
            // 如果獲取鎖失敗,則會進行稍後嘗試,這應該是複雜而精巧的
            if (tryAcquireShared(arg) < 0)
                doAcquireSharedInterruptibly(arg);
        }
        
        /**
         * Acquires in shared interruptible mode.
         * @param arg the acquire argument
         */
        private void doAcquireSharedInterruptibly(int arg)
            throws InterruptedException {
            // 首先將當前線程添加排隊隊尾,此處會保證線程安全,稍後我們可以看到
            final Node node = addWaiter(Node.SHARED);
            boolean failed = true;
            try {
                for (;;) {
                    // 獲取其上一節點,如果上一節點是頭節點,就代表當前線程可以再次嘗試獲取鎖了
                    final Node p = node.predecessor();
                    if (p == head) {
                        int r = tryAcquireShared(arg);
                        if (r >= 0) {
                            setHeadAndPropagate(node, r);
                            p.next = null; // help GC
                            failed = false;
                            return;
                        }
                    }
                    // 先檢測是否需要阻塞,然後再進行阻塞等待,阻塞由 LockSupport 底層支持
                    // 如果阻塞后,將不會主動喚醒,只會由 unlock 時,主動被通知
                    // 因此,此處即是獲取鎖的最終等待點
                    // 操作系統將不會再次調度到本線程,直到獲取到鎖
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())
                        throw new InterruptedException();
                }
            } finally {
                if (failed)
                    cancelAcquire(node);
            }
        }
    
        // 如此線程安全地添加當前線程到隊尾? CAS 保證
        /**
         * Creates and enqueues node for current thread and given mode.
         *
         * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
         * @return the new node
         */
        private Node addWaiter(Node mode) {
            Node node = new Node(Thread.currentThread(), mode);
            // Try the fast path of enq; backup to full enq on failure
            Node pred = tail;
            if (pred != null) {
                node.prev = pred;
                if (compareAndSetTail(pred, node)) {
                    pred.next = node;
                    return node;
                }
            }
            enq(node);
            return node;
        }
        /**
         * Inserts node into queue, initializing if necessary. See picture above.
         * @param node the node to insert
         * @return node's predecessor
         */
        private Node enq(final Node node) {
            for (;;) {
                Node t = tail;
                if (t == null) { // Must initialize
                    if (compareAndSetHead(new Node()))
                        tail = head;
                } else {
                    node.prev = t;
                    if (compareAndSetTail(t, node)) {
                        t.next = node;
                        return t;
                    }
                }
            }
        }
        
        // 檢測是否需要進行阻塞
        /**
         * Checks and updates status for a node that failed to acquire.
         * Returns true if thread should block. This is the main signal
         * control in all acquire loops.  Requires that pred == node.prev.
         *
         * @param pred node's predecessor holding status
         * @param node the node
         * @return {@code true} if thread should block
         */
        private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
            int ws = pred.waitStatus;
            if (ws == Node.SIGNAL)
                /*
                 * This node has already set status asking a release
                 * to signal it, so it can safely park.
                 */
                 // 只有前置節點是 SIGNAL 狀態的節點,才需要進行 阻塞等待,當然前置節點會在下一次循環中被設置好
                return true;
            if (ws > 0) {
                /*
                 * Predecessor was cancelled. Skip over predecessors and
                 * indicate retry.
                 */
                do {
                    node.prev = pred = pred.prev;
                } while (pred.waitStatus > 0);
                pred.next = node;
            } else {
                /*
                 * waitStatus must be 0 or PROPAGATE.  Indicate that we
                 * need a signal, but don't park yet.  Caller will need to
                 * retry to make sure it cannot acquire before parking.
                 */
                compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
            }
            return false;
        }
        
        // park 阻塞實現
        /**
         * Convenience method to park and then check if interrupted
         *
         * @return {@code true} if interrupted
         */
        private final boolean parkAndCheckInterrupt() {
            // 將當前 AQS 實例作為鎖對象 blocker, 進行操作系統調用阻塞, 所以所有等待鎖的線程將會在同一個鎖前提下執行
            LockSupport.park(this);
            return Thread.interrupted();
        }

      如上,上鎖過程是比較簡單明了的。加入一隊列,然後由操作系統將線程調出。(那麼操作系統是如何把線程調出的呢?有興趣自行研究)

     

    重點2. 解鎖過程,即 countDown() 調用

        public void countDown() {
            // 同樣直接調用 AQS 的接口,由AQS實現了鎖的釋放骨架邏輯
            sync.releaseShared(1);
        }
        // java.util.concurrent.locks.AbstractQueuedSynchronizer#releaseShared
        /**
         * Releases in shared mode.  Implemented by unblocking one or more
         * threads if {@link #tryReleaseShared} returns true.
         *
         * @param arg the release argument.  This value is conveyed to
         *        {@link #tryReleaseShared} but is otherwise uninterpreted
         *        and can represent anything you like.
         * @return the value returned from {@link #tryReleaseShared}
         */
        public final boolean releaseShared(int arg) {
            // 調用業務實現的釋放邏輯,如果成功,再執行底層的釋放,如隊列移除,線程通知等等
            // 在 CountDownLatch 的實現中,只有 state == 0 時才會成功,所以它只會執行一次底層釋放
            // 這也是我們認為 CountDownLatch 能夠做到多線程同時執行的效果的原因之一
            if (tryReleaseShared(arg)) {
                doReleaseShared();
                return true;
            }
            return false;
        }
        
        /**
         * Release action for shared mode -- signals successor and ensures
         * propagation. (Note: For exclusive mode, release just amounts
         * to calling unparkSuccessor of head if it needs signal.)
         */
        private void doReleaseShared() {
            /*
             * Ensure that a release propagates, even if there are other
             * in-progress acquires/releases.  This proceeds in the usual
             * way of trying to unparkSuccessor of head if it needs
             * signal. But if it does not, status is set to PROPAGATE to
             * ensure that upon release, propagation continues.
             * Additionally, we must loop in case a new node is added
             * while we are doing this. Also, unlike other uses of
             * unparkSuccessor, we need to know if CAS to reset status
             * fails, if so rechecking.
             */
            for (;;) {
                Node h = head;
                // 隊列不為空才進行釋放
                if (h != null && h != tail) {
                    int ws = h.waitStatus;
                    // 看過上面的 lock 邏輯,我們知道只要在阻塞狀態,一定是 Node.SIGNAL 
                    if (ws == Node.SIGNAL) {
                        // 狀態改變成功,才進行後續的喚醒邏輯
                        // 因為先改變狀態成功,才算是線程安全的,再進行喚醒,否則進入下一次循環再檢查
                        if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                            continue;            // loop to recheck cases
                        // 將頭節點的下一節點喚醒,如有必要
                        unparkSuccessor(h);
                    }
                    // 這裏的 propagates, 是要傳播啥呢??
                    // 為什麼只喚醒了一個線程,其他線程也可以動了?
                    else if (ws == 0 &&
                             !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                        continue;                // loop on failed CAS
                }
                if (h == head)                   // loop if head changed
                    break;
            }
        }
        /**
         * Wakes up node's successor, if one exists.
         *
         * @param node the node
         */
        private void unparkSuccessor(Node node) {
            /*
             * If status is negative (i.e., possibly needing signal) try
             * to clear in anticipation of signalling.  It is OK if this
             * fails or if status is changed by waiting thread.
             */
            int ws = node.waitStatus;
            if (ws < 0)
                compareAndSetWaitStatus(node, ws, 0);
    
            /*
             * Thread to unpark is held in successor, which is normally
             * just the next node.  But if cancelled or apparently null,
             * traverse backwards from tail to find the actual
             * non-cancelled successor.
             */
            // 喚醒下一個節點
            // 但如果下一節點已經取消等待了,那麼就找下一個沒最近的沒被取消的線程進行喚醒
            // 喚醒只是針對一個線程的喲
            Node s = node.next;
            if (s == null || s.waitStatus > 0) {
                s = null;
                for (Node t = tail; t != null && t != node; t = t.prev)
                    if (t.waitStatus <= 0)
                        s = t;
            }
            if (s != null)
                LockSupport.unpark(s.thread);
        }

     

    重要3. 線程解鎖的傳播性?

      因為從上一節的講解中,我們看到,當用戶調用 countDown 時,僅僅是讓操作系統喚醒了 head 的下一個節點線程或者最近未取消的節點。那麼,從哪裡來的所有線程都獲取了鎖從而運行呢?

      其實是在 獲取鎖的過程中,還有一點我們未看清:

        // java.util.concurrent.locks.AbstractQueuedSynchronizer#doAcquireShared
        /**
         * Acquires in shared uninterruptible mode.
         * @param arg the acquire argument
         */
        private void doAcquireShared(int arg) {
            final Node node = addWaiter(Node.SHARED);
            boolean failed = true;
            try {
                boolean interrupted = false;
                for (;;) {
                    final Node p = node.predecessor();
                    if (p == head) {
                        // 當countDown被調用后,head節點被喚醒,執行
                        int r = tryAcquireShared(arg);
                        if (r >= 0) {
                            // 獲取到鎖后,設置node為下一個頭節點,並把喚醒狀態傳播下去,而這裏面肯定會做一些喚醒其他線程的操作,請看下文
                            setHeadAndPropagate(node, r);
                            p.next = null; // help GC
                            if (interrupted)
                                selfInterrupt();
                            failed = false;
                            return;
                        }
                    }
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())
                        interrupted = true;
                }
            } finally {
                if (failed)
                    cancelAcquire(node);
            }
        }
        
        /**
         * Sets head of queue, and checks if successor may be waiting
         * in shared mode, if so propagating if either propagate > 0 or
         * PROPAGATE status was set.
         *
         * @param node the node
         * @param propagate the return value from a tryAcquireShared
         */
        private void setHeadAndPropagate(Node node, int propagate) {
            Node h = head; // Record old head for check below
            setHead(node);
            /*
             * Try to signal next queued node if:
             *   Propagation was indicated by caller,
             *     or was recorded (as h.waitStatus either before
             *     or after setHead) by a previous operation
             *     (note: this uses sign-check of waitStatus because
             *      PROPAGATE status may transition to SIGNAL.)
             * and
             *   The next node is waiting in shared mode,
             *     or we don't know, because it appears null
             *
             * The conservatism in both of these checks may cause
             * unnecessary wake-ups, but only when there are multiple
             * racing acquires/releases, so most need signals now or soon
             * anyway.
             */
            if (propagate > 0 || h == null || h.waitStatus < 0 ||
                (h = head) == null || h.waitStatus < 0) {
                // 如果有必要,則做一次喚醒下一線程的操作
                // 在 countDown() 不會觸發此操作,所以這裏只是一個內部調用傳播
                Node s = node.next;
                if (s == null || s.isShared())
                    // 此處鎖釋放邏輯如上,總之,又是另一次的喚醒觸發
                    doReleaseShared();
            }
        }

      到此,我們明白了它是怎麼做到一個鎖釋放,所有線程可通行的。也從根本上回答了我們猜想,所有線程同時併發運行。然而並沒有,它只是通過喚醒傳播性來依次喚醒各個等待線程的。從絕對時間性上來講,都是有先後關係的。以後可別再淺顯說是同時執行了喲。

     

    三、 鎖的切換:wait/notify

      上面看出,針對一個lock/unlock 的過程還是很簡單的,由操作系統負責大頭,實現代碼也並不多。

      但是針對稍微有點要求的場景,就會進行條件式的操作。比如:持有某個鎖運行一段代碼,但是,運行時發現某條件不滿足,需要進行等待而不能直接結束,直到條件成立。即所謂的 wait 操作。

      乍一看,wait/notify 與 lock/unlock 很像,其實不然。區分主要是 lock/unlock 是針對整個代碼段的,而 wait/notify 則是針對某個條件的,即獲取了鎖不代表條件成立了,但是條件成立了一定要在鎖的前提下才能進行安全操作。

      那麼,是否 wait/notify 也一樣的實現簡單呢?比如java的最基礎類 Object 類就提供了 wait/notify 功能。

      我們既然想一探究竟,還是以併發包下的實現作為基礎吧,畢竟 java 才是我們的強項。

      本次,咱們以  ArrayBlockingQueue#put/take 作為基礎看下這種場景的使用先。

      ArrayBlockingQueue 的put/take 特性就是,put當隊列滿時,一直阻塞,直到有可用位置才繼續運行下一步。而take當隊列為空時一樣阻塞,直到隊列里有數據才運行下一步。這種場景使用鎖主不好搞了,因為這是一個條件判斷。put/take 如下:

        // java.util.concurrent.ArrayBlockingQueue#put
        /**
         * Inserts the specified element at the tail of this queue, waiting
         * for space to become available if the queue is full.
         *
         * @throws InterruptedException {@inheritDoc}
         * @throws NullPointerException {@inheritDoc}
         */
        public void put(E e) throws InterruptedException {
            checkNotNull(e);
            final ReentrantLock lock = this.lock;
            lock.lockInterruptibly();
            try {
                // 當隊列滿時,一直等待
                while (count == items.length)
                    notFull.await();
                enqueue(e);
            } finally {
                lock.unlock();
            }
        }
        
        // java.util.concurrent.ArrayBlockingQueue#take
        public E take() throws InterruptedException {
            final ReentrantLock lock = this.lock;
            lock.lockInterruptibly();
            try {
                // 當隊列為空時一直等待
                while (count == 0)
                    notEmpty.await();
                return dequeue();
            } finally {
                lock.unlock();
            }
        }

      看起來相當簡單,完全符合人類思維。只是,這裏使用的兩個變量進行控制流程 notFull,notEmpty. 這兩個變量是如何進行關聯的呢?

      在這之前,我們還需要補充下上面的例子,即 notFull.await(), notEmpty.await(); 被阻塞了,何時才能運行呢?如上代碼在各自的入隊和出隊完成之後進行通知就可以了。

        // 與 put 對應,入隊完成后,隊列自然就不為空了,通知下 notEmpty 就好了
        /**
         * Inserts element at current put position, advances, and signals.
         * Call only when holding lock.
         */
        private void enqueue(E x) {
            // assert lock.getHoldCount() == 1;
            // assert items[putIndex] == null;
            final Object[] items = this.items;
            items[putIndex] = x;
            if (++putIndex == items.length)
                putIndex = 0;
            count++;
            // 我已放入一個元素,不為空了
            notEmpty.signal();
        }
        // 與 take 對應,出隊完成后,自然就不可能是滿的了,至少一個空餘空間。
        /**
         * Extracts element at current take position, advances, and signals.
         * Call only when holding lock.
         */
        private E dequeue() {
            // assert lock.getHoldCount() == 1;
            // assert items[takeIndex] != null;
            final Object[] items = this.items;
            @SuppressWarnings("unchecked")
            E x = (E) items[takeIndex];
            items[takeIndex] = null;
            if (++takeIndex == items.length)
                takeIndex = 0;
            count--;
            if (itrs != null)
                itrs.elementDequeued();
            // 我已移除一個元素,肯定沒有滿了,你們繼續放入吧
            notFull.signal();
            return x;
        }

      是不是超級好理解。是的。不過,我們不是想看 ArrayBlockingQueue 是如何實現的,我們是要論清 wait/notify 是如何實現的。因為畢竟,他們不是一個鎖那麼簡單。

        // 三個鎖的關係,即 notEmpty, notFull 都是 ReentrantLock 的條件鎖,相當於是其子集吧
        /** Main lock guarding all access */
        final ReentrantLock lock;
    
        /** Condition for waiting takes */
        private final Condition notEmpty;
    
        /** Condition for waiting puts */
        private final Condition notFull;
        
        public ArrayBlockingQueue(int capacity, boolean fair) {
            if (capacity <= 0)
                throw new IllegalArgumentException();
            this.items = new Object[capacity];
            lock = new ReentrantLock(fair);
            notEmpty = lock.newCondition();
            notFull =  lock.newCondition();
        }
        // lock.newCondition() 是什麼鬼?它是 AQS 中實現的 ConditionObject
        // java.util.concurrent.locks.ReentrantLock#newCondition
        public Condition newCondition() {
            return sync.newCondition();
        }
            // java.util.concurrent.locks.ReentrantLock.Sync#newCondition
            final ConditionObject newCondition() {
                // AQS 中定義
                return new ConditionObject();
            }

      接下來,我們要帶着幾個疑問來看這個 Condition 的對象:

        1. 它的 wait/notify 是如何實現的?
        2. 它是如何與互相進行聯繫的?
        3. 為什麼 wait/notify 必須要在外面的lock獲取之後才能執行?
        4. 它與Object的wait/notify 有什麼相同和不同點?

      能夠回答了上面的問題,基本上對其原理與實現也就理解得差不多了。

     

    重點1. wait/notify 是如何實現的?

      我們從上面可以看到,它是通過調用 await()/signal() 實現的,到底做事如何,且看下面。

            // java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#await()
            /**
             * Implements interruptible condition wait.
             * <ol>
             * <li> If current thread is interrupted, throw InterruptedException.
             * <li> Save lock state returned by {@link #getState}.
             * <li> Invoke {@link #release} with saved state as argument,
             *      throwing IllegalMonitorStateException if it fails.
             * <li> Block until signalled or interrupted.
             * <li> Reacquire by invoking specialized version of
             *      {@link #acquire} with saved state as argument.
             * <li> If interrupted while blocked in step 4, throw InterruptedException.
             * </ol>
             */
            public final void await() throws InterruptedException {
                if (Thread.interrupted())
                    throw new InterruptedException();
                // 添加當前線程到 等待線程隊列中,有 lastWaiter/firstWaiter 維護
                Node node = addConditionWaiter();
                // 釋放當前lock中持有的鎖,詳情且看下文
                int savedState = fullyRelease(node);
                // 從以下開始,將不再保證線程安全性,因為當前的鎖已經釋放,其他線程將會重新競爭鎖使用
                int interruptMode = 0;
                // 循環判定,如果當前節點不在 sync 同步隊列中,那麼就反覆阻塞自己
                // 所以判斷是否在 同步隊列上,是很重要的
                while (!isOnSyncQueue(node)) {
                    // 沒有在同步隊列,阻塞
                    LockSupport.park(this);
                    if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                        break;
                }
                // 當條件被滿足后,需要重新競爭鎖,詳情看下文
                // 競爭到鎖后,原樣返回到 wait 的原點,繼續執行業務邏輯
                if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                    interruptMode = REINTERRUPT;
                // 下面是異常處理,忽略
                if (node.nextWaiter != null) // clean up if cancelled
                    unlinkCancelledWaiters();
                if (interruptMode != 0)
                    reportInterruptAfterWait(interruptMode);
            }
        /**
         * Invokes release with current state value; returns saved state.
         * Cancels node and throws exception on failure.
         * @param node the condition node for this wait
         * @return previous sync state
         */
        final int fullyRelease(Node node) {
            boolean failed = true;
            try {
                int savedState = getState();
                // 預期的,都是釋放鎖成功,如果失敗,說明當前線程並並未獲取到鎖,引發異常
                if (release(savedState)) {
                    failed = false;
                    return savedState;
                } else {
                    throw new IllegalMonitorStateException();
                }
            } finally {
                if (failed)
                    node.waitStatus = Node.CANCELLED;
            }
        }
        /**
         * Releases in exclusive mode.  Implemented by unblocking one or
         * more threads if {@link #tryRelease} returns true.
         * This method can be used to implement method {@link Lock#unlock}.
         *
         * @param arg the release argument.  This value is conveyed to
         *        {@link #tryRelease} but is otherwise uninterpreted and
         *        can represent anything you like.
         * @return the value returned from {@link #tryRelease}
         */
        public final boolean release(int arg) {
            // tryRelease 由客戶端自定義實現
            if (tryRelease(arg)) {
                Node h = head;
                if (h != null && h.waitStatus != 0)
                    unparkSuccessor(h);
                return true;
            }
            return false;
        }
        
        // 如何判定當前線程是否在同步隊列中或者可以進行同步隊列?
        /**
         * Returns true if a node, always one that was initially placed on
         * a condition queue, is now waiting to reacquire on sync queue.
         * @param node the node
         * @return true if is reacquiring
         */
        final boolean isOnSyncQueue(Node node) {
            // 如果上一節點還沒有被移除,當前節點就不能被加入到同步隊列
            if (node.waitStatus == Node.CONDITION || node.prev == null)
                return false;
            // 如果當前節點的下游節點已經存在,則它自身必定已經被移到同步隊列中
            if (node.next != null) // If has successor, it must be on queue
                return true;
            /*
             * node.prev can be non-null, but not yet on queue because
             * the CAS to place it on queue can fail. So we have to
             * traverse from tail to make sure it actually made it.  It
             * will always be near the tail in calls to this method, and
             * unless the CAS failed (which is unlikely), it will be
             * there, so we hardly ever traverse much.
             */
             // 最終直接從同步隊列中查找,如果找到,則自身已經在同步隊列中
            return findNodeFromTail(node);
        }
    
        /**
         * Returns true if node is on sync queue by searching backwards from tail.
         * Called only when needed by isOnSyncQueue.
         * @return true if present
         */
        private boolean findNodeFromTail(Node node) {
            Node t = tail;
            for (;;) {
                if (t == node)
                    return true;
                if (t == null)
                    return false;
                t = t.prev;
            }
        }
        
        // 當條件被滿足后,需要重新競爭鎖,以保證外部的鎖語義,因為之前自己已經將鎖主動釋放
        // 這個鎖與 lock/unlock 時的一毛一樣,沒啥可講的
        // java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued
        /**
         * Acquires in exclusive uninterruptible mode for thread already in
         * queue. Used by condition wait methods as well as acquire.
         *
         * @param node the node
         * @param arg the acquire argument
         * @return {@code true} if interrupted while waiting
         */
        final boolean acquireQueued(final Node node, int arg) {
            boolean failed = true;
            try {
                boolean interrupted = false;
                for (;;) {
                    final Node p = node.predecessor();
                    if (p == head && tryAcquire(arg)) {
                        setHead(node);
                        p.next = null; // help GC
                        failed = false;
                        return interrupted;
                    }
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())
                        interrupted = true;
                }
            } finally {
                if (failed)
                    cancelAcquire(node);
            }
        }

      總結一下 wait 的邏輯:

        1. 前提:自身已獲取到外部鎖;
        2. 將當前線程添加到 ConditionQueue 等待隊列中;
        3. 釋放已獲取到的鎖;
        4. 反覆檢查進入等待,直到當前節點被移動到同步隊列中;
        5. 條件滿足被喚醒,重新競爭外部鎖,成功則返回,否則繼續阻塞;(外部鎖是同一個,這也是要求兩個對象必須存在依賴關係的原因)
        6. wait前線程持有鎖,wait后線程持有鎖,沒有一點外部鎖變化;

     

    重點2. 釐清了 wait, 接下來,我們看 signal() 通知喚醒的實現:

            // java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#signal
            /**
             * Moves the longest-waiting thread, if one exists, from the
             * wait queue for this condition to the wait queue for the
             * owning lock.
             *
             * @throws IllegalMonitorStateException if {@link #isHeldExclusively}
             *         returns {@code false}
             */
            public final void signal() {
                // 只有獲取鎖的實例,才可以進行signal,否則你拿什麼去保證線程安全呢
                if (!isHeldExclusively())
                    throw new IllegalMonitorStateException();
                Node first = firstWaiter;
                // 通知 firstWaiter 
                if (first != null)
                    doSignal(first);
            }
            
            /**
             * Removes and transfers nodes until hit non-cancelled one or
             * null. Split out from signal in part to encourage compilers
             * to inline the case of no waiters.
             * @param first (non-null) the first node on condition queue
             */
            private void doSignal(Node first) {
                // 最多只轉移一個 節點
                do {
                    if ( (firstWaiter = first.nextWaiter) == null)
                        lastWaiter = null;
                    first.nextWaiter = null;
                } while (!transferForSignal(first) &&
                         (first = firstWaiter) != null);
            }
        // 將一個節點從 等待隊列 移動到 同步隊列中,即可參与下一輪競爭
        // 只有確實移動成功才會返回 true
        // 說明:當前線程是持有鎖的線程
        // java.util.concurrent.locks.AbstractQueuedSynchronizer#transferForSignal
        /**
         * Transfers a node from a condition queue onto sync queue.
         * Returns true if successful.
         * @param node the node
         * @return true if successfully transferred (else the node was
         * cancelled before signal)
         */
        final boolean transferForSignal(Node node) {
            /*
             * If cannot change waitStatus, the node has been cancelled.
             */
            if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
                return false;
    
            /*
             * Splice onto queue and try to set waitStatus of predecessor to
             * indicate that thread is (probably) waiting. If cancelled or
             * attempt to set waitStatus fails, wake up to resync (in which
             * case the waitStatus can be transiently and harmlessly wrong).
             */
            // 同步隊列由 head/tail 指針維護
            Node p = enq(node);
            int ws = p.waitStatus;
            // 注意,此處正常情況下並不會喚醒等待線程,僅是將隊列轉移。 
            // 因為當前線程的鎖保護區域並未完成,完成后自然會喚醒其他等待線程
            // 否則將會存在當前線程任務還未執行完成,卻被其他線程搶了先去,那接下來的任務當如何??
            if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
                LockSupport.unpark(node.thread);
            return true;
        }

      總結一下,notify 的功能原理如下:

        1. 前提:自身已獲取到外部鎖;
        2. 轉移下一個等待隊列的節點到同步隊列中;
        3. 如果遇到下一節點被取消情況,順延到再下一節點直到為空,至多轉移一個節點;
        4. 正常情況下不做線程的喚醒操作;

      所以,實現 wait/notify, 最關鍵的就是維護兩個隊列,等待隊列與同步隊列,而且都要求是在有外部鎖保證的情況下執行。

      到此,我們也能回答一個問題:為什麼wait/notify一定要在鎖模式下才能運行?

      因為wait是等待條件成立,此時必定存在競爭需要做保護,而它自身又必須釋放鎖以使外部條件可成立,且後續需要做恢復動作;而notify之後可能還有後續工作必須保障安全,notify只是鎖的一個子集。。。

     

    四、通知所有線程的實現:notifyAll

      有時條件成立后,可以允許所有線程通行,這時就可以進行 notifyAll, 那麼如果達到通知所有的目的呢?是一起通知還是??

      以下是 AQS 中的實現:

            // java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#signalAll
            public final void signalAll() {
                if (!isHeldExclusively())
                    throw new IllegalMonitorStateException();
                Node first = firstWaiter;
                if (first != null)
                    doSignalAll(first);
            }
            /**
             * Removes and transfers all nodes.
             * @param first (non-null) the first node on condition queue
             */
            private void doSignalAll(Node first) {
                lastWaiter = firstWaiter = null;
                do {
                    Node next = first.nextWaiter;
                    first.nextWaiter = null;
                    transferForSignal(first);
                    first = next;
                } while (first != null);
            }

      可以看到,它是通過遍歷所有節點,依次轉移等待隊列到同步隊列(通知)的,原本就沒有人能同時干幾件事的!

      本文從java實現的角度去解析同步鎖的原理與實現,但並不局限於java。道理總是相通的,只是像操作系統這樣的大佬,能幹的活更純粹:比如讓cpu根本不用調度一個線程。

     

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

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

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

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

  • HttpClient在高併發場景下的優化實戰

    HttpClient在高併發場景下的優化實戰

    在項目中使用HttpClient可能是很普遍,尤其在當下微服務大火形勢下,如果服務之間是http調用就少不了跟http客戶端找交道.由於項目用戶規模不同以及應用場景不同,很多時候可能不需要特別處理也.然而在一些高併發場景下必須要做一些優化.

    項目是快遞公司的快件軌跡查詢項目,目前平均每小時調用量千萬級別.軌跡查詢以Oracle為主要數據源,Mongodb為備用,當Oracle不可用時,數據源切換到Mongodb.今年菜鳥團隊加入后,主要數據遷移到了阿里雲上,以Hbase為主要存儲.其中Hbase數據查詢服務由數據解析組以Http方式提供.原有Mongodb棄用,雲上數據源變為主數據源,Oracle作為備用.當數據源切換以後,主要的調用方式也就變成了http方式.在第10月初第一輪雙11壓測試跑上,qps不達標.當然這個問題很好定位,因為十一假之間軌跡域組內已經進行過試跑,當時查的是oracle.十一假期回來后,只有這一處明顯的改動,很容易定位到問題出現在調用上.但具體是雲上Hbase慢,還是網絡傳輸問題(Hbase是阿里雲上的服務,軌跡查詢項目部署在IDC機房).通過雲服務,解析組和網絡運維的配合,確定問題出現在應用程序上.在Http服務調用處打日誌記錄,發現以下問題:

    可以看到每隔一段時間,就會有不少請求的耗時明顯比其它的要高.

    導致這種情況可能可能是HttpClient反覆創建銷毀造成引起來銷,首先憑經驗可能是對HttpClient進行了Dispose操作(Using(HttpClient client=new HttpClient){…})

    如果你裝了一些第三方插件,當你寫的HttpClient沒有被Using包圍的時候會給出重構建議,建議加上Using或者手動dispose.然而實際中是否要dispose還要視情況而定,對於一般項目大家的感覺可能是不加也沒有大問題,加了也還ok.但是實際項目中,一般不建議反覆重新創建這個對象,關於HttpClient是否需要Dispose請看

    在對這個問題的答案里,提問者指出微軟的一些示例也是沒有使用using的.下面一個比較熱的回答指出HttpClient生命周期應該和應用程序生命周期一致,只要應用程序需要Http請求,就不應用把它Dispose掉.下面的一個仍然相對比較熱的回答指出一般地,帶有Dispose方法的對象都應當被dispose掉,但是HttpClient是一個例外.

    當然以上只是結合自己的經驗對一個大家都可能比較困惑的問題給出一個建議,實際上對於一般的項目,用還是不用Dispose都不會造成很大問題.本文中上面提到的問題跟HttpClient也沒有關係,因為程序中使用的Http客戶端是基於HttpWebRequest封裝的.

    問題排查及優化

    經過查詢相關資料以及同行的經驗分享(給了很大啟發)

    查看代碼,request.KeepAlive = true;查詢,這個屬性其實是設置一個’Keep-alive’請求header,當時同事封裝Http客戶端的場景現場無從得知,然而對於本文中提到的場景,由於每次請求的都是同一個接口,因此保持持續連接顯然能夠減少反覆創建tcp連接的開銷.因此註釋掉這一行再發布測試,以上問題便不復出現了!

    當然實際中做的優化絕不僅僅是這一點,如果僅僅是這樣,一句話就能夠說完了,大家都記住以後就這樣做就Ok了.實際上還參考了不少大家在實際項目中的經驗或者坑.下面把整個HttpClient代碼貼出來,下面再對關鍵部分進行說明.

     public static string Request(string requestUrl, string requestData, out bool isSuccess, string contentType = "application/x-www-form-urlencoded;charset=utf8")
        {
            string apiResult = "";
            isSuccess = false;
            if (string.IsNullOrEmpty(requestData))
            {
                return apiResult;
            }
            HttpWebRequest request = null;
            HttpWebResponse response = null;
            try
            {
                byte[] buffer = Encoding.UTF8.GetBytes(requestData);
                request = WebRequest.Create($"{requestUrl}") as HttpWebRequest;
                request.ContentType = "application/json";
                request.Method = "POST";
                request.ContentLength = buffer.Length;
                request.Timeout =200;
                request.ReadWriteTimeout =  Const.HttpClientReadWriteTimeout
                request.ServicePoint.Expect100Continue = false;
                request.ServicePoint.UseNagleAlgorithm = false;
                request.ServicePoint.ConnectionLimit = 2000
                request.AllowWriteStreamBuffering = false;
                request.Proxy = null;
    
                using (var stream = request.GetRequestStream())
                {
                    stream.Write(buffer, 0, buffer.Length);
                }
                using (response = (HttpWebResponse)request.GetResponse())
                {
                    string encoding = response.ContentEncoding;
                    using (var stream = response.GetResponseStream())
                    {
                        if (string.IsNullOrEmpty(encoding) || encoding.Length < 1)
                        {
                            encoding = "UTF-8"; //默認編碼
                        }
    
                        if (stream != null)
                        {
                            using (StreamReader reader = new StreamReader(stream, Encoding.GetEncoding(encoding)))
                            {
                                apiResult = reader.ReadToEnd();
                                //byte[] bty = stream.ReadBytes();
                                //apiResult = Encoding.UTF8.GetString(bty);
                            }
                        }
                        else
                        {
                            throw new Exception("響應流為null!");
                        }
                    }
                }
                isSuccess = true;
            }
            catch (Exception err)
            {
                isSuccess = false;
                LogUtilities.WriteException(err);
            }
            finally
            {
                response?.Close();
                request?.Abort();
            }
    
            return apiResult;
        }
    • 首先是TimeOut問題,不僅僅是在高併發場景下,實際項目中建議不管是任何場景都要設置它的值.在HttpWebRequest對象中,它的默認值是100000毫秒,也就是100秒.如果服務端出現問題,默認設置將會造成嚴重阻塞,對於普通項目也會嚴重影響用戶體驗.返回失敗讓用戶重試也比這樣長時間等待體驗要好.

    • ReadWriteTimeout很多朋友可能沒有接觸過這個屬性,尤其是使用.net 4.5里HttpClient對象的朋友.有過Socket編程經驗的朋友可能會知道,socket連接有連接超時時間和傳輸超時時間,這裏的ReadWriteTimeout類似於Socket編程里的傳輸超時時間.從字面意思上看,就是讀寫超時時間,防止數據量過大或者網絡問題導致流傳入很長時間都無法完成.當然在一般場景下大家可以完全不理會它,如果由於網絡原因造成讀寫超時也很有可能造成連接超時.這裏之所以設置這個值是由於實際業務場景決定的.大家可能已經看到,以上代碼對於ReadWriteTimeout的設置並不像Timeout一樣設置為一個固定值,而是放在了一個Const類中,它實際上是讀取一個配置,根據配置動態決定值的大小.實際中的場景是這樣的,由於壓測環境無法完全模擬真實的用戶訪問場景.壓測的時候都是使用單個單號進行軌跡查詢,但是實際業務中允許用戶一次請求查詢最多多達數百個單號.一個單號的軌跡記錄一般都是幾十KB大小,如果請求的單號數量過多數量量就會極大增加長,查詢時間和傳輸時間都會極大增加,為了保證雙11期間大多數用戶能正常訪問,必要時會把這個時間設置的很小(默認是3000毫秒),讓單次查詢量大的用戶快速失敗.

    以上只是一種備用方案,不得不承認,既然系統允許一次查詢多個單號,因此在用戶在沒有達到上限之前所有的請求都是合法的,也是應該予以支持的,因此以上做法實際上有損用戶體驗的,然而系統的資源是有限的,要必要的時候只能犧牲特殊用戶的利益,保證絕大多數用戶的利益.雙11已經渡過,實際中雙11也沒有改動以上配置的值,但是做為風險防範增加動態配置是必要的.

    這裏再多差一下嘴,就是關於ContentLength它的值是可以不設置的,不設置時程序會自動計算,但是設置的時候一定要設置字節數組的長度,而不是字符串的長度,因為包含中文時,根據編碼規則的不同,中文字符可能佔用兩個字節或者更長字節長度.

    • 關於 request.ServicePoint.Expect100Continue = false; request.ServicePoint.UseNagleAlgorithm = false;這兩項筆者也不是特別清楚,看了相關文檔也沒有特別明白,還請了解的朋友指點,大家共同學習進步.

    • request.ServicePoint.ConnectionLimit = 2000是設置最大的連接數,不少朋友是把這個數值設置為65536,實際上單台服務器web併發連接遠太不到這個數值.這裏根據項目的實際情況,設置為2000.以防止處理能力不足時,請求隊列過長.

    • request.AllowWriteStreamBuffering = false;根據[微軟文檔()]這個選項設置為true時,數據將緩衝到內存中,以便在重定向或身份驗證請求時可以重新發送數據.

    最為重要的是,文檔中說將 AllowWriteStreamBuffering 設置為 true 可能會在上傳大型數據集時導致性能問題,因為數據緩衝區可能會使用所有可用內存。由於發送的請求僅僅是單號,數據量很小,並且很少有用戶一個單號反覆查詢的需求.加上可能會有副作用.這裏設置為false.

    • request.Proxy = null;這裡是參考了一個一位網友的文章,裏面提到默認的Proxy導致超時怪異行為.由於解決問題是在10月份,據寫這篇文章已經有一段時間了,因此再尋找時便找不到這篇文章了.有興趣的朋友可以自己搜索一下.

    很多朋友可能會關心,通過以上配置到底有沒有解決問題.實際中以上配置后已經經歷了雙11峰值qps過萬的考驗.下面給出寫本文時候請求耗時的監控

    可以看到,整體上請求耗時比較平穩.

    可能看了這個圖,有些朋友還是會有疑問,通過上面日誌截圖可以看到,除了耗時在100ms以上的請求外,普通的耗時在四五十毫秒的還是有很多的,但是下面這個截圖裡都是在10到20區間浮動,最高的也就30ms.這其實是由於在壓測的過程中,發現Hbase本身也有不穩定的因素(大部分請求響應耗時都很平穩,但是偶爾會有個別請求婁千甚至數萬毫秒(在監控圖上表現為一個很突兀的線,一般習慣稱為毛刺),這在高併發場景下是不能接受的,問題反饋以後阿里雲對Hbase進行了優化,優化以後耗時也有所下降.)

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

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

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

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

  • this綁定方式總結

    最近在回顧js的一些基礎知識,把《你不知道的js》系列又看了一遍,this始終是重中之重,還是決定把this相關知識做一個系統的總結,也方便自己日後回顧。

    this的四條綁定規則

    1.默認綁定

    這是最常用的函數調用類型:獨立函數調用(即函數是直接使用不帶任何修飾的函數引用進行調用的)。可以把這條規則看作是無法應用其他規則時的默認規則。
    默認綁定的this在非嚴格模式下指向window,嚴格模式下指向undefined,比如下面的函數foo在非嚴格模式下:

    var a = 2;
    function foo(){
        var a = 3;
        console.log(this.a);
    }
    foo(); //2

    這裏的foo()方法內的this指向了window,因此window.a = 2;

    嚴格模式下,this.指向undefined,因此訪問this.a會報錯:

    var a = 2;
    function foo(){
        "use strict";
        var a = 3;
        console.log(this.a);
    }
    foo(); //Uncaught TypeError: Cannot read property 'a' of undefined

    2.隱式綁定

    如果調用位置上有上下文對象,或者說被某個對象“擁有”或者“包
    含”,則使用隱式綁定。

    function foo() {
        console.log( this.a );
    }
    var obj = {
        a: 2,
        foo: foo
    };
    obj.foo(); // 2

    上例中的foo是通過obj.foo()的方式調用的,調用位置會使用obj上下文來引用函數,因此foo中的this指向了obj。
    另外foo是當做引用被加入到obj中的,但是無論是直接在obj 中定義還是先定義再添加為引用屬性,foo嚴格上來說都不屬於obj,因此上述定義裏面的“擁有”與“包含”加上了引號,這樣說是為了方便理解。
    常見的隱式調用場景:
    obj.fn();
    arguments[i]();//其實就是將點的調用方式變為了[]調用
    el.onClick(function(){console.log(this);//this指向el})

    隱式丟失

    先來看一段代碼:

    function foo() {
        console.log( this.a );
    }
    var obj = {
        a: 2,
        foo: foo
    };
    var bar = obj.foo; // 函數別名!
    var a = "global"; // a 是全局對象的屬性
    bar(); // "global"

    上述代碼其實只用看調用的方式:bar(),這其實是一個不帶任何修飾的函數調用,因此應用了默認綁定。
    還有一種參數傳遞的方式也會發生隱式丟失,原理其實跟上述例子一樣:

    function foo() {
        console.log( this.a );
    }
    function doFoo(fn) {
        // fn 其實引用的是foo
        fn(); // <-- 調用位置!
    }
    var obj = {
        a: 2,
        foo: foo
    };
    var a = "global"; // a 是全局對象的屬性
    doFoo( obj.foo ); // "global"

    显示綁定

    使用call,apply和bind方法可以指定綁定函數的this的值,這種綁定方法叫显示綁定。

    function foo() {
        console.log( this.a );
    }
    var obj = {
        a:2
    };
    foo.call( obj ); // 2

    通過foo.call(obj),我們可以在調用foo 時強制把它的this 綁定到obj 上

    new綁定

    new操作符可以基於一個“構造函數”新創建一個對象實例,new的實例化過程如下:

    1. 創建(或者說構造)一個全新的對象。
    2. 這個新對象會被執行[[ 原型]] 連接。
    3. 這個新對象會綁定到函數調用的this。
    4. 如果函數沒有返回其他對象,那麼new 表達式中的函數調用會自動返回這個新對象。
      明確了new的實例化過程后,思考如下代碼:
    function foo(a) {
        this.a = a;
    }
    var bar = new foo(2);
    console.log( bar.a ); // 2

    new foo(2)后新創建了個實例對象bar,然後把這個新對象bar綁定到了foo函數中的this,因此執行this.a = a后其實是把a賦給了bar.a

    優先級

    一般情況下this的綁定會根據上述四條綁定規則來,那麼他們同時出現時,該以怎樣的順序來判斷this的指向?下面是具體的規則:

    1. 函數是否在new 中調用(new 綁定)?如果是的話this 綁定的是新創建的對象( var bar = new foo() )。
    2. 函數是否通過call、apply(顯式綁定)或者硬綁定調用?如果是的話,this 綁定的是指定的對象( var bar = foo.call(obj2) )。
    3. 函數是否在某個上下文對象中調用(隱式綁定)?如果是的話,this 綁定的是那個上下文對象。( var bar = obj1.foo() )
    4. 如果都不是的話,使用默認綁定。如果在嚴格模式下,就綁定到undefined,否則綁定到全局對象。( var bar = foo() )

    綁定例外

    1.使用call,appy,bind這種顯式綁定的方法,參數傳入null或者undefined作為上下文時,函數調用還是會使用默認綁定

    function foo() {
        console.log( this.a );
    }
    var a = 2;
    foo.call( null ); // 2

    什麼情況下需要將上下文傳為null呢?
    1.使用bind函數來實現柯里化

    function foo(a,b) {
        console.log(a,b);
    }
    // 使用 bind(..) 進行柯里化
    var bar = foo.bind( null, 2 );
    bar( 3 ); // 2,3

    2.使用apply(..) 來展開一個數組,併當作參數傳入一個函數

    function foo(a,b) {
        console.log(a,b);
    }
    // 把數組展開成參數
    foo.apply( null, [2, 3] ); // 2,3

    其實上面兩種使用場景其實都不關心call/app/bind第一個參數的值是什麼,只是想傳個佔位值而已。
    但是總是傳入null可能會出現一些難以追蹤的bug,比如說當你在使用的第三方庫中的某個函數中有this時,this會被錯誤的綁定到全局對象上,造成一些難以預料的後果(修改全局變量)

    var a = 1;//全局變量
    const Utils = {
        a: 2,
        changeA: function(a){
            this.a = a;
        }
    }
    Utils.changeA(3);
    Utils.a //3
    a //1
    Utils.changeA.call(null,4);
    Utils.a //3
    a //4,修改了全局變量a!

    更安全的做法:

    var o = Object.create(null);
    Utils.changeA.call(o,6);
    a //1, 全局變量沒有修改
    o.a // 6 改的是變量o

    2.間接引用

    function foo() {
        console.log( this.a );
    }
    var a = 2;
    var o = { a: 3, foo: foo };
    var p = { a: 4 };
    o.foo(); // 3
    (p.foo = o.foo)(); // 2

    賦值表達式p.foo = o.foo 的返回值是目標函數的引用,因此調用位置是foo() 而不是p.foo() 或者o.foo()。根據我們之前說過的,這裡會應用默認綁定。

    this詞法(箭頭函數)

    上述的幾種規則適用於所有的正常函數,但不包括ES6的箭頭函數。箭頭函數不使用this的四種標準規則,而是根據外層(函數或者全局)作用域(詞法作用域)來決定this

    function foo() {
    // 返回一個箭頭函數
        return (a) => {
            //this 繼承自foo()
            console.log( this.a );
        };
    }
    var obj1 = {
        a:2
    };
    var obj2 = {
        a:3
    };
    var bar = foo.call( obj1 );
    bar.call( obj2 ); // 2, 不是3 !

    foo() 內部創建的箭頭函數會捕獲調用時foo() 的this。由於foo() 的this 綁定到obj1,bar(引用箭頭函數)的this 也會綁定到obj1,箭頭函數的綁定無法被修改。(new 也不行!)

    幾個例子加深理解

    this的理論知識講解得差不多了,來幾個例子看看自己有沒有理解全面:
    1.經典面試題:以下輸出結果是什麼

    var length = 10;
    function fn() {
        console.log(this.length);
    }
    var obj = {
      length: 5,
      method: function(fn) {
        fn();
        arguments[0]();
      }
    };
    obj.method(fn, 1);

    obj中method方法裏面調用了兩次fn。第一次是直接調用的“裸露”的fn,因此fn()中this使用默認綁定,this.length為10.第二次調用時通過arguments的方式調用的,arguments[0]其實指向的就是fn,但是是通過obj[fn]這種對象上下文的隱式綁定的,因此this指向arguments,而arguments只有一個一項(method中只有fn一個參數),因此arguments.length為1。因此打印的結果為:

    10
    1

    2.以下輸出什麼

    var obj = {
        birth: 1990,
        getAge: function () {
            var b = this.birth; // 1990
            var fn = function () {
                return new Date().getFullYear() - this.birth; // this指向window或undefined
            };
            return fn();
        }
    };
    obj.getAge();

    答案是嚴格模式下會報錯,非嚴格模式下輸出NaN
    原因也是因為在調用obj.getAge()后,getAge方法內的this使用隱式綁定。但是return fn()的時候用的是“裸露的fn”使用默認綁定,fn裏面的this指向window或者undefined。
    使用箭頭函數來修正this的指向:

    var obj = {
        birth: 1990,
        getAge: function () {
            var b = this.birth; // 1990
            var fn = () => new Date().getFullYear() - this.birth; // this指向obj對象
            return fn();
        }
    };
    obj.getAge(); // 25

    使用箭頭函數后,fn中的this在他的詞法分析階段就已經確定好了(即fn定義的時候),跟調用位置無關。fn的this指向外層的作用域(即getAge中的this)
    3.以下輸出為什麼是’luo’

    var A = function( name ){ 
        this.name = name;
    };
    var B = function(){ 
        A.apply(this,arguments);
    };
    B.prototype.getName = function(){ 
        return this.name;
    };
    var b=new B('sven');  // B {name: "luo"}
    console.log( b.getName() ); // 輸出:  'luo'

    執行new B(‘seven’)後會返回一個新對象b,並且B函數中的this會綁定到新對象b上,B的函數體內執行A.apply(this.arguments)也就是執行b.name = name;這個時候b的值就是{name:’luo’},所以b.getName()就能輸出’luo’啦~

    實際在業務使用中,邏輯會更複雜一些,但是萬變不離其宗,都按照上面寫的規則來代入就好了

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

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

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

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

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

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

    【其他文章推薦】

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

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

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

  • 《軟件方法(上)》讀書筆記

    《軟件方法(上)》讀書筆記

    1、建模

    1.1、業務建模之願景

    重點1:通俗一點講,一個東西的願景就是:東西最應該賣個誰,對他有什麼好處?

    重點2:願景是需求排序的主要依據。

    重點3:老大、願景、需求都是基於現狀尋找最值得的改進。改進過後,又是新的現狀了,還是基於現狀尋找最值得的改進。進一步說也可以說,需求只有真假對錯,沒有變化。說需求有變化,那是從一個靜止時間點來看的。

    1.1.1、願景




    建模之願景

    1.2、業務建模之業務用例圖

    有了願景,我們知道老大對他所代表的組織的現狀的某些指標不滿意。接下來就可以研究組織,弄清楚到底是組織的哪些環節造成了這些指標比較差,這就是業務建模(Business modeling)的主要內容。

    重點1:軟件系統只是組織的一個零件。組織裏面還有很多系統,其中最值錢的是千百年來一直在使用,現在依然是最複雜的系統——人腦系統。

    重點2:開發團隊發現需求“容易變化”。根源之一是需求的來路不正,沒有把系統當作一個零件放在組織中來看,靠拍腦袋得出需求,導致得到的系統需求是錯的。

    1.2.1、業務角色

    ① 業務執行者

    以某組織為研究對象,在組織之外和組織交互的其他組織(人群或機構)就是該組織的執行者。以一家商業銀行為研究對象,觀察在它邊界之外和它打交道的人群或機構,可以看到儲戶來存錢,企業來貸款,人民銀行要它作監督等等,這些就是該商業銀行的執行者,如下圖所示:




    業務執行者(一)

    這裏要注意的是,作為觀察者的建模人員本身是一個人腦系統,所以在觀察組織邊界時,直覺上觀察到的不是組織之間的交互,而是組織派出的系統之間的交互,但是一定要把它理解成組織間的交互,因為談論業務執行者時,研究對象是組織,所以外部對應物——業務執行者也應該是組織。例如:以某國稅局為研究對象,可以觀察到企業財務人員到國稅局報稅,但業務執行者不是企業財務人員,而是企業。也許到後來,企業財務人員和國稅系統交互,又或許再後來是企業系統與國稅系統交互,從組織的抽象級別來看,都應該理解為企業和國稅局這兩個機構之間的交互,如下圖所示:




    業務執行者(二)

    ② 業務工人

    組織內的人稱為業務工人,例如某商業銀行裏面的營業員。業務工人是可以被替換的人腦零件,它可能被其他業務工人替換,但更有可能被業務實體替換。

    ③ 業務實體

    業務實體是組織中的非人智能系統,例如銀行的ATM、點鈔機、營業系統。

    1.2.2、識別業務用例

    重點1:業務用例指業務執行者希望通過和所研究組織交互獲得的價值。業務用例是組織的價值,不會因為某個人腦系統或電腦系統的存在或消失而改變,好比如300年前的商業銀行和當前的銀行的業務用例是不變的,因為銀行提供價值的本質沒有改變。所以“這個系統的業務用例是什麼”這樣的說法是錯誤的。

    重點1:用好用例,關鍵在於理解“價值”。價值是期望和承諾的平衡點、買賣的平衡點。例如以“醫院”為研究對象,真正的用例是“患者→看病”,而不是“患者→挂號”,患者→挂號”可以是以“挂號室”為研究對象的業務用例(如下圖)。所以做任何事情之前,要搞清楚“邊界”,沒有邊界會很容易盲目“拍腦袋”做一些努力但沒效果的事情。




    業務用例識別

    1.2.2.1、識別業務用例思路

    識別業務用例的思路有兩條:

    【從外到內】從業務執行者開始考慮,思考業務執行者和組織交互的目的(主要);

    【從內到外】通過觀察組織的內部活動,一直問為什麼,向外推導出組織外部的某個業務執行者(補漏)。




    業務用例識別思路

    1.2.2.1.1、識別業務用例常犯錯誤

    錯誤1 :把業務工人的行為當做業務用例。




    錯誤用例識別(1)

    錯誤2:業務用例隨待引入系統伸縮。




    錯誤用例識別(2)

    錯誤3:把害怕遺漏掉的擴展路徑片段提升為業務用例。




    錯誤用例識別(3)

    錯誤4:管理型業務用例。




    錯誤用例識別(4)

    總結:錯誤的根源主要源於:建模人員分不清問題和問題的解決方案。

    1.3、業務建模之業務序列圖

    1.3.1、描述業務流程的手段

    本章節主要討論的是業務建模中最繁重的工作——描述業務用例的實現,即業務流程,然後改進它,推導出待引入系統的用例。目前描述業務流程的可選擇手段有文本、活動圖和序列圖,它們的主要區別如下(以財務部“員工→報銷”用例的實現為樣例):

    ● 文本




    文本樣例

    文本的缺點是不夠生動,所以在描述業務流程時很少使用文本方式。不過,描述系統用例(即系統需求)的流程時,文本是常用的,因為此時更注重精確,而且還要表達業務規則、性能等目前尚未被UML標準覆蓋的內容。

    ● 活動圖




    活動圖樣例

    序列圖是UML圖形描述業務流程的兩種選擇之一。活動圖的前身是流程圖,應該是在建模人員中使用頻率最高的圖形,是隨机械工程領域慢慢引入到計算機領域。不過,隨着編程語言表達能力越來越強,針對簡單的分支或循環邏輯畫圖在很多情況下已經變得沒有必要。

    ● 序列圖




    序列圖樣例

    序列圖與活動圖的比較如下:

    1)活動圖只關注人,序列圖把人當作系統;

    在上一章節中已經提到,現在的業務流程中已經有很多領域邏輯是封裝在業務實體而不是業務工人中,如果忽略非人智能系統,很多重要信息就丟掉了。

    2)活動圖表示動作,序列圖強迫思考動作背後的目的;

    序列圖可以更加清晰地表述業務工人或業務實體對外的責任,也就是用例的期望值。期望和承諾是用例和對象技術的關鍵思想,使用序列圖來做業務建模,“對象協作以完成用例”的思想就可以統一地慣竊業務建模和系統建模的始終。

    3)活動圖“靈活”,序列圖“不靈活”;

    不少人認為活動圖勝過序列圖的地方是它靈活,但這靈活是一把雙刃劍。活動圖很靈活,他的控制箭頭可以指向任何地方,就像編碼原始時代的“goto”語句,所以活動圖很容易畫。不過,“很容易畫”的活動圖也比較容易掩蓋建模人員對業務流程認識不足或者業務流程本身存在缺陷的事實。序列圖可通過alt、loop等結構化控製片段來描述業務流程,強迫建模人員用這種方式思考。

    1.3.2、業務序列圖要點

    1.3.2.1、消息代表責任分配而不是數據流動

    序列圖中最重要的要點是消息的含義。A指向B的消息,代表“A請求B做某事”,或者“A調用B做某事的服務”,而“做某事”是B的一個責任。




    序列圖消息含義

    1.3.2.2、抽象級別是系統之間的協作

    業務建模的研究對象是組織,出現在業務序列圖生命線上的對象,其最小顆粒是系統,包括人和非人系統,而系統之間最主要突出的是協作。所以“系統粒度”和“協作”是業務序列圖的關鍵要點,如果記住了這兩個關鍵點,就可以避免了對組織對象抽象的錯誤以及對協作理解的錯誤。




    系統內部的組件暴露



    表達了過細的交互步驟

    以上說的兩種錯誤是把需求和分析的工作流的工作帶入了業務建模。第一樣例圖提到的系統內部的組件,應該在分析和設計工作流中描述;第二樣例圖提到了交互步驟,應該在需求工作流中描述。除了以上兩種抽象級別的錯誤,還有一種是:業務序列圖的內容和業務用例圖差不多,如下所示:




    目標組織作為整體出現在業務序列圖中  

    1.3.2.3、把時間看作特殊的業務實體

    業務序列圖中,我們把時間看作特殊的業務實體。把時間看作上帝造好掛在天上的一個大鐘,向全世界各種系統發送時間消息,這樣,就和後面需要工作流中映射系統用例的時間執行者一致了,同時也幫助理清什麼情況下使用時間執行者的問題。




    把時間當作一個系統

    值得注意的一點是,時間和定時器不是一個概念,時間是“外系統”,定時器是其他系統用來和時間打交道的“邊界類”。世界上只有一個時間系統,但有無數的定時器。如果建模人員在識別系統用例時說“執行者是定時器”,那就錯了,執行者是時間。




    時間和定時器的區別

    1.3.2.4、為業務對象分配合適的責任

    分配給業務對象的責任必須是該對象有能力承擔的,這需要我們自身必須對理解要十分清晰,畢竟我們自己說話有時候的會含糊。例如“工作人員用Word寫標書”這樣的說法好像可以接受,但如果按照說話的文字不假思索地隨便畫,會很容易導致對象責任分配不準確。




    不恰當與不恰當的責任分配對比

    1.3.3、現狀業務序列圖

    業務序列圖描述的是業務流程,建模需要通過在現狀的業務序列圖基礎上找出改進的要點。如果要把現狀序列圖畫出來,就必須讓自己站在客觀的角度“親臨現場”,“如實”地把所看到的記錄下來,儘力描繪出真實的現狀。但說起來非常簡單,做到卻極其困難。總結到這裏,忽然讓我想起了彼得·德魯克。下面列出一些描述現狀時經常犯的錯誤。

    1)錯誤:把想象中的改進當成現狀

    很多時候造成這種錯誤,背後的原因很可能是根本沒有深入到組織流程中去做觀察和訪談,對現狀沒有認識,只好想像一個改進后的場景來應付。

    2)錯誤:把“現狀”誤解為“純手工”

    有的建模人員以為人做的事情才是本質,所以他畫的業務流程中,只有人,沒有非人系統,完全忽略了在技術進步下慢慢可以替代人的這些“業務實體”。

    3)錯誤:把“現狀”誤解為“本開發團隊未參与之前”

    開發團隊很容易會誤以為當他們開始參与組織流程完善而開發系統的時候當作“現狀”,這就是典型的“技術思維”,很多時候在開發團隊在參与組織流程完善前,組織已經經過了許多次“非系統級”的流程改進,這是站在組織角度去看問題的。

    4)錯誤:把“現狀”誤解為“規範”

    建模人員在建模業務流程時,照搬組織制定的規範,沒有去觀察實際工作中人們是如何做的,或者即使觀察到了人們實際沒有按照規範做,卻依然按照規範建模。這樣做,得到的業務流程是不真實的,畢竟上有政策,下有對策。

    5)錯誤:“我是創新,沒有現狀”

    互聯網創業公司的建模人員很容易犯的這個錯誤,動不動就說“我做的是互聯網創新,沒有現狀”,但他們已經忘記了歷史上所有的創新都是站在前輩這些巨人的肩膀之上這個事實。

    6)錯誤:“我做產品,沒有現狀”

    非定製系統的開發團隊進程拿這句話做接口。A公司的流程和B公司的流程有差異,中國的流程和外國的流程有差異,畫誰的現狀好的?問這個問題的時候,我想是開始開發團隊忘記了“做需求時把產品當項目做”的道理,在第2章節中也提到過“誰比誰更像”的重點。

    1.3.4、改進業務序列圖

    上面提到的現狀業務序列圖是對組織現狀的客觀描述,而改進業務序列圖是通過信息化手段去思考對業務現狀序列圖的一些改進。通常,信息化給人類的工作和生活帶來的改進有三種模式。

    1.3.4.1、改進模式一:物流變成信息流

    和信息的光電運輸比起來,用其他手段運輸的物的流轉速度就顯得太慢了,而且運輸成本會隨着距離的增加而明顯增加。如果同類物的不同實例之間可以相互取代,那麼可以提煉物中包含的部分或全部有價值的信息,在需要發生物流的地方,改為通過軟件系統交互信息,需要物的時候再將信息變成物,這樣就可以大大增加流轉速度和降低流轉成本。




    物流變成信息流改進

    1.3.4.2、改進模式二:改善信息流轉

    軟件系統越來越多,而各個軟件系統之間溝通不暢,導致一個人為了達到某個目的可能需要和多個軟件系統打交道,如果把各軟件系統之間的協調工作改為一個軟件系統來完成,人只需要和單個軟件系統打交道,信息的流轉就改進了。




    改善信息流轉

    1.3.4.3、改進模式三:封裝領域邏輯

    在業務流程中,有很多步驟是由人腦來判斷和計算的,領域邏輯封裝在人腦中。相對於計算機,人腦(業務人才)存在成本高,狀態不穩定、會徇私舞弊等問題。如果能夠提煉人腦中封裝的領域邏輯,改為封裝到軟件系統中,用軟件系統代替人腦,業務流程就得到了改進。換句話說,領域邏輯的封裝是對系統“內在”價值的提升,相對於前兩個改進模式有更高的要求和更大的困難。




    封裝領域邏輯改進

    1.3.4.4、改進思考方式:阿布爾思考法

    在軟件開發團隊中,當有人提出新的想法時,經常會被馬上否定“太難了,做不了”,最終得到一個平庸的、毫無競爭力的系統。學會像阿布(俄羅斯大富豪羅曼·阿布拉莫維奇)一樣思考,有助於克服普通人因資源受限而不敢展開想象的思維障礙。阿布思考法分兩步:

    1)假設有充足的資源去解決問題,得到一個完美的方案;

    2)用手上現有的資源去山寨這個完美的方案。

    其實,阿布思考法的核心思想就是,不要閉門造車,要“接地氣”的行動起來,主動去觀察,或主動尋找有用的信息去分析和調研,不要被各種局限被迫讓步。

    2、需求

    2.1、需求之系統用例圖

    在“建模”階段我們研究和思考的對象是組織,從組織的整體性客觀地去發現組織如何可以通過信息化手段去優化流程。有了客觀的整體性分析和改進認知,接下來的“需求”階段需要深入到系統層面去思考了。按正常邏輯,每一步都有“承上啟下”的作用,本章節所研究的系統用例就是通過上一步業務序列圖中所映射出來的。

    執行者和用例的概念在業務建模的學習中已經出現過,現在要研究的執行者和用例與業務建模時研究的執行者和用例相比,不同之處是研究對象,之前研究的是組織,現在研究的是系統。

    2.1.1、系統執行者要點

    系統執行者的定義:在所研究系統外,與該系統發生功能性交互的其他系統。

    2.1.1.1、系統是能獨立對外提供服務的整體

    封裝了自身的數據和行為,能獨立對外提供服務的東西才能稱為系統。不了解這點,建模人員很容易把“添加一些功能”當作“研發新系統”。




    劃分系統用例

    2.1.1.2、系統邊界是責任的邊界

    系統執行者不是所研究系統的一部分,是該系統邊界外的另一個系統。這裏的系統邊界不是物理的邊界,而是責任的邊界。




    錯誤的遙控軟件用例圖    



    正確的遙控軟件用例圖

     

    2.1.1.3、系統執行者和系統有交互

    外系統必須和系統有交互,否則不能算是系統的執行者。如一名旅客來到火車站售票窗口,告訴售票員目的地和車次,售票員使用售票系統幫助旅客購買火車票,這個場景中,和火車票系統交互的是售票員,他是售票系統的執行者。




    旅客不是售票系統的執行者

    如果火車售票系統現在已經提供了旅客自行購票的接口,例如互聯網購票、售票機等,這種情況下,旅客也是售票系統的執行者。不過“售票員→售票”和“旅客→購票”是兩個不同的用例。

    2.1.1.4、交互是功能性交互

    上面說的交互還引出一個問題:假設售票員使用鼠標和售票系統交互,按道理,比起銷售員,鼠標里售票系統更近,為什麼不把鼠標作為售票系統的執行者呢?還有,假設售票系統運行在Windows操作系統之上,那麼Windows是不是售票系統的執行者?其實吧,辨別這些問題的要點就是:執行者和系統發生的交互是系統的功能需求。鼠標和操作系統跟售票系統的交互都不是售票系統的核心域概念。售票員和售票系統之間的交互才是,所以售票員才是售票系統的執行者。




    售票系統的功能需求

    2.1.1.5、系統執行者可以是人或非人系統

    系統執行者可以是一個人腦系統,也可以是一個非人智能系統,甚至是一個特別的系統——時間。在軟件業的早期,一個系統的執行者往往全部都是人。隨着時間的推移,系統的執行者中非人執行者所佔的比例越來越多。用例的優勢在於“執行者”和“涉眾”的概念,把演員和觀眾分開。演員(執行者)在台上表演,觀眾(涉眾)在台下看,演員表演什麼是由觀眾的口味決定的,演員可以不是人,但觀眾肯定是人。演員如果是人類,那麼在觀眾席上也會有一個位置,不過在第幾排就不知道了(權重等級)。用例使用“執行者”和“涉眾”代替了原來的“用戶”是一個非常大的突破,建模人員如果過多地關注“用戶”,混淆了真正真正重要的前排“涉眾”的需求,把操作人員當前重要的調研對象(非關鍵人員),那麼花在重要的前排涉眾(關鍵人)身上的時間可能就不夠了。越來越多的系統執行者不是人類,也就是說沒有“用戶”。




    從“執行者都是人”到“執行者有一些是人”

     

    2.1.1、識別系統執行者

    2.1.2.1、從業務序列圖映射系統執行者

    如果沒有做業務建模,識別系統執行者只能靠頭腦風暴。例如:什麼人會使用系統來工作?什麼人負責維護系統?系統需要和哪些其他智能系統交互?有沒有定時引發的事件?等等問題。有了業務建模,可以直接從業務序列圖映射即可。業務序列圖上,和所研究系統有實線相連的對象映射為所研究系統的執行者。




    業務序列圖:需找租客線索  



    從業務序列圖映射得到系統執行者

     

    2.1.3、系統用例要點

    2.1.3.1、價值的買賣的平衡點

    系統用例的定義:系統能夠為執行者提供的、涉眾可以接受的價值。和業務用例相比,研究對象從組織變成了系統,要理解好系統用例,重點依然是之前所強調的買賣平衡點、期望和承諾平衡點。

    用例之前的許多需求方法學,把需求定義為思考系統“做什麼”,用例把需求提升到思考系統“賣什麼”的高度。這種思考是非常艱難的,因為它沒有標準答案,只有最佳答案。要得到這個答案,不能靠拍腦袋,必須揣摩涉眾。要得到合適的用例,需要有一顆善於提擦他人的心。




    ATM和程序員人腦系統的用例

    2.1.3.2、價值不等於可以這樣做

    有些人會較真,還是以ATM為例子,有些人會因為“難道ATM放在那裡我就不能登錄一下就離開嗎?我今晚下班就去ATM那裡登錄一下給你看,然後走人。”ATM確實能登錄,但登錄功能並非ATM的賣點,如果以一個“門禁系統”為研究對象,登錄就可以作為它的用例。

    還有一種情況,例如科員可以有A和B用例,科長因為比科員的權力大,所以就能擁有科員的用例。用例的執行者只是表明這個用例是為這一類執行者而做的。但不代表系統一定要有權限控制以防止其他的人或電腦系統使用該用例。即時系統確實需要有權限控制,而且角色的劃分和執行者相近,也要把這兩者分開,更不可以因為系統不設權限控制,所以把執行者的名字合併為“用戶”。




    用例劃分案例

    有些書中會給出“最佳粒度原則”。例如:一個系統的用例最好控制在XXX個之內,一個用例的基本路徑最好控制在X步到X步之間……這些是沒有根據的。市場需要各種各樣的系統,有功能眾多的,也有功能單一的,也有交付複雜的,應該把屁股坐到涉眾那邊去,揣摩涉眾的心裏,實事求是地寫下來。如果建模人員在粒度問題上激烈爭吵以及糾纏不清,有可能已經犯了錯誤,最常犯的錯誤是把步驟當作用例。




    錯誤:把步驟當作用例

    2.1.3.3、增刪改查用例的根源是從設計映射需求

    有一些用例圖,映入眼帘的用例是四個四個一組的,仔細一看,剛好對應看數據庫的四種操作。相當於把數據庫的各個表名加上新增、刪除、修改、查詢,就得到了用例的名字。有些建模人員確實也知道這個錯誤,但他們學乖了,乾脆把每四個用例合併,改名叫“管理XX”或(“XX管理”),然後新增、刪除、修改、查詢等用例再擴展它,可惜依然是換湯不換藥。




    從數據庫視角得到的用例

     

    2.1.3.4、從設計映射需求錯誤二:“復用”用例

    增刪改查用例實際上就是從設計映射需求,導致“復用”用例的一種情況。在看看以下例子:




    “復用”用例錯誤示例——缺陷管理系統

    從不同的業務序列圖分別映射得到系統有右邊四個用例,但有的建模人員會動起心思:這些實現起來不都是針對“缺陷”表來“select X X X from缺陷表where X X X”嗎,合併成一個用例“查詢缺陷”多好!於是得到左邊的結果。實際上,右邊這四個用例面對的執行者不同,背後的涉眾利益也有差別。

    當然,如果真的像這位建模人員講的,把“數據庫”,買回去就好,想怎麼折騰這信息都可以那不是更加簡單。其實,用例是涉眾願意“購買”的、對系統的一種“用法”,只要涉眾願意“購買”,當然越多越好。講到這裏,就要來說一個需求的基本要點:需求不考慮“復用”,如果考慮“復用”,要警惕自己是不是已經轉換到了設計視角來思考問題。

    2.1.3.5、系統用例不存在層次問題

    系統用例的研究對象就是某特定系統,不是組織,也不是系統內部的組件。如果存在“層次”上的疑惑,背後的原因是研究對象不知不覺改變了。

    像醫院信息系統的用例,有人會畫成如下圖所示,原因可能是前面沒有畫業務用例圖和業務序列圖,所以建模人員頭腦里不知不覺把醫院信息系統的價值和醫院的價值混在一起了。




    錯誤的“高層”用例:混淆組織的價值和系統的價值

    還有以下的防汛系統用例圖,把系統的願景當成了“高層”用例:




    錯誤的“高層”用例:把願景當作用例

    以下更為常見的錯誤,為系統的“模塊”或“子系統”畫用例圖:




    錯誤:模塊的用例  



    用例仍然是系統的用例    



    錯誤:子系統的用例

    2.1.3.6、用例的命名是動賓結構

    用例的命名是動賓結構,例如“取現金”。動詞前面可以加狀語,賓語前面可以加定語,把一句話的主語砍掉,剩下的可以用作用例的名字。

    給用例起名時不要使用弱動詞。用例之前的需求技術,可能是以“名詞+動詞”的形式命名系統的功能,例如“發票作廢”,後來要改成用例的動賓結構了,有的建模人員就在前面加一個弱動詞“進行”,就變成了“進行發票作廢”,這個也是不合適的。

    如果“名詞+動詞”已經成為行業中的一個術語,也未必要嚴格的動賓結構,例如“成果分析”是某行業的一個術語,也就不必硬要倒過來變成“分析成果”了。

    2.1.4、識別系統用例

    2.1.4.1、從業務序列圖映射系統用例

    其實,只要認真做好業務建模,從業務序列圖上映射系統用例,得到的結果自然就會符合上面說的這些要點。

    從業務序列圖中,從外部指向所研究系統的消息,可以映射為該系統的用例。現在我們繼續從“識別系統執行者”的用例中結合執行者和系統用例一起識別。




    從業務序列圖上找到從外部指向所研究系統的信息    



    從業務序列圖映射得到系統用例

     

    在以上業務序列圖中,有一處消息是“外呼人員”指向“線索管理系統”的消息為“提供本人當天名單”,但在以上系統用例圖中,用例名改為了“查看本人當天名單”。因為序列圖上的消息代表“請求某系統做某事”,用例代表“用某系統來做某事”,一定要理解兩種圖的要點,所以有的地方需要調整。

    在以上系統用例圖中,有的箭頭是從執行者指向用例,這樣的執行者稱為用例的主執行者,有的箭頭是從用例指向執行者,這樣的執行者稱為用例的輔執行者。主執行者主動發起用例的交互,輔執行者在交互的過程中被動參与進來。

    值得注意一下,輔執行者這個概念是被誤用的比較多。最常見的錯誤是把信息的接收者或者將來可能使用信息的人當成輔執行者。另一種輔執行者的誤用剛好相反,把信息的來源當作輔執行者。




    錯誤:把可能會用到所生產信息的人當作輔執行者  



    錯誤:把提供用例所需要信息的人當作輔執行者

    以上錯誤的原因很多是因為前面沒有畫業務序列圖,導致建模人員在畫系統用例圖的時候產生焦慮,總是希望在圖上多放一些信息,以免自己忘記了。一般來說,輔執行者是非人智能系統的情況較多,人腦系統作為輔執行者的情況比較少,所以碰到輔執行者是人的時候,要多留心。




    正確:合適的輔執行者(因為辦卡需要用戶輸入密碼)

     

    2.2、需求之系統用例規約

    用例圖表達了用例的目標,但是對於完整的需求來說,這是遠遠不夠的。用例的背後封裝了不同級別的相關需求,我們需要通過書寫用例規約把這些需求表達出來。用例規約就是以用例為核心來組織需求內容的需求規約。用例規約的各項內容可以通過以下類圖來展示:




    用例規約的內容

    2.2.1、前置條件和後置條件

    用例通過前置條件(precondition)、後置條件(postcondition)以契約的形式表達需求。用例相當於系統的一個承諾:在滿足前置條件時開始,按照裏面的路徑步驟走,系統就能達到後置條件。為了避免掉入“從實現角度看這樣可以那樣也可以”的陷阱,後置條件只需要寫出最想要的那個狀態即可。

    ● 前置條件:用例開始前,系統需要滿足的約束。

    ● 後置條件:用例成功結束后,系統需要滿足的約束。

    2.2.1.1、前置條件、後置條件必須是系統能檢測的




    系統必須能檢測前置、後置條件

    以上圖為例,“錄入保單”用例的前置條件是錯誤的。業務代表是否已經把保單交給內勤,系統無法檢測,不能作為前置條件;同樣,“收銀”用例的後置條件也是不對的。顧客是否已經帶着貨物離開商店,系統也無法檢測,不能作為後置條件。

    2.2.1.2、前置條件必須是用例開始前系統能檢測的




    前置條件必須是用例開始前系統能檢測的

     以上圖所示,儲戶開始取現金的交互前,系統不知道儲戶是誰,要去多少錢,所以無法檢測“儲戶賬戶里有足夠的金額”這個條件。如果把前置條件設置為類似於“存在大於最低限額的現金”這樣的背景條件作為前提條件是可以的。就算很長時間沒人來ATM取現金,這個條件是否成立就擺在那裡。

    2.2.1.3、前置後置條件是狀態,不是動作

    例如,“經理→批假”的前置條件不能寫“員工提交請假單”,因為是一個動作不是狀態,應改為“存在待審批的請假單”。特別要注意的是,寫成“員工已經提交請假單”很可能也是不對的,因為狀態和導致達到某個狀態的行為不是一一對應的,請假單未必是員工自己提交的,也可以組長負責幫本組人員請假,也可能是從另外的系統批量導入。

    如果分不清狀態和行為的區別,建模就會遇到很大的麻煩。後面的建模工作中,還會不斷討論狀態和行為的問題。

    2.2.1.4、前置後置條件要用核心域詞彙描述

    “系統正常運行”、“網絡連接正常”等放之四海而皆準的約束,和所研究系統沒有特定關係,不需要在前置條件中寫出來,否則會得到一堆沒有任何增值作用的廢話。

    後置條件也不能簡單地把用例的名字加上“成功”二字變成“XXX成功”。例如“顧客→下單”的後置條件寫成“顧客已經成功下單”,這不是廢話嗎?更合適的後置條件是“訂單信息已保存”。

    2.2.1.5、“已登錄”不應作為前置條件

    “已登錄”是一個比較有爭議的情況,以購物網站為研究對象,登錄不是用例。這一點已經在前面的已經學習過,那如何處理登錄?

    1)畫法一:把其他用例作為“登錄”的擴展




    畫法一:把其他用例作為“登錄”的擴展

     

    會員登錄后可以下單,也可以查看以往訂單,還可以退貨……所以上圖這個方法把下單、查看以往訂單畫出登錄的擴展。這是錯的。並不是先做A然後做B或C,B和C就成了A的擴展。

    2)畫法二:把“登錄”作為被包含用例




    畫法二:把“登錄”作為被包含用例

    把“登錄”變成被其他用例包含(Include)的被包含用例(Include Use Case)。這樣做是正確的。登錄用例本來不存在,後來在寫用例規約的時候,發現“下單”、“查看以往訂單”等用例都有以下步驟:




    “查看以往訂單”步驟

    為了節省書寫用例規約的工作量,考慮把這些形成一個小目標的步驟集合(不是單個步驟)分離出來,作為一個被包含用例單獨編寫規約。這個用例只被其他用例包含,不由主執行者指向。所以,如果按照這個做法的話,“下單”用例規約的步驟里,應該有表示包含“登錄”用例的步驟集合:會員【登錄】。這裏的“登錄”二字加了粗括號表示這是一個被包含用例。它的步驟和約束在另外的地方描述。當然,不喜歡用粗括號可以用下劃線等其他方法以示區分。

    3)畫法三:其他用例以“已登錄”作為前置條件




    畫法三:其他用例以“已登錄”作為前置條件

    有些人覺得畫法二會讓好些用例會出現會員【登錄】,看起來有些礙眼,就想能不能把它提到前置條件里,那就得到了畫法三。把“登錄”作為一個用例,“會員已經登錄”作為其他用例的前置條件。這樣用例的步驟看起來更清爽,但是嚴格來說這也是不對的,“登錄”不能作為購物網站的用例。

    以上章節學習過,如果在做需求時考慮復用,可能已經陷入了設計的思維。能夠在多個用例中復用登錄的狀態,這是設計人員的本事,他甚至可以做到10個用例的界面都從一個模板生成,但不能因此就把這10個用例合併成一個。

    2.2.2、涉眾利益

    前提條件是起點,後置條件是終點,中間的路該怎麼走?這就要由涉眾決定了。也就是我們需要對關鍵人按重要程度排序(從前排到後排)去考慮他們的利益,根據這些利益去梳理正確的需求。以銀行ATM為例子,儲戶在ATM取現金的時,涉及的涉眾利益如如下:

    ● 儲戶:希望方便;擔心權益受損。

    ● 銀行負責人:希望安全;希望節約運營成本。

    正是這些涉眾利益的交鋒之下,目前我們日常生活中所看到的ATM的用例片段如下:




    ATM用例片段

    從步驟1有設計約束“通過磁條卡或芯片卡提交賬戶號碼”看,這是為了照顧儲戶“方便”的利益。在銀行角度,雖然儲戶是上帝,為了儲戶更加方便,不用密碼更方便的。但從銀行角度要考慮安全問題,不可能不設置密碼,但為什麼只設置6位而不是8位或者更多呢?這又是“安全”和“方便”交鋒后的妥協……

    2.2.2.1、涉眾的來源

    1)涉眾來源一:人類執行者

    用例的執行者如果是人類,當然是用例的涉眾。執行者如果不是人類,就不是涉眾,因為它沒有利益主張。




    考慮人類執行者之後的涉眾

    上圖保險系統的“內勤→錄入保單”用例中,內勤是人類,是涉眾,而OA系統不是人類,不是涉眾。

    2)涉眾來源二:上游

    執行者要使用系統做某個用例,可能會需要一些資源,這些資源的提供者可能就是用例的涉眾。還是以“內勤→錄入保單”為例,保單由業務人員代表提供給內勤。如果內勤喝醉了酒亂錄,信息錯得一塌糊塗,業務代表的利益就被損害了。所以,考慮到上游之後,“內勤→錄入保單”用例的涉眾有內勤和業務代表了。




    考慮上游之後的涉眾

    3)涉眾來源三:下游

    執行者使用系統做某個用例,產生的後果會影響到其他人。這些受影響的人也是涉眾。還是以“內勤→錄入保單”為例,如果系統做得不好,沒有檢測內勤錄保單時是否填了必填項就放了過去,後面負責審核的經理工作量增加了。還有,OA系統雖然不是該用例的涉眾,但假如保險系統不停地向OA系統發送垃圾數據包,導致OA癱瘓,那麼OA系統維護人員的工作量就增加了。所以,OA系統維護人員也是下游的涉眾。考慮下游之後,“內勤→錄入保單”用例的涉眾如下圖所示:




    考慮下游之後的涉眾

     

    4)涉眾來源四:信息的主人

    用例會用到一些信息,這些信息會涉及某些人,雖然這些人也許並不知道這個系統的存在,但他們是用例的涉眾。還是以“內勤→錄入保單”為例,保單的信息涉及被保人,投保人和受益人,如果信息出錯或泄露,這些人就會遭殃,所以他們是涉眾。因為這類涉眾可能和系統沒什麼接口,比較容易被忽略,所以要特別需要注意。




    考慮信息的主人之後的涉眾

    其實,前面的業務建模對識別涉眾起到了非常大的幫助,如果做需求前做了業務建模,會更加了解一件事情的前因後果,大多數涉眾都能夠從業務序列圖中看出來。如下圖所示:




    業務建模可以幫助尋找涉眾

     

    2.2.2.2、尋找涉眾利益

    查理·芒格說過:說服別人要訴諸利益,而非訴諸理性。所以要學會思考涉眾的利益點是一門非常大的學問。尋找涉眾利益時,要“親兄弟,明算賬”,把不同涉眾各自關注的利益體現出來,而不是寫成一模一樣的。家裡兩夫妻對同一件事情都還有不同立場,更不用說一個組織裏面形形色色的涉眾了。例如,司機開車進廠裝化肥,工作人員通過地磅系統操縱地磅給車稱重。針對這件事,不同的涉眾可謂是“各懷鬼胎”:

    ● 化肥公司老闆——擔心公司內部人員貪污;

    ● 地磅操作員——希望操作簡便;擔心承擔責任;擔心繫統壞掉影響工作量;

    ● 倉管人員——擔心稱不準導致無謂的返工裝包;

    ● 買主——擔心進去時稱得輕了,出來時稱得重了,導致給少了化肥;

    ● 司機——擔心等候時間太長導致每天拉貨次數減少;

    即使有些利益有時不方便白紙黑字寫出來共享,但至少建模人員要心知肚明,不能一團和氣了事。建模人員要仔細觀察和揣摩涉眾的痛苦,才能找到真正的涉眾利益,否則寫出來的“涉眾利益”往往很蒼白。例如以下例子:

    ● 護士——擔心出錯

    這都是正確的無用廢話,誰都擔心出錯,但為什麼還是出錯?仔細調研過之後寫出來就生動多了:

    ● 護士——擔心自己的藥理學知識記錯,對藥物名稱相近的藥物計算錯劑量,導致給葯錯誤;

    2.2.2.3、善於積累涉眾利益

    需求是不斷變化的,我想這都是共識了,新系統肯定在功能或性能上和舊系統有所不同,否則還做什麼新系統呢。但是,背後的涉眾利益要穩定得多。看看之前ATM的例子出現的涉眾利益:

    儲戶——希望方便;擔心權益受損;

    銀行負責人——希望安全;希望節約運營成本;

    其實這些涉眾利益不止適用於ATM,也適用於清朝的錢莊櫃檯、現在的銀行櫃檯、網上銀行和手機銀行。換句話說,越本質越穩定。

    2.2.3、基本路徑

    一個用例會有多個場景,其中有一個場景描述了最成功的情況,執行者和系統的交互非常順利,一路綠燈直抵用例的後置條件。這個場景稱為基本路徑。用例把基本路徑分離出來,目的是凸顯用例的核心價值。還是以ATM為例,發生在ATM上的場景有很多:

    1)張三來了,插卡,輸入密碼,輸入金額,順順利利取到錢,高興地走了;

    2李四來了,插卡,輸密碼,密碼錯,在輸,再錯,再輸,卡被吞掉了;

    3王五來了,插卡,輸密碼,輸金額,今天取得太多不能取了……

    以上三個場景,只有場景(1)是銀行在大街上擺放一台ATM的初衷。雖然場景(2)和(3)是難以避免,但場景(1)出現得越多越好,這是涉眾對ATM的期望。

    書寫路徑步驟的時候需要注意以下一些要點。這些要點有重疊的地方,如果違反了其中一個要點,很可能會違反另外的要點。

    2.2.3.1、按照交互四步曲書寫

    執行者和系統按回合交互,直到達成目的。需要的回合數是不定的,可能一個回合足夠,也可能需要多個回合。一個回合中的步驟分為四類:請求、驗證、改變、回應。如下圖所示:




    交互四步曲

    在一個回合中,請求是必須的,同時還需要其他三類步驟中的至少一類。看看以下例子,可以看到,第一個回合只需要請求和響應,第二個回合則四類步驟都有。




    回合制的交互示例

    當時間作為主執行者而且不需要和其他輔執行者交互的用例中,可能會出現不需要回應的情況,而且只有一個回合,如下所示:




    回合制的交互示例

    在書寫步驟時要注意以下一些形式上的問題:

    1)對於時間為主執行者的用例,回合中的請求步驟不寫“時間告知時間周期到了”,而是寫“當到達時間周期時”。

    2)驗證步驟不寫“是否”。例如以上例子中,第4步寫“系統驗證註冊信息充分”,不寫“系統驗證註冊信息是否充分”,目的是要表達“充分”是基本路徑期望的驗證結果。

    3)系統和輔執行者之間的交互可以看作是一種回應步驟,寫成“系統請求輔助執行者做某事”,例如“系統請求郵件列表系統群發郵件”。

    2.2.3.2、只寫系統能感知和承諾的內容

    看看以下例子:

    ……

    4、系統反饋應收總金額

    5、顧客付款

    6、收銀員提交付款方式和金額

    7、系統計算找零金額

    8、系統反饋找零金額,打印收據

    9、收銀員找零

    ……

    顧客付款和收銀員找零是系統無法感知和承諾的。如果寫在步驟里,會讓人產生誤解:只要用了本系統,顧客就會乖乖付款,收銀員會乖乖找零——也許顧客忘記付款和收銀員忘記找零正式商場要解決的一個頭痛問題。

    2.2.3.3、使用主動語句理清責任

    把動作的責任人放在主語的位置,看看以下兩句話:

    1)伊布從瓦倫西亞處得到傳球,舒梅切爾撲救伊布的射門。

    2瓦倫西亞傳球,伊布射門,舒梅切爾撲救。

    雖然上面一句比較文藝,但下面一句把責任理得更清晰。用例步驟也是如此:

    系統從會員處獲得用戶名和密碼(錯)

    會員提交用戶名和密碼(對)

    用戶名和密碼被驗證(錯)

    系統驗證用戶名和密碼(對)

    會員要是不提交,就不要怪系統沒有動靜;會員要是提交了,系統不動彈,那就要怪系統了。做到規規矩矩說話,把責任理清楚,其實不容易。再列舉一些常見的“胡說八道”,如下所示:




    規矩用詞

    2.2.3.4、主語只能是主執行者或系統

    寫需求,就是要把系統當作一個黑箱,描述它對外提供的功能以及功能附帶的質量需求。系統如何構造,不屬於需求描述的範圍,除非是涉眾強加的設計約束。所以步驟里不能出現“執行者請求前端系統做某事,前端系統請求後端系統做某事”“執行者請求客戶端做某事,客戶端請求服務端做某事”“執行者請求A子系統做某事,A子系統請求B子系統做某事”,就算這個系統最終的組成是分解成很多個部分,分佈在一百多個國家運行,需求里也只有兩個字:系統。前面已經學習過了,系統邊界是責任邊界,而非物理邊界,如下所示:




    需求把系統看作是黑箱

     

    2.2.3.5、使用核心域術語描述

    路徑步驟應該使用核心域的術語來描述,也就是說,要說“人話”。以下以一個零件採購系統為研究對象,比較以下兩句話,哪一句是“人話”,哪一句是“鳥語”?

    1)系統建立連接,打開連接,執行SQL語句,從“零件”表查詢……

    2系統根據查詢條件搜索零件

    其實,一眼就能看出,第一句是“鳥語”,第二句是“人話”了。不同職能多少會有主觀意識,做Java開發的覺得自己做的才是技術,需求屬於業務。但需求人員卻覺得自己做的也是技術,他們所研究的客戶才是業務。但客戶覺得自己做的才是技術……,這咋看起來有點像一個鄙視鏈。其實,大家做的都是“技術”,這是領域不同而已。應該用“核心域”和“非核心域”來代替“業務”和“技術”。

    如果所研究系統是一個關係數據庫的腳本工具,核心域是關係數據庫領域,上面提到的“系統建立連接,打開連接,執行SQL語句”就成了合適的需求。

    2.2.3.6、不要涉及界面細節

    很多人寫需求的時候,會把界面的細節帶進來,例如:

    ● 會員從下拉框中選擇類別

    ● 會員從文本框中輸入查詢條件

    ● 會員單擊“確定”按鈕

    這些界面細節很可能不是需求,更多是設計方案,背後可能隱藏更多的真正需求,也許是可用性需求“操作次數不超過5次”。但畢竟我們面對的客戶各種各樣的喜好都有,可能有些前排涉眾明確要求“一定要用下拉框”,那麼“下拉框”也是需求,但依然不能寫“會員從下拉框框中選擇類別”。因為這裏涉及兩類需求,她們的穩定性和變化趨勢不同,應該分開描述:

    ● 會員選擇類別(這是步驟)

    ● 通過下拉框來實現(這是設計約束)

    用例的需求組織方式是分層的,從用例的路徑、步驟、約束,穩定性會越來越低,如下所示:




    用例規約的需求層級

    把需求分層級了,穩定和不穩定的需求就分開了,更有利於了解事情的核心本質。平時遇到的大部分“需求變更”發生在補充約束級別,例如輸入會員信息時加個微信字段(字段列表變了),調整結賬時的打折規則(業務規則變了)。級別越高的需求,內容越穩定。

    很多時候做需求會把看得見和需求混為一談,真正的需求不見得是顯而易見的。需求判斷的標準不是涉眾是否看得見,而是涉眾是否在意。第一章已經學習過,需求和設計不是一一對應的,而是多對多的。

    2.2.3.7、不要涉及交互細節

    在步驟中,除了避免描述頁面細節,還要避免描述交互細節。例如有人會這樣寫:

    ● 會員每輸入賬戶名稱的一個字符

    ● 系統在界面中驗證當前輸入信息合法

    寫的人有他的道理:系統不是等待提交后才驗證輸入信息是否合法,而是隨時驗證立即反饋,這樣使用戶體驗更好。其實,這隻是交互設計的一些技能。忍不住要在需求規約里描述界面和交互的細節,背後的原因和忍不住要思考內部代碼如何實現的原因是一樣的,都是對自己的設計技能沒有信心,害怕“現在想到了如果不忘記記下來以後就忘記了”。這些都是人性的弱點。

    用例的步驟應該把焦點放在系統必須接收什麼輸入、系統必須輸出什麼信息以及系統必須做什麼處理這三個重點上,加上字段列表、業務規則、可用性需求等約束,足以表達各種需求。

    關於用例的交互怎麼寫,是一個比較頭疼的問題。即使不涉及交互設計細節的問題,也免不了混進交互設計的成分,例如,為什麼要分兩個回合而不是一個回合?實際上涉眾更希望一個回合就能達到用例的目標。所以,建議觀點是在用例規約中把路徑步驟刪掉,只保留輸入輸出、涉眾利益和補充約束,交互的路徑步驟由交互設計人員決定。

    2.2.3.8、需求是“不這樣不行”

    許多需求人員之所以在需求崗位上,並不是因為他掌握了該掌握的需求技能,可能只是因為他工作年限足夠長該換到需求崗位了——和許多年齡到了就上崗的夫妻和父母相似。這樣的需求人員硬着頭皮做需求時,最常用的一招就是托着腦袋想“這個東西是什麼樣子”,然後畫一個界面原型拿去和涉眾確認。一旦涉眾說“差不多就這樣吧”,就把這個界面原型作為需求交給分析設計人員。在這一點上,互聯網公司的產品經理表現得尤為明顯。如果僥倖成功,就拚命鼓吹“原型大法好”,因為他只會這個。

    當需求人員問問題時都是“這樣可以嗎”,相當於:

    ● 需求人員:界面這樣布局可以嗎?

    ● 涉    眾:(好用就行,我又不會做界面,問我可不可以我當然說可以了)可以。

    ● 需求人員:代碼這樣寫可以嗎?

    ● 涉    眾:(好用就行,我又不會寫代碼,問我可不可以我當然說可以了)可以。

    如果問的問題改為“不這樣可以嗎?”,像下面這樣:

    ● 需求人員:界面不這樣布局可以嗎?

    ● 涉    眾:不可以,這是政府的規定,你們不要自己亂髮揮啊!

    ● 需求人員:代碼不這樣寫可以嗎?

    ● 涉    眾:不可以,這段代碼是我小舅子寫的,一定要這樣,否則不給錢。

    這時,界面和代碼就成為了需求,當然,只是補充約束級別的需求。說到這裏,我們歸納出需求的判斷標準:需求是“不這樣不行”,而不是“這樣也行”。

    2.2.4、擴展路徑

    基本路徑上的每個步驟都有可能發生很多意外,其實某些意外是系統要負責處理的,處理意外的路徑就是擴展路徑。因為一個步驟上出現的意外及其處理可能有多種,所以同一步驟上的擴展路徑可能有多條。




    擴展路徑和步驟

    對於擴展路徑及其步驟的標號,本書採用的是Cockburn推薦的方法。擴展路徑的標號方法是在擴展步驟的数字序號後面加上字符序號,例如2a表示步驟2的第a條擴展路徑,2b表示步驟2的第b條擴展路徑。擴展路徑條件的最後加上冒號,接下來是該擴展路徑的步驟,標號方法是在擴展路徑編號後面加上数字序號,例如2a1。也就是說,步驟的編號以数字結尾,擴展路徑編號以字母結尾。如果多重擴展,那就繼續按此形式標註。還是以之前ATM“儲戶→取現金”用例為例。該用例規約加上擴展路徑之後如下所示:

    基本路徑:

    1. 儲戶提交賬戶號碼

    2. 系統驗證賬戶號碼合法

    3. 系統提示輸入密碼

    4. 儲戶輸入密碼

    5. 系統驗證密碼合法、正確

    6. 系統提示輸入取現金額

    7. 儲戶輸入取現金額

    8. 系統驗證取現金額合法

    9. 系統記錄取現信息,更新賬戶餘額

    ……

    2a. 賬戶號碼不合法:

             2a1.系統反饋賬戶號碼不合法

             2a2.返回1

    5a. 密碼不合法:

             5a1.返回3

    5b. 密碼合法但不正確:

             5b1.系統驗證當日取款累計輸錯密碼次數不超過3

                       5b1a.當日取款累計輸錯密碼次數超過3次:

                                5b1a1.系統關閉賬戶

                                5b1a2.用例結束

             5b2.系統反饋密碼不正確

             5b3.返回3

    8a. 取現金額不合法:

             8a1.返回6

    有一點需要注意,和輔執行者交互的步驟很有可能會出現擴展。例如:

    4. 系統請求短信平台發布信息

    ……

    擴展

    ……

    4a. 短信平台無響應:

             4a1.系統反饋短信平台無響應

    ……

    但,如果系統不需要從外部系統那裡得到任何結果,這個外系統就不是輔執行者,所以它出現故障會不會導致擴展的討論是沒有意義的。例如:

    5. 系統向經理的电子郵箱通知有新的待審批申請

    除了以上步驟之外,從其他步驟產生擴展路徑一定要非常謹慎,否則容易讓不屬於需求的內容混進用例規約中。特別要注意下面幾點。

    1)能感知和要處理的意外才是擴展

    2)設計技能不足導致的錯誤不是擴展

    3)不引起交互行為變化的選擇不是擴展

    4)界面跳轉不是擴展

    2.2.5、補充約束

    路徑步驟里描述的需求是不完整的。例如:

    用例名:發布講座消息

    ……

    1. 工作人員輸入講座信息,請求發布

    2. 系統驗證講座信息充分

    3. 系統生成發布內容

    4. 系統請求短信平台發布消息

    5. 系統保存講座信息和發布情況

    6. 系統反饋信息已經保存併發布

    ……

    步驟1中的“講座信息”包括哪些內容?需要添加字段列表。步驟2中“充分”指什麼,需要添加業務規則。從步驟1到步驟6有沒有速度上的要求?需要質量需求。

    如果補充約束的內容只和單個用例相關,可以直接放在該用例的規約中;如果補充約束適用於多個用例,可以單獨集中到另外的地方,從用例規約引用。

    補充約束前面的編號不代表順序,而是表示該約束綁定的步驟編號,如果某條補充約束不是針對某一步驟,而是針對多個步驟甚至整個用例,前面的編號可以是“*”,如下所示:

    5. 發布情況=發布時間+工作人員

    補充約束的類型可用類圖表示:




    用例的補充約束

    2.2.5.1、字段列表

    字段列表用來描述步驟里某個領域概念的細節。例如上面“發布講座消息”用例的步驟中,步驟1、3、5都需要分別添加字段列表。

    字段列表可以用自然語言表達,例如:

    字段列表

    1. 講座信息包括:舉辦時間、地點、專家信息、主題、簡介。專家信息包括:姓名、單位、頭銜。

    也可以用符號表達,例如:

    字段列表

    1. 講座信息=舉辦時間+地點+專家+主題+簡介

    1. 專家=姓名+單位+頭銜

    表示的符號可以採用過去數據字典常用的符號。例如:“+”表示數據序列,“()”表示可選項,“{}”表示多個,“[|||]”表示可能的取值。例如:

    註冊信息=公司名+聯繫人+電話+{聯繫地址}

    聯繫地=州+城市+街道+(郵編)

    保存信息=註冊信息+註冊時間

    客房狀態=[空閑|已預定|佔用|維修中]

    很多時候,做需求會把設計的細節帶上,例如“電話號碼varchar(255)”或把數據模型圖附上,這是不準確的。數據模型是設計,設計應該來源於需求,而非空想一個設計,然後把他當成需求。

    2.2.5.2、業務規則

    業務規則描述步驟中系統運算的一些規則,例如上面“發布講座消息”用例的步驟2中的“充分”沒有說清楚,需要添加業務規則,例如:

    業務規則:

    2. 必須有的項包括:時間、地點、專家、主題

    其實,主要涉眾能理解,行業上適用的任何方式(例如數學、物理公式)都可以用來表達業務規則。描述業務規則時要注意:業務規則不等於實現算法。因為業務規則也是一種需求,也是從涉眾的角度看“不這樣不行”的。例如,研究一款為盲人或殘疾人而做的語音輸入軟件,用例規約有如下片段:

    3. 系統將語音輸入翻譯為文字

    業務規則

    3. 採用XX識別算法

    這樣的業務規則可能是有問題的,如果前排是盲人或殘疾人,他們是不懂什麼叫“XX算法”,也不在意你是否用了這個算法,他們在意的需求是:“背景噪音強度為XX的情況下,識別率應該在XX以上”。當然也不排除前排涉眾是有意推廣某廠家的識別技術,那麼“採用XX識別算法”也可以成為需求。

    2.2.5.3、質量需求

    系統滿足功能需求,說明系統能把事情做正確。在做正確的基礎上,系統還需要在做的過程中滿足一些指標,這些指標就是質量需求,也被稱為“非功能需求”。

    1)可用性

    可用性需求是對人類執行者和系統之間交互質量的度量。如果系統僅能正確達到用例目標,但交互太頻繁,人類執行者是不喜歡用的。在表達可用性需求時,僅僅說“系統容易使用”是不行的。這是無法量化的目標,合適的可用性需求應該是可以度量的,例如:




    可用性度量

    2)性能

    性能包括速度、容量、能力等,例如:

    ① 系統應在0.5秒之內拍攝超速車的照片(速度)

    ② 應允許1000個執行者同時使用此用例(容量)

    ③ 在標準工作負荷下,系統的CPU佔用率應少於50%(能力)

    在尋找質量需求時,性能類型的質量需求往往是最多的。

    3)可靠性

    可靠性表示系統的安全性和完整性,通常用平均無故障時間(MTBF,Mean Time Between Failures)和平均修復時間(MTTR, Mean Time To Repair)表示。可靠性需求往往不是針對單個用例,而是針對整個系統,可以在所有用例規約的最後,單獨用小篇幅描述。

    4)可支持性

    可支持性表示系統升級和修復的能力。例如:

    ① 95%的緊急錯誤應能在30個工作時內修復

    ② 在修復故障時,未修復的相關缺陷平均數應小於0.5

    ③ 升級新版本時,應保存所有系統設置和個人設置

    和可靠性一樣,可支持性需求往往不是針對單個用例,而是針對整個系統,可以在所有用例規約的最後,單獨用小篇幅描述。

    以上介紹了質量需求的種類,很多時候質量需求不用可以去尋找,按照前面說過的“不這樣行嗎”的標準,把混入需求的設計刪掉,然後問為什麼,背後往往隱含的就是質量需求,如下所示:




    質量需求

    2.2.5.4、設計約束

    設計約束是在實現系統時必須要遵守的一些約束,包括界面樣式、報表格式、平台、語言等。

    設計約束既不是功能需求,也不是質量需求。例如,“用Oracle數據庫保存數據”,其實用DB2也可以滿足同樣的功能需求和質量需求,但必須要用Oracle,因為客戶已經採購了許多Oracle數據庫軟件,如果不用,成本就會增加。

    設計約束是需求的一種,也一樣要從涉眾的視角描述。在很多需求規約中,不少來自開發人員視角的設計偽裝成設計約束,混進了需求的隊伍。例如“系統應採用三層架構方式搭建”,涉眾並不了解“三層”好在哪裡,為什麼不是四層、五層等,然後問“為什麼”,背後的真正需求可能還是性能需求。

    需求是問題,設計是解決方案,二者的穩定性不同。

     

    2.3、需求啟發

    2.3.1、需求啟發要點

    需求人員要能夠像獵人一樣,用銳利的眼睛發現隱藏在叢林中的獵物,像偵探一樣,用縝密的思維判斷出偽裝成好人的兇手。但需求人員會有許多的障礙:如

    1)需求的一個啟發障礙是知識的詛咒,意思是:一旦知道某個東西,就很難相像不知道它會是什麼樣子;

    2)知識的詛咒在需求啟發中體現為溝通的困難;

    3)需求啟發的另一個障礙是做和定義的不同;

    但理解了以下兩個要點,有助於克服需求啟發中的障礙:

    1)和涉眾交流的形式應該採用視圖,而不是模型;

    2)和涉眾交流的內容應該聚焦涉眾利益,而不是需求;

    2.3.2、需求啟發手段




    需求啟發手段

    2.3.3、需求人員的素質培養




    需求人員的素質

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

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

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

    ※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

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

  • PL真有意思(三):名字、作用域和約束

    前言

    這兩篇寫了詞法分析和語法分析,比較偏向實踐。這一篇來看一下語言設計里一個比較重要的部分:名字。在大部分語言里,名字就是標識符,如果從抽象層面來看名字就是對更低一級的內存之類的概念的一層抽象。但是名字還有其它相關的比如它的約束時間和生存周期等等

    約束時間

    約束就是兩個東西之間的一種關聯,例如一個名字和它所命名的事物,約束時間就是指創建約束的時間。有關的約束可以在許多不同的時間作出

    • 語言設計時
    • 語言實現時
    • 編寫程序時
    • 編譯時
    • 鏈接時
    • 裝入時
    • 運行時

    這就是為什麼基於編譯的語言實現通常會比基於解釋器的語言的實現更高效的原因,因為基於編譯的語言在更早的時候就做了約束,比如對於全局變量在編譯時就已經確定了它在內存中的布局了

    對象生存期和存儲管理

    在名字和它們所引用的對象的約束之間有幾個關鍵事件

    • 對象的創建
    • 約束的創建
    • 對變量、子程序、類型等的引用,所有這些都使用了約束
    • 對可能暫時無法使用的約束進行失活或者重新約束
    • 約束的撤銷
    • 對象的撤銷

    對象的生存期和存儲分配機制有關

    • 靜態對象被賦予一個絕對地址,這個地址在程序的整個執行過程中都保持不變
    • 棧對象按照後進先出的方式分配和釋放,通常與子程序的調用和退出同時進行
    • 堆對象可以在任意時刻分配或者釋放,它們要求更通用的存儲管理算法

    靜態分配

    全局變量是靜態對象最顯而易見的例子,還有構成程序的機器語言翻譯結果的那些指令,也可以看作是靜態分配對象。

    還有像每次調用函數都會保持相同的值的局部變量也是靜態分配的。對於數值和字符串這些常量也是靜態分配。

    還有用來支持運行時的各種程序,比如廢料收集和異常處理等等也可以看作是靜態分配

    基於棧的分配

    如果一種語言允許遞歸,那麼局部變量就不能使用靜態分配的方式了,因為在同一時刻,一個局部變量存在的實例個數是不確定的

    所以一般對於子程序,都用棧來保存它相關的變量信息。在運行時,一個子程序的每個實例都在棧中有一個相應的棧幀,保存着它的參數、返回值、局部變量和一些簿記信息

    基於堆的分配

    堆是一塊存儲區域,其中的子存儲塊可以在任意時間分配與釋放。因為堆具有它的動態性,所以就需要對堆空間進行嚴格的管理。許多存儲管理算法都維護着堆中當前尚未使用的存儲塊的一個鏈接表,稱為自由表。

    初始時這個表只有一個塊,就是整個堆,每當遇到分配請求時,算法就在表中查找一個大小適當的塊。所以當請求次數增多,就會出現碎片問題,也需要相應的解決

    所以有廢料收集的語言其實就是對堆的管理

    作用域作用

    一個約束起作用的那一段程序正文區域,稱為這個約束的作用域。

    現在大多數語言使用的都是靜態作用域,也就是在編譯時就確定了。也有少數語言使用動態作用域,它們的約束需要等到運行時的執行流才能確定

    靜態作用域

    在使用靜態作用域的語言,也叫作詞法作用域。一般當前的約束就是程序中包圍着一個給定點的最近的,其中有與該名字匹配的聲明的那個快中建立的那個約束。比如C語言在進入子程序時,如果局部變量和全局變量,那麼當前的約束就是與局部變量關聯,直到退齣子程序才撤銷這個約束

    但是有的語言提供了一種可以提供約束的生存期的機制,比如Fortran的save和C的static

    嵌套子程序

    有許多語言允許一個子程序嵌套在另一個子程序的。這樣有關約束的定義通常來說都是首先用這個名字在當前、最內層的作用域中查找相應的聲明,如果找不到就直接到更外圍的作用域查找當前的約束,直到到達全局作用域,否則就發生一個錯誤

    訪問非局部變量

    上面提到的訪問外圍作用域的變量,但是當前子程序只能訪問到當前的棧幀,所以就需要一個調用幀鏈來讓當前的作用域訪問到外圍作用,通過調用順序形成一個靜態鏈

    聲明的順序

    關於約束還有一個問題,就是在同一作用域里,先聲明的名字是否能使用在此之後的聲明

    在Pascal里有這樣兩條規則:

    1. 修改變量要求名字在使用之前就進行聲明
    2. 但是當前聲明的作用域是整個程序塊

    所以在這兩個的相互作用下,會造成一個讓人吃驚的問題

    const N = 10;
    
    procedure foo;
    const
      M = N; (*靜態語義錯誤*)
      N = 20;

    但是在C、C++和Java等語言就不會出現這個問題,它們都規定標識符的作用域不是整個塊,而是從其聲明到塊結束的那一部分

    並且C++和Java還進一步放寬了規則,免除了使用之前必須聲明的要求

    模塊

    恰當模塊化的代碼可以減少程序員的思維負擔,因為它最大限度的減少了理解系統的任意給定部分時所需的信息量。在設計良好的程序中,模塊之間的接口應盡可能的小,所有可能改變的設計決策都隱藏在某個模塊里。

    模塊作為抽象

    模塊可以將一組對象(如子程序、變量、類型)封裝起來。使得:

    1. 這些內部的對象相互可見
    2. 但是外部對象和內部對象,除非显示的導入,否則都是不可見的

    模塊作為管理器

    模塊使我們很容易的創建各種抽象,但是如果需要多個棧的實例,那麼就需要一個讓模塊成為一個類型的管理器。這種管理器組織方式一般都是要求在模塊中增加創建/初始化函數,並給每一個函數增加一個用於描述被操作的實例

    模塊類型

    對於像這種多實例的問題,除了管理器,在許多語言里的解決方法都是可以將模塊看作是類型。當模塊是類型的時候,就可以將當前的方法認為是屬於這個類型的,簡單來說就是調用方法變化了

    push(A, x) -> A.push(x)

    本質上的實現區別不大

    面向對象

    在更面向對象里的方法里,可以把類看作是一種擴充了一種繼承機制的模塊類型。繼承機制鼓勵其中所有操作都被看作是從屬於對象的,並且新的對象可以從現有對象繼承大部分的操作,而不需要為這些操作重寫代碼。

    類的概念最早應該是起源於Simula-67,像後來的C++,Java和C#中的類的思想也都起源於它。類也是像Python和Ruby這些腳本語言的核心概念

    從模塊到模塊類型再到類都是有其思想基礎,但是最初都是為了更好的數據抽象。但是即使有了類也不能完全取代模塊,所以許多語言都提供了面向對象和模塊的機制

    動態作用域

    在使用動態作用域的語言中,名字與對象間的約束依賴於運行時的控制流,特別是依賴子程序的調用順序

    n : integer
    
    procedure first
      n := 1
    
    procedure second
      n : integer
      first()
    
    n := 2
    if read_integer() > 0
      second()
    else
      first()
    write_integer()

    這裏最後的輸出結果完全取決於read_integer讀入的数字的正負,如果為正,輸出就為2,否則就打印一個1

    作用域的實現

    為了跟蹤靜態作用域程序中的哥哥名字,編譯器需要依靠一個叫做符號表的數據結構。從本質上看,符號表就是一個記錄名字和它已知信息的映射關係的字典,但是由於作用域規則,所以還需要更強大的數據結構。像之前那個寫編譯器系列的符號表就是使用哈希表加上同一層作用域鏈表來實現的

    而對於動態作用域來說就需要在運行時執行一些操作

    作用域中名字的含義

    別名

    在基於指針的數據結構使用別名是很自然的情況,但是使用別名可能會導致編譯器難以優化或者造成像懸空引用的問題,所以需要謹慎使用

    重載

    在大多數語言中都或多或少的提供了重載機制,比如C語言中(+)可以被用在整數類型也可以用在浮點數類型,還有Java中的String類型也支持(+)運算髮

    要在編譯器的符號表中處理重載問題,就需要安排查找程序根據當前的上下文環境返回一個有意義的符號

    比如C++、Java和C#中的類方法重載都可以根據當前的參數類型和數量來判斷使用哪個符號

    內部運算符的重載

    C++、C#和Haskell都支持用戶定義的類型重載內部的算術運算符,在C++和C#的內部實現中通常是將A+B看作是operator+(A, B)的語法糖

    多態性

    對於名字,除了重載還有兩個重要的概念:強制和多態。這三個概念都用於在某些環境中將不同類型的參數傳給一個特定名字的子程序

    強制是編譯器為了滿足外圍環境要求,自動將某類型轉換為另一類型的值的操作

    所以在C中,定義一個計算整數或者浮點數兩個值中的最小值的函數

    double min(double x, double y);

    只要浮點數至少有整數那麼多有效二進制位,那麼結果就一定會是正確的。因為編譯器會對int類型強制轉換為double類型

    這是強制提供的方法,但是多態性提供的是,它使同一個子程序可以不加轉換的接受多種類型的參數。要使這個概念有意義,那麼這多種類型肯定要具有共同的特性

    顯式的參數多態性就叫做泛型,像Ada、C++、Clu、Java和C#都支持泛型機制,像剛才的例子就可以在Ada中用泛型來實現

    generic
      type T is private;
      with function "<" (x, y : T) return Boolean;
    function min(x, y : T) return T;
    
    function min(x, y : T) return T is
    begin
      if x < y then return x;
      else return y;
      end if;
    end min
    
    function string_min is new min(string, "<")
    function date_min is new min(date, date_precedes);

    像List和ML中就可以直接寫

    (define min (lambda (a b) (if (< a b) a b)))

    其中有關類型的任何細節都由解釋器處理

    引用環境的約束

    提到引用環境的約束就有兩種方式:淺約束和深約束

    推遲到調用時建立約束的方式淺約束。一般動態作用域的語言默認是淺約束,當然動態作用域和深約束也是可以組合到一起的。
    執行時依然使用傳遞時的引用環境,而非執行時的引用環境。那麼這種規則稱為深約束,一般靜態作用域的語言默認是深約束

    閉包

    為了實現神約束,需要創建引用環境的一種顯示錶示形式,並將它與對有關子程序的引用捆綁在一起,這樣的捆綁叫做閉包

    總而言之,如果子程序可以被當作參數傳遞,那麼它的引用環境一樣也會被傳遞過去

    一級值和非受限生存期

    一般而言,在語言中,如果一個值可以賦值給變量、可以當作參數傳遞、可以從子程序返回,那麼它被稱為具有一級狀態(和我們在js中說函數是一等公民一個含義)。大多數的語言中數據對象都是一級狀態。二級狀態是只能當作參數傳遞;三級值則是連參數也不能做,比如C#中一些+-*/等符號。

    在一級子程序會出現一個複雜性,就是它的生存期可能持續到這個子程序的作用域的執行期外。為了避免這一問題,大部分函數式語言都表示局部變量具有非受限的生命周期,它們的生命周期無限延長,直到GC能證明這些對象再也不使用了才會撤銷。那麼不撤銷帶來的問題就是這些子程序的存儲分配基於棧幀是不行了,只能是基於堆來分配管理。為了維持能基於棧的分配,有些語言會限制一級子程序的能力,比如C++,C#,都是不允許子程序嵌套,也就從根本上不會存在閉包帶來的懸空引用問題。

    小結

    這一篇從名字入手,介紹了名字與其背後的對象的約束關係、以及約束時間的概念;然後介紹了對象的分配策咯(靜態、棧、堆);緊接着討論了名字與對象之間建立的約束的生命周期,並由此引出了作用域的概念;進一步延伸出多個約束組成的引用環境的相關概念以及問題。

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

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

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

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

  • Kafka冪等性原理及實現剖析

    Kafka冪等性原理及實現剖析

    1.概述

    最近和一些同學交流的時候反饋說,在面試Kafka時,被問到Kafka組件組成部分、API使用、Consumer和Producer原理及作用等問題都能詳細作答。但是,問到一個平時不注意的問題,就是Kafka的冪等性,被卡主了。那麼,今天筆者就為大家來剖析一下Kafka的冪等性原理及實現。

    2.內容

    2.1 Kafka為啥需要冪等性?

    Producer在生產發送消息時,難免會重複發送消息。Producer進行retry時會產生重試機制,發生消息重複發送。而引入冪等性后,重複發送只會生成一條有效的消息。Kafka作為分佈式消息系統,它的使用場景常見與分佈式系統中,比如消息推送系統、業務平台系統(如物流平台、銀行結算平台等)。以銀行結算平台來說,業務方作為上游把數據上報到銀行結算平台,如果一份數據被計算、處理多次,那麼產生的影響會很嚴重。

    2.2 影響Kafka冪等性的因素有哪些?

    在使用Kafka時,需要確保Exactly-Once語義。分佈式系統中,一些不可控因素有很多,比如網絡、OOM、FullGC等。在Kafka Broker確認Ack時,出現網絡異常、FullGC、OOM等問題時導致Ack超時,Producer會進行重複發送。可能出現的情況如下:

     

     

    2.3 Kafka的冪等性是如何實現的?

    Kafka為了實現冪等性,它在底層設計架構中引入了ProducerID和SequenceNumber。那這兩個概念的用途是什麼呢?

    • ProducerID:在每個新的Producer初始化時,會被分配一個唯一的ProducerID,這個ProducerID對客戶端使用者是不可見的。
    • SequenceNumber:對於每個ProducerID,Producer發送數據的每個Topic和Partition都對應一個從0開始單調遞增的SequenceNumber值。

    2.3.1 冪等性引入之前的問題?

    Kafka在引入冪等性之前,Producer向Broker發送消息,然後Broker將消息追加到消息流中后給Producer返回Ack信號值。實現流程如下:

     

    上圖的實現流程是一種理想狀態下的消息發送情況,但是實際情況中,會出現各種不確定的因素,比如在Producer在發送給Broker的時候出現網絡異常。比如以下這種異常情況的出現:

     

    上圖這種情況,當Producer第一次發送消息給Broker時,Broker將消息(x2,y2)追加到了消息流中,但是在返回Ack信號給Producer時失敗了(比如網絡異常) 。此時,Producer端觸發重試機制,將消息(x2,y2)重新發送給Broker,Broker接收到消息后,再次將該消息追加到消息流中,然後成功返回Ack信號給Producer。這樣下來,消息流中就被重複追加了兩條相同的(x2,y2)的消息。

    2.3.2 冪等性引入之後解決了什麼問題?

    面對這樣的問題,Kafka引入了冪等性。那麼冪等性是如何解決這類重複發送消息的問題的呢?下面我們可以先來看看流程圖:

     

     同樣,這是一種理想狀態下的發送流程。實際情況下,會有很多不確定的因素,比如Broker在發送Ack信號給Producer時出現網絡異常,導致發送失敗。異常情況如下圖所示:

     

     當Producer發送消息(x2,y2)給Broker時,Broker接收到消息並將其追加到消息流中。此時,Broker返回Ack信號給Producer時,發生異常導致Producer接收Ack信號失敗。對於Producer來說,會觸發重試機制,將消息(x2,y2)再次發送,但是,由於引入了冪等性,在每條消息中附帶了PID(ProducerID)和SequenceNumber。相同的PID和SequenceNumber發送給Broker,而之前Broker緩存過之前發送的相同的消息,那麼在消息流中的消息就只有一條(x2,y2),不會出現重複發送的情況。

    2.3.3 ProducerID是如何生成的?

    客戶端在生成Producer時,會實例化如下代碼:

    // 實例化一個Producer對象
    Producer<String, String> producer = new KafkaProducer<>(props);

    在org.apache.kafka.clients.producer.internals.Sender類中,在run()中有一個maybeWaitForPid()方法,用來生成一個ProducerID,實現代碼如下:

     private void maybeWaitForPid() {
            if (transactionState == null)
                return;
    
            while (!transactionState.hasPid()) {
                try {
                    Node node = awaitLeastLoadedNodeReady(requestTimeout);
                    if (node != null) {
                        ClientResponse response = sendAndAwaitInitPidRequest(node);
                        if (response.hasResponse() && (response.responseBody() instanceof InitPidResponse)) {
                            InitPidResponse initPidResponse = (InitPidResponse) response.responseBody();
                            transactionState.setPidAndEpoch(initPidResponse.producerId(), initPidResponse.epoch());
                        } else {
                            log.error("Received an unexpected response type for an InitPidRequest from {}. " +
                                    "We will back off and try again.", node);
                        }
                    } else {
                        log.debug("Could not find an available broker to send InitPidRequest to. " +
                                "We will back off and try again.");
                    }
                } catch (Exception e) {
                    log.warn("Received an exception while trying to get a pid. Will back off and retry.", e);
                }
                log.trace("Retry InitPidRequest in {}ms.", retryBackoffMs);
                time.sleep(retryBackoffMs);
                metadata.requestUpdate();
            }
        }

    3.事務

    與冪等性有關的另外一個特性就是事務。Kafka中的事務與數據庫的事務類似,Kafka中的事務屬性是指一系列的Producer生產消息和消費消息提交Offsets的操作在一個事務中,即原子性操作。對應的結果是同時成功或者同時失敗。

    這裏需要與數據庫中事務進行區別,操作數據庫中的事務指一系列的增刪查改,對Kafka來說,操作事務是指一系列的生產和消費等原子性操作。

    3.1 Kafka引入事務的用途?

    在事務屬性引入之前,先引入Producer的冪等性,它的作用為:

    • Producer多次發送消息可以封裝成一個原子性操作,即同時成功,或者同時失敗;
    • 消費者&生產者模式下,因為Consumer在Commit Offsets出現問題時,導致重複消費消息時,Producer重複生產消息。需要將這個模式下Consumer的Commit Offsets操作和Producer一系列生產消息的操作封裝成一個原子性操作。

    產生的場景有:

    比如,在Consumer中Commit Offsets時,當Consumer在消費完成時Commit的Offsets為100(假設最近一次Commit的Offsets為50),那麼執行觸發Balance時,其他Consumer就會重複消費消息(消費的Offsets介於50~100之間的消息)。

    3.2 事務提供了哪些可使用的API?

    Producer提供了五種事務方法,它們分別是:initTransactions()、beginTransaction()、sendOffsetsToTransaction()、commitTransaction()、abortTransaction(),代碼定義在org.apache.kafka.clients.producer.Producer<K,V>接口中,具體定義接口如下:

    // 初始化事務,需要注意確保transation.id屬性被分配
    void initTransactions();
    
    // 開啟事務
    void beginTransaction() throws ProducerFencedException;
    
    // 為Consumer提供的在事務內Commit Offsets的操作
    void sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata> offsets,
                                  String consumerGroupId) throws ProducerFencedException;
    
    // 提交事務
    void commitTransaction() throws ProducerFencedException;
    
    // 放棄事務,類似於回滾事務的操作
    void abortTransaction() throws ProducerFencedException;

    3.3 事務的實際應用場景有哪些?

    在Kafka事務中,一個原子性操作,根據操作類型可以分為3種情況。情況如下:

    • 只有Producer生產消息,這種場景需要事務的介入;
    • 消費消息和生產消息並存,比如Consumer&Producer模式,這種場景是一般Kafka項目中比較常見的模式,需要事務介入;
    • 只有Consumer消費消息,這種操作在實際項目中意義不大,和手動Commit Offsets的結果一樣,而且這種場景不是事務的引入目的。

    4.總結

    Kafka的冪等性和事務是比較重要的特性,特別是在數據丟失和數據重複的問題上非常重要。Kafka引入冪等性,設計的原理也比較好理解。而事務與數據庫的事務特性類似,有數據庫使用的經驗對理解Kafka的事務也比較容易接受。

    5.結束語

    這篇博客就和大家分享到這裏,如果大家在研究學習的過程當中有什麼問題,可以加群進行討論或發送郵件給我,我會盡我所能為您解答,與君共勉!

    另外,博主出書了《》和《》,喜歡的朋友或同學, 可以在公告欄那裡點擊購買鏈接購買博主的書進行學習,在此感謝大家的支持。關注下面公眾號,根據提示,可免費獲取書籍的教學視頻。 

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

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

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

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

  • 從零開始搭建前後端分離的NetCore2.2(EF Core CodeFirst+Autofac)+Vue的項目框架之十二Swagger(參數)使用二

    從零開始搭建前後端分離的NetCore2.2(EF Core CodeFirst+Autofac)+Vue的項目框架之十二Swagger(參數)使用二

      引言

      在 中提到了 Swagger 的基本使用,僅限於沒有參數,沒有驗證的那種api文檔生成,那麼這篇就連接上篇繼續,在一般具有安全性、權限等驗證的接口上,

      都會在header/url中加上請求者的秘鑰、簽名等,當然也有可能添加到body等其它地方, Swashbuckle.AspNetCore 都支持這些寫法。

      如何使用 — 下面將介紹兩種使用方式

    兩種方式參數設置到何處都是在  In屬性上,屬性對於值如下:    參考

    • query: 參数字段值對應放在url中
    • header: 參數值對應放在header param中
    • body: 參數對應放到請求體中
    • path: 參數應該對應放到請求路徑  // 具體貌似沒用
    • formData: 參數對應放到請求表單中

      第一種:將一個或多個參數保護API的“securityDefinitions”添加到生成的Swagger中。

    這種是直接在文檔的右上方添加一個 Authorize 按鈕,設置了值后,每一個請求都會在設置的位置上加上相應的值,在 上一篇隨筆中的 ConfigureServices 方法中,

    對應位置 services.AddSwaggerGen(options =>{}) 中的  XmlComments  下 添加代碼如下:

                    options.AddSecurityDefinition("token", new ApiKeyScheme
                    {
                        Description = "token format : {token}",//參數描述
                        Name = "token",//名字
                        In = "header",//對應位置
                        Type = "apiKey"//類型描述
                    });
                    options.AddSecurityDefinition("sid", new ApiKeyScheme
                    {
                        Description = "sid format : {sid}",//參數描述
                        Name = "sid",//名字
                        In = "header",//對應位置
                        Type = "apiKey"//類型描述
                    });
                    //添加Jwt驗證設置 設置為全局的,不然在代碼中取不到
                    options.AddSecurityRequirement(new Dictionary<string, IEnumerable<string>> {
                        { "token", Enumerable.Empty<string>() },
                        { "sid", Enumerable.Empty<string>() },
                    });

      添加完成后,運行起來看下效果,效果圖: 

     設置上對應值,調用測試方法,可以在header中取到剛設置到的值,

     這裡能看到,可以取到設置的參數了。這樣一來,在需要驗證的接口上,我們就可以通過接口文檔來測試了。基本不用再藉助postman等接口測試工具了。

    但是,但是,這裡有一個問題,就是只要設置了參數值,每一次訪問都會在請求中帶上參數。

    下面將介紹第二種方式,只給需要驗證用戶的接口上添加驗證參數。

      第二種:使用“filters”擴展Swagger生成器,來實現只在需要添加參數的方法上添加參數。複雜的可以根據自己的需求來添加對應參數

    實現方式就是先新建一個類,名: SwaggerParameter ,實現 IOperationFilter 接口。SwaggerParameter 類代碼如下: 

        /// <summary>
        /// 自定義添加參數
        /// </summary>
        public class SwaggerParameter : IOperationFilter
        {
            /// <summary>
            /// 實現 Apply 方法
            /// </summary>
            /// <param name="operation"></param>
            /// <param name="context"></param>
            public void Apply(Operation operation, OperationFilterContext context)
            {
                if (operation.Parameters == null) operation.Parameters = new List<IParameter>();
                var attrs = context.ApiDescription.ActionDescriptor.AttributeRouteInfo;
                var t = typeof(BaseUserController);
                //先判斷是否是繼承用戶驗證類
                if (context.ApiDescription.ActionDescriptor is ControllerActionDescriptor descriptor && context.MethodInfo.DeclaringType?.IsSubclassOf(t) == true)
                {
                    //再驗證是否允許匿名訪問
                    var actionAttributes = descriptor.MethodInfo.GetCustomAttributes(inherit: true);
                    bool isAnonymous = actionAttributes.Any(a => a is AllowAnonymousAttribute);
                    // 需要驗證的方法添加
                    if (!isAnonymous)
                    {
                        operation.Parameters.Add(new NonBodyParameter()
                        {
                            Name = "sid",
                            In = "header", //query header body path formData
                            Type = "string",
                            Required = true,//是否必選
                            Description = "登錄返回的sid"
                        });
                        operation.Parameters.Add(new NonBodyParameter()
                        {
                            Name = "token",
                            In = "header", //query header body path formData
                            Type = "string",
                            Required = true,//是否必選
                            Description = "登錄返回的token"
                        });
                    }
                }
            }
        }

     運行起來后,進入到  文檔頁面,可以看到右上角的 Authorize 按鈕已經不見了,在不需要驗證的方法上,也找不到相應需要設置參數的輸入框。就只有在需要驗證的接口上才有。

    參考Swagger文檔圖如下: 

    參考代碼圖如下:

     

    效果圖: 

      這樣一來設置也就完成了。從上面就能看出,就只有需要用戶驗證的接口才會有相應參數。 

     

    我的設置方式是先定義了用戶驗證控制器類,讓需要用戶驗證的控制器繼承該控制器,然後在該控制器中不需要用戶驗證的接口上加上 AllowAnonymous 屬性 

    設置fitter時就可以根據上面提到的兩個點來進行判斷是否需要加上參數,如果不是這樣實現的,可以根據自己的需求變更fitter類,來控制文檔的生成。 

     

    以上若有什麼不對或可以改進的地方,望各位指出或提出意見,一起探討學習~ 

    有需要源碼的可通過此 鏈接拉取 覺得還可以的給個 start 和點個 下方的推薦哦~~謝謝!

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

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

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

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

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

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

  • (三十五)golang–面向對象之多態

    (三十五)golang–面向對象之多態

    多態:變量具有多種形態,可以用統一的接口來調用不同的實現。

    接口體現多態特徵:

    (1)多態參數:之前所講的Usb接口案例,既可以接受手機變量,也可以接受相機變量,就體現了usb接口的多態;

    (2)多態數組:

    package main
    
    import (
        "fmt"
    )
    
    type usb interface {
        start()
        stop()
    }
    
    type phone struct {
        name string
    }
    
    func (p phone) start() {
        fmt.Println(p.name, "手機開始工作")
    }
    
    func (p phone) stop() {
        fmt.Println(p.name, "手機停止工作")
    }
    
    type camera struct {
        name string
    }
    
    func (c camera) start() {
        fmt.Println(c.name, "相機開始工作")
    }
    
    func (c camera) stop() {
        fmt.Println(c.name, "相機停止工作")
    }
    
    type computer struct {
    }
    
    func (co computer) working(usb usb) {
        usb.start()
        usb.stop()
    }
    
    func main() {
        var usbArr [3]usb
        usbArr[0] = phone{"小米"}
        usbArr[1] = phone{"vivo"}
        usbArr[2] = camera{"尼康"}
        fmt.Println(usbArr)
        for i := 0; i < len(usbArr); i++ {
            usbArr[i].start()
            usbArr[i].stop()
        }
    }

    我們以前講到,數組是只能存儲同一種類型的數據,利用多態數組,就可以存儲不同的類型了;

    如何將一個接口變量賦值給一個自定義類型的變量?使用類型斷言

    類型斷言:由於接口是一般類型,不知道具體類型,如果要轉成具體類型,就需要使用類型斷言;要保持原來空接口指向的數據類型和斷言的數據類型一致;

    為了避免輸出panic報錯,可以進行斷言判斷;

    類型斷言實踐一:

    我們給phone中加入一個方法call(),在調用usb變量時,usb.call(),肯定是不對的,因為usb可能是phone,也可能是camera,而camera是沒有這個函數的,因此,在調用的時候用類型斷言。

    package main
    
    import (
        "fmt"
    )
    
    type usb interface {
        start()
        stop()
    }
    
    type phone struct {
        name string
    }
    
    func (p phone) start() {
        fmt.Println(p.name, "手機開始工作")
    }
    
    func (p phone) call() {
        fmt.Println(p.name,"手機在打電話")
    }
    
    func (p phone) stop() {
        fmt.Println(p.name, "手機停止工作")
    }
    
    type camera struct {
        name string
    }
    
    func (c camera) start() {
        fmt.Println(c.name, "相機開始工作")
    }
    
    func (c camera) stop() {
        fmt.Println(c.name, "相機停止工作")
    }
    
    type computer struct {
    }
    
    func (co computer) working(usb usb) {
        usb.start()
        //如果usb還指向phone的結構體變量,則還需要調用call方法
        if phone, ok := usb.(phone); ok { phone.call() }
        usb.stop()
    }
    
    func main() {
        var usbArr [3]usb
        usbArr[0] = phone{"小米"}
        usbArr[1] = phone{"vivo"}
        usbArr[2] = camera{"尼康"}
        var com computer
        fmt.Println(usbArr)
        for i := 0; i < len(usbArr); i++ {
            com.working(usbArr[i])
        }
    }

    類型斷言實踐2:循環判斷輸入參數的類型

    package main
    
    import (
        "fmt"
    )
    
    type student struct {
        name string
    }
    
    func typeJudge(items ...interface{}) {
        for index, x := range items {
            switch x.(type) {
            case bool:
                fmt.Printf("第%v個參數是bool類型,值是%v\n", index, x)
            case int, int32, int64:
                fmt.Printf("第%v個參數是整數類型,值是%v\n", index, x)
            case float32:
                fmt.Printf("第%v個參數是float32類型,值是%v\n", index, x)
            case float64:
                fmt.Printf("第%v個參數是float64類型,值是%v\n", index, x)
            case string:
                fmt.Printf("第%v個參數是string類型,值是%v\n", index, x)
            case student:
                fmt.Printf("第%v個參數是student類型,值是%v\n", index, x)
            case *student:
                fmt.Printf("第%v個參數是*student類型,值是%v\n", index, x)
            default:
                fmt.Printf("第%v個參數類型不確定,值是%v\n", index, x)
            }
        }
    }
    
    func main() {
        var n1 float32 = 1.1
        var n2 float64 = 1.2
        var n3 int32 = 1
        var name string = "tom"
        var n5 bool = true
    
        stu1 := student{"jack"}
        stu2 := &student{"bob"}
    
        typeJudge(n1, n2, n3, name, n5, stu1, stu2)
    }

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

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

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

    ※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

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