在開始講static之前，我想讓各位看一段有意思的代碼：

public class Test {
     
    static{
        System.out.println("test static 1");
    }
  
    static{
        System.out.println("test static 2");
    }
    
    public static void main(String[] args) {
         
    }
}

看完程序，小白童鞋發話了：啥玩意？main方法中啥都沒有，能運行啥？博主你個星星星…

運行結果：
test static 1
test static 2

小白童鞋:那啥…那啥…博主我說啥了，我啥都沒說…

其實，上面的代碼懂的自然懂，不懂的自然就不懂了，因為上面的代碼涉及到JVM的類加載了！當然不在本篇博客文章的範疇內，如果有興趣理解上面的程序，這篇文章可能會對你有所幫助

1、static存在的主要意義

static的主要意義是在於創建獨立於具體對象的域變量或者方法。以致於即使沒有創建對象，也能使用屬性和調用方法！

static關鍵字還有一個比較關鍵的作用就是 用來形成靜態代碼塊以優化程序性能。static塊可以置於類中的任何地方，類中可以有多個static塊。在類初次被加載的時候，會按照static塊的順序來執行每個static塊，並且只會執行一次。

　　為什麼說static塊可以用來優化程序性能，是因為它的特性:只會在類加載的時候執行一次。因此，很多時候會將一些只需要進行一次的初始化操作都放在static代碼塊中進行。

2、static的獨特之處

1、被static修飾的變量或者方法是獨立於該類的任何對象，也就是說，這些變量和方法不屬於任何一個實例對象，而是被類的實例對象所共享。

怎麼理解 “被類的實例對象所共享” 這句話呢？就是說，一個類的靜態成員，它是屬於大夥的【大夥指的是這個類的多個對象實例，我們都知道一個類可以創建多個實例！】，所有的類對象共享的，不像成員變量是自個的【自個指的是這個類的單個實例對象】…我覺得我已經講的很通俗了，你明白了咩？

2、在該類被第一次加載的時候，就會去加載被static修飾的部分，而且只在類第一次使用時加載並進行初始化，注意這是第一次用就要初始化，後面根據需要是可以再次賦值的。

3、static變量值在類加載的時候分配空間，以後創建類對象的時候不會重新分配。賦值的話，是可以任意賦值的！

4、被static修飾的變量或者方法是優先於對象存在的，也就是說當一個類加載完畢之後，即便沒有創建對象，也可以去訪問。

3、static應用場景

因為static是被類的實例對象所共享，因此如果某個成員變量是被所有對象所共享的，那麼這個成員變量就應該定義為靜態變量。

因此比較常見的static應用場景有：

1、修飾成員變量
2、修飾成員方法
3、靜態代碼塊
4、修飾類【只能修飾內部類也就是靜態內部類】
5、靜態導包

以上的應用場景將會在下文陸續講到…

4、靜態變量和實例變量的概念

靜態變量：
static修飾的成員變量叫做靜態變量【也叫做類變量】，靜態變量是屬於這個類，而不是屬於是對象。

實例變量：
沒有被static修飾的成員變量叫做實例變量，實例變量是屬於這個類的實例對象。

還有一點需要注意的是：static是不允許用來修飾局部變量，不要問我問什麼，因為java規定的！

5、靜態變量和實例變量區別【重點常用】

靜態變量：
靜態變量由於不屬於任何實例對象，屬於類的，所以在內存中只會有一份，在類的加載過程中，JVM只為靜態變量分配一次內存空間。

實例變量：
每次創建對象，都會為每個對象分配成員變量內存空間，實例變量是屬於實例對象的，在內存中，創建幾次對象，就有幾份成員變量。

我相信各位智商都比宜春智商要高，應該都能理解上面的話。下面舉了例子完全出於娛樂，理解了大可不必看，下面的例子僅供參考，僅供娛樂一下下氣氛，趕時間的熊dei大可略過！

怎麼理解呢？打個比喻吧…就比方說程序員小王是一個比較溫柔陽光的男孩子，這1024的這一天，老闆閑的沒事，非要拉着程序員小王來玩耍，怎麼個玩法呢？老闆和小王一人拿着一把菜刀，規則很簡單，互相傷害，一人一刀，你一刀，我一刀….遊戲一開始，老闆二話不說，跳起來就是一刀，程序員小王二話也沒說反手就是一菜刀回去，這個時候老闆發飆了，雙眼瞪得忒大，跳起來又是一刀，這個時候程序員小王不敢還手了，就沒動手。沒想到老闆越來越生猛，左一刀右一刀全程下來差不多砍個半個時….程序員小王一直沒有還過手，因為小王知道他是老闆…

這個程序員小王只會在老闆第一次揮刀的時候，回老闆一刀，之後就不還手了，這個時候我們把程序員小王看做是靜態變量，把老闆第一次向小王揮刀看做是類加載，把小王回老闆一刀看出是分配內存空間，而一人一刀這個回合過程看成是類加載的過程，之後老闆的每一刀都看成是創建一次對象。

連貫起來就是static變量值在類第一次加載的時候分配空間，以後創建類對象的時候不會重新分配

之後這個老闆挨了一刀之後躺醫院了一年，一出院回到公司第一件事就是拉程序員宜春出來玩耍，老闆殊不知其然，這個博主程序員宜春性格異常暴躁，老闆遞給程序員宜春一把菜刀，博主宜春一接過菜刀，猝不及防的被老闆跳起來就是一刀，程序員宜春痛的嗷了一聲，暴躁的程序員宜春還沒嗷完，在嗷的同時跳起來就是給老闆一刀，接着老闆跳起來又是一刀，程序員宜春嗷的一聲又是回一刀，老闆跳起來又一刀，程序員宜春嗷的一聲又是回一刀，只要老闆沒停程序員宜春就沒停，因為程序員宜春知道，就自己這曝脾氣，暴躁起來si都敢摸，肯定有幾個老鐵知道….

程序員宜春就類似實例變量，每次創建對象，都會為每個對象分配成員變量內存空間，就像老闆來一刀，程序員宜春都會回一刀這樣子的…

6、訪問靜態變量和實例變量的兩種方式

我們都知道靜態變量是屬於這個類，而不是屬於是對象，static獨立於對象。

但是各位有木有想過：靜態成員變量雖然獨立於對象，但是不代表不可以通過對象去訪問，所有的靜態方法和靜態變量都可以通過對象訪問【只要訪問權限足夠允許就行】，不理解沒關係，來個代碼就理解了

public class StaticDemo {

        static int value = 666;

        public static void main(String[] args) throws Exception{
            new StaticDemo().method();
        }

        private void method(){
            int value = 123;
            System.out.println(this.value);
        }

}

猜想一下結果，我猜你的結果是123，哈哈是咩？其實

運行結果： 666

回過頭再去品味一下上面的那段話，你就能非常客觀明了了，這個思想概念要有隻是這種用法不推薦！

因此小結一下訪問靜態變量和實例變量的兩種方法：

靜態變量：

類名.靜態變量

對象.靜態變量(不推薦)

靜態方法：

類名.靜態方法

對象.靜態方法(不推薦)

7、static靜態方法

static修飾的方法也叫做靜態方法，不知道各位發現咩有，其實我們最熟悉的static靜態方法就是main方法了~小白童鞋：喔好像真的是哦~。由於對於靜態方法來說是不屬於任何實例對象的，this指的是當前對象，因為static靜態方法不屬於任何對象，所以就談不上this了。

還有一點就是：構造方法不是靜態方法！

8、static靜態代碼塊

先看個程序吧，看看自個是否掌握了static代碼塊，下面程序代碼繼承關係為 BaseThree——> BaseTwo——> BaseOne

BaseOne類

package com.gx.initializationblock;

public class BaseOne {

    public BaseOne() {
        System.out.println("BaseOne構造器");
    }

    {
        System.out.println("BaseOne初始化塊");
        System.out.println();
    }

    static {
        System.out.println("BaseOne靜態初始化塊");

    }

}

BaseTwo類

package com.gx.initializationblock;

public class BaseTwo extends BaseOne {
    public BaseTwo() {
        System.out.println("BaseTwo構造器");
    }

    {
        System.out.println("BaseTwo初始化塊");
    }

    static {
        System.out.println("BaseTwo靜態初始化塊");
    }
}

BaseThree 類

package com.gx.initializationblock;

public class BaseThree extends BaseTwo {
    public BaseThree() {
        System.out.println("BaseThree構造器");
    }

    {
        System.out.println("BaseThree初始化塊");
    }

    static {
        System.out.println("BaseThree靜態初始化塊");
    }
}

測試demo2類

package com.gx.initializationblock;

/*
     注：這裏的ABC對應BaseOne、BaseTwo、BaseThree 
 * 多個類的繼承中初始化塊、靜態初始化塊、構造器的執行順序
     在繼承中，先後執行父類A的靜態塊，父類B的靜態塊，最後子類的靜態塊，
     然後再執行父類A的非靜態塊和構造器，然後是B類的非靜態塊和構造器，最後執行子類的非靜態塊和構造器
 */
public class Demo2 {
    public static void main(String[] args) {
        BaseThree baseThree = new BaseThree();
        System.out.println("-----");
        BaseThree baseThree2 = new BaseThree();

    }
}

運行結果

BaseOne靜態初始化塊
BaseTwo靜態初始化塊
BaseThree靜態初始化塊
BaseOne初始化塊

BaseOne構造器
BaseTwo初始化塊
BaseTwo構造器
BaseThree初始化塊
BaseThree構造器
-----
BaseOne初始化塊

BaseOne構造器
BaseTwo初始化塊
BaseTwo構造器
BaseThree初始化塊
BaseThree構造器

至於static代碼塊運行結果不是很清晰的童鞋，詳細講解請看這篇

以上僅僅是讓各位明確代碼塊之間的運行順序，顯然還是不夠的，靜態代碼塊通常用來對靜態變量進行一些初始化操作，比如定義枚舉類，代碼如下：

public enum WeekDayEnum {
    MONDAY(1,"周一"),
    TUESDAY(2, "周二"),
    WEDNESDAY(3, "周三"),
    THURSDAY(4, "周四"),
    FRIDAY(5, "周五"),
    SATURDAY(6, "周六"),
    SUNDAY(7, "周日");
 
    private int code;
    private String desc;
 
    WeekDayEnum(int code, String desc) {
        this.code = code;
        this.desc = desc;
    }
 
    private static final Map<Integer, WeekDayEnum> WEEK_ENUM_MAP = new HashMap<Integer, WeekDayEnum>();
 
    // 對map進行初始化
    static {
        for (WeekDayEnum weekDay : WeekDayEnum.values()) {
            WEEK_ENUM_MAP.put(weekDay.getCode(), weekDay);
        }
    }
 
    public static WeekDayEnum findByCode(int code) {
        return WEEK_ENUM_MAP.get(code);
    }
 
    public int getCode() {
        return code;
    }
 
    public void setCode(int code) {
        this.code = code;
    }
 
    public String getDesc() {
        return desc;
    }
 
    public void setDesc(String desc) {
        this.desc = desc;
    }
}　

當然不僅僅是枚舉這一方面，還有我們熟悉的單例模式同樣也用到了靜態代碼塊，如下：

public class Singleton {
    private static Singleton instance;
 
    static {
        instance = new Singleton();
    }
 
    private Singleton() {}
 
    public static Singleton getInstance() {
        return instance;
    }
}

9、static變量與普通變量區別

static變量也稱作靜態變量，靜態變量和非靜態變量的區別是：靜態變量被所有的對象所共享，在內存中只有一個副本，它當且僅當在類初次加載時會被初始化。而非靜態變量是對象所擁有的，在創建對象的時候被初始化，存在多個副本，各個對象擁有的副本互不影響。

還有一點就是static成員變量的初始化順序按照定義的順序進行初始化。

10、靜態內部類

靜態內部類與非靜態內部類之間存在一個最大的區別，我們知道非靜態內部類在編譯完成之後會隱含地保存着一個引用，該引用是指向創建它的外圍內，但是靜態內部類卻沒有。沒有這個引用就意味着：

1、它的創建是不需要依賴外圍類的創建。
2、它不能使用任何外圍類的非static成員變量和方法。

代碼舉例（靜態內部類實現單例模式）

public class Singleton {
    
   // 聲明為 private 避免調用默認構造方法創建對象
    private Singleton() {
    }
    
   // 聲明為 private 表明靜態內部該類只能在該 Singleton 類中被訪問
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getUniqueInstance() {
        return SingletonHolder.INSTANCE;
    }
}

當 Singleton 類加載時，靜態內部類 SingletonHolder 沒有被加載進內存。只有當調用 getUniqueInstance()方法從而觸發 SingletonHolder.INSTANCE 時 SingletonHolder 才會被加載，此時初始化 INSTANCE 實例，並且 JVM 能確保 INSTANCE 只被實例化一次。

這種方式不僅具有延遲初始化的好處，而且由 JVM 提供了對線程安全的支持。

11、靜態導包

靜態導包格式：import static

這兩個關鍵字連用可以指定導入某個類中的指定靜態資源，並且不需要使用類名調用類中靜態成員，可以直接使用類中靜態成員變量和成員方法

//  Math. --- 將Math中的所有靜態資源導入，這時候可以直接使用裏面的靜態方法，而不用通過類名進行調用
//  如果只想導入單一某個靜態方法，只需要將換成對應的方法名即可
 
import static java.lang.Math.;
//  換成import static java.lang.Math.max;具有一樣的效果
 
public class Demo {
    public static void main(String[] args) {
 
        int max = max(1,2);
        System.out.println(max);
    }
}

靜態導包在書寫代碼的時候確實能省一點代碼，可以直接調用裏面的靜態成員，但是會影響代碼可讀性，所以開發中一般情況下不建議這麼使用。

12、static注意事項

1、靜態只能訪問靜態。
2、非靜態既可以訪問非靜態的，也可以訪問靜態的。

13、final與static的藕斷絲連

到這裏文章本該結束了的，但是static的使用始終離不開final字眼，二者可謂藕斷絲連，常常繁見，我覺得還是很有必要講講，那麼一起來看看下面這個程序吧。

package Demo;

class FinalDemo {
    public final double i = Math.random();
    public static double t = Math.random();
}

public class DemoDemo {
    public static void main(String[] args) {

        FinalDemo demo1 = new FinalDemo();
        FinalDemo demo2 = new FinalDemo();
        System.out.println("final修飾的  i=" + demo1.i);
        System.out.println("static修飾的 t=" + demo1.t);
        System.out.println("final修飾的  i=" + demo2.i);
        System.out.println("static修飾的 t=" + demo2.t);

        System.out.println("t+1= "+ ++demo2.t );
//      System.out.println( ++demo2.i );//編譯失敗
      }
}
運行結果：
    final修飾的  i=0.7282093281367935
    static修飾的 t=0.30720545678577604
    final修飾的  i=0.8106990945706758
    static修飾的 t=0.30720545678577604
    t+1= 1.307205456785776

static修飾的變量沒有發生變化是因為static作用於成員變量只是用來表示保存一份副本，其不會發生變化。怎麼理解這個副本呢？其實static修飾的在類加載的時候就加載完成了（初始化），而且只會加載一次也就是說初始化一次，所以不會發生變化！

至於final修飾的反而發生變化了？是不是巔覆你對final的看法？關於final詳細講解博主也準備好了一篇文章

ok,文章就先到這裏了，希望這篇文章能夠幫助到你對static的認識，若有不足或者不正之處，希望諒解並歡迎批評指正！

如果本文章對你有幫助，哪怕是一點點，那就請點一個讚唄，謝謝~

參考：
《java編程思想》

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

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

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

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

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

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

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

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

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

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

本人親身經歷，但後續的流程分析都是個人猜測的，畢竟沒有實際做過這塊的業務。

訂單物流阻塞經過

火熱的雙11剛剛退去，截止今日，我在京東購買的礦泉水終於到貨啦，下單兩箱還只收到了一箱 🙁 ，從下單到收到貨過去了14天，足足兩周的時間。

我從11-20號開始與京東客服聯繫，直到11-25整個購物體驗才完成，也因為京東沒有按照約定重新發貨，算是補償了我3000個京豆。

朋友們，不會不知道京豆是幹啥的吧，100個京豆相當於一塊錢，1000個京豆相當於10塊錢，3000個京豆就是30塊錢。

可那不是現金有啥卵用，你不會不在京東購物吧，下單的時候就可以選擇用京豆來抵用一部分下單金額了。

所以一般購買商品后鼓勵你去評價，文字超過一定字數且上傳了購買商品的圖片，就能得到比如20個京豆。京豆積少成多，就可以下單抵用現金了。

廢話不多說，回到正題！

雙11我在京東下單，自營商品的訂單一般都是次日達，因為雙11物流緊張，所以下單后提示11-13日送達。

11-13日：

遺憾的是，11-13日並沒有如期送達，查看訂單物流，增加了一段溫馨提示：「由於銷售火爆，根據目前情況，訂單預計11月16日送達到您的手中」，額~，當然大家都能理解，原來京東商品這麼「火爆」，畢竟雙十一累積銷量2000億呢。

11-20日 周三：

問題是到了11-16日並沒有送達，我把這個訂單差點忘記了，11-20號突然想起來了這件事，上京東確認了訂單，才發現還是那個「銷售火爆…」的提示呀！竟然沒有給我送貨。。。

然後在線聯繫人工客服，說了一下情況，客服態度很好，兩箱水拆分下單后因已經拆分為了兩個訂單，有兩個訂單號，為了表示歉意，每個訂單號補了500個京豆，1000個京豆到手了。

然後，客服跟我說，已經給我催促倉儲發貨了，讓耐心等待一下，預計第二天就能到了。

11-21號 周四：

可惜到了第二天，並沒有像客服MM所說的那樣如期送達，反正已經晚了，心想也不差這一天兒，還贈送了京豆，再等等了…… 。

11-22號 周五：

然而，到了11-22號還是沒有配送物流通知，訂單中的分揀流程沒有完成，這是什麼操作？？

當天繼續聯繫客服，問了是什麼原因，又來「話術」：小妹已為您催促正在發貨中，此時我有點懷疑了，可能這個流程本身就中斷了，需要人工來協助處理補單流程。

此刻，「客服的嘴，騙人的鬼」終於用到這了~

同時，京東客服升級來了個電話溝通，誠摯的表示歉意，說是倉儲這邊發貨有點問題，正在重新補貨中… ，預計明日就能送到，請注意查收！

11-23日 周六：

「客服的嘴，騙人的鬼」再一次用到這了~

周六仍然沒有收到貨，而且訂單里的物流配送流程一動也沒動~

11-23日 周日：

周日仍然沒有收到貨，而且訂單里的物流配送流程一動也沒動~

看來沒很好的注重用戶體驗嘛，再次在線聯繫客服，每次接線的不是同一個客服，所以每次都要求提供一下訂單號，很煩，此時很無語了，本用戶表示很生氣啊，自己查！

然後呢，客服又說已經重新補發貨了，並且這次竟然不給我大概的送貨時間點了，因為他不相信到底有沒有真的去補發貨操作了，補發貨這個操作多半客服是沒有權限的。

另外，解釋到因訂單延遲時間過長，又一次非常的抱歉，給申請了1000京豆，不過這次京豆並不是實時到賬的，需要經過審核流程。

11-25日 周一：

早上已經在地鐵上了，收到了京東快遞小哥的來電，但是只到了一個訂單的貨。查了一下另外一個訂單物流狀態仍然一動沒動 :(。

最後，客服專員再次電話聯繫，解釋到這個訂單給疏忽了，建議我重新下單，然後這個訂單走退款流程。並且再一次給予了1000京豆的補償 :)。

物流系統異常分析：

上述物流配送異常流程中，想了解故障原因，電話中我也有意識的去問一下客服，是不是某個環節有這樣的問題，但是從客服那裡只能給到說倉配流程有問題 ，具體他們也不是很清楚了，全都是針對用戶的話術，避免說錯話。

作為個技術人，通常得思考一下問題背後的原因：

• 到底是哪個環節出現的問題
• 出現這樣問題的原因
• 對用戶的影響及應對方案
• 如何能避免類似的問題發生
• …

物流系統介紹

由此次問題引出，我還特意去查資料看了一下京東物流的系統架構演進過程。記得當時京東物流招人非常猛，作為一個內部非常重量級的項目投入了很多研發人力。

在2012年的時候京東內部開始對物流系統進行設計改造，那時訪問量應該還不算高，最初的系統還沒那麼複雜。新改造的物流系統：「青龍系統」

青龍系統演進過程如上圖所示 ，它的系統發展至今，已經包含了分揀中心，運輸路由，終端，對外拓展，運營支持等五十餘個核心子系統，構建了完善的電商物流體系。

並且青龍系統中總結了一些最佳的實戰原則，如下所示：

這些系統設計原則我認為對任何系統都是通用的，值得我們一起學習的:

• 高可用

選擇合適的架構方案；大系統小做，服務拆分；併發控制，服務隔離；灰度發布；全方位監控報警；核心服務，平滑降級。

• 高性能

緩存和異步化，同步接口異步化設計；接口數據緩存化。

接口數據緩存化是非常重要的手段，對Redis緩存系統的很好的利用，構建了具有自己特色的緩存體系，很好的支撐了業務發展。同時，還發展了基於Redis的分佈式調度系統

• 數據一致性

高實時性/高一致性，高實時性/低一致性，低實時性/高一致性，低實時性/低一致性。

針對具體的業務，可以匹配到具體的數據場景，找到對應的解決方案。要客觀的結合業務分析，選擇最適合的一致性方案，並不是高實時性/高一致性就好，成本是很更貴的。

• 用戶體驗

東哥要求過任何人不能對用戶體驗提升的建議說No。用戶體驗主要遵循MVP原則和動態運營的原則。

MVP原則：也就是敏捷開發中的迭代思路。即快速迭代，核心需求線上，及時的反饋和改進。

動態運營：跟MVP原則強關聯，上線后收集並分析用戶數據，使得產品落地的設計符合用戶的需求，不符合設計要求的就要不斷的持續調整，是一個動態持續的過程。

物流分揀系統

簡單介紹完了物流系統的演進過程及架構原則，還是回到主題，到底是哪個環節出現了問題？

需要了解整個購物鏈路的各個環節：

用戶整個購物流程經過以上幾個關鍵的流程，已經生成訂單號並且已經支付了，流程到了訂單中心。

各個系統都是分佈式部署的，訂單中心會發送一個MQ消息給各個下游系統，積分系統增加積分京豆等，促銷系統發放優惠券等，倉儲系統接收到MQ消息進行處理，調用物流系統生成物流單，通知到配送站，由配送員送貨。

結合一個火爆的訂單，看一下訂單跟蹤過程：

該訂單在倉庫處理中已經打包完成，訂單在京東【北京李橋接貨倉庫】分揀完成。注意到了「分揀」二字，順便看了一下正常的訂單流程，會經過多個貨倉的分揀過程，最終會分揀到離用戶最近的貨倉。

所以，猜測，這筆訂單的問題就是在配送前的分揀系統處理過程中出現了異常情況。

青龍物流系統其中就包括了預分揀流程，如下所示：

當用戶下單后，首先必須是經過預分揀環節，但是根據最新的訂單跟蹤過程看，是先進行了倉庫打包處理，然後進入分揀流程。

分揀系統接收到訂單，根據不同的訂單進行規則匹配，分配站點，處理成功後生產包裹打印標籤。

訂單無法被正常分揀完成，將無法生成訂單：

想必我的訂單大概率就是在分揀環節出現了問題 ~

分揀系統的目標：

其中可用性要求是達到99.99%，4個9的可用率呢，看來很不幸啊，不可用的0.01%小概率事件偶發在了我的訂單上。

預分揀算法：

1、經驗值

只適用於同一個地址多次購買，依賴於第一妥投地址。

2、特徵值

需要提前人工維護關鍵字，依賴於關鍵字的準確性。

3、特殊配置

需要提前人工配置，依賴於該區域是否有特殊配置。

4、GIS

通過GIS技術精準的匹配地理位置。

上述都沒有匹配到，那麼只能走人工處理流程了。

預分揀系統架構：

訂單系統下發服務，默認會進入到預分揀系統，不同的訂單有不同的匹配規則，匹配規則使用開源的Drools來實現的，規則匹配完成，會按照預分揀算法匹配，優先匹配到離用戶最近的地址，返回自動預分揀的結果。

一旦回傳失敗，應該會有預警，需要人工介入來協助完成預分揀，將結果返回給訂單服務。

預分揀服務系統交互流程：

分揀服務使用Tomcat分佈式部署的Worker進程，完成后，將結果寫入到任務庫，回傳服務從人物庫抓取分揀結果回傳站點。

下圖來源於網絡，不是很清晰了：

其中預分揀服務接受訂單服務都是分佈式部署的，並且針對不同的訂單做了服務隔離，使用應用服務器是Tomcat；全文檢索使用的Solr，可能目前已改進為流行的ElasticSerach架構了；分佈式緩存使用了Redis集群；預分揀算法中的地址庫、特徵值、配置都對應了自己的Worker集群，也是做了服務隔離，每個服務分佈式部署，最終將結果寫入到MySQL數據庫中；預分揀回傳站點單獨的Worker集群，用來從數據庫抓取分揀數據，返回給用戶站點。

小結

經過以上過程猜測性分析，基本就清楚了自己的訂單問題出現的位置了。

大概率就是預分揀服務在某一個站點因為流量洪峰或異常出現了故障，可能服務恢復后沒有及時完成自動分揀數據校對。

與客服的溝通結果來看，當分揀過程出現問題后，可能並沒有及時預警並人工及時的去干預處理，導致分揀流程被阻塞，遲遲無法進入到分揀恢復階段。或許也是考慮到這種小概率事件，就由用戶來直接反饋，然後由人工介入處理。

但是，很明顯，客服用話術告知用戶結果，讓用戶耐心等待的同時。在後續的分揀系統訂單恢複流程並不是那麼順暢的，不一定是那麼簡單的人工直接快速處理，會經過一些校驗核對、人工審核等一系列流程，又或者讓技術人員協助恢復的，導致分揀流程流轉下去很慢，也進而影響了用戶體驗。

在線話術告知用戶結果算是A方案。

人工處理的第一筆訂單跟蹤：

而第二個訂單，客服根據情況執行了B方案，將問題升級到專員，電話聯繫用戶，建議用戶重新下單，並給予一定的補償。當你重新下單，分揀系統接收到新的訂單，就是進入了自動預分揀訂單處理過程了，自動化流程當然是很快的，無需人工干預。

總體來說，京東客服的做法可圈可點，整體售後服務流程較以前值得肯定，越來越完善。

同時，系統架構在未來方向上，肯定更趨向於更加的智能化，使用機器學習、人工智能等手段持續不斷優化物流的各環節，減少或避免小概率的事件發生。

ps：文章前半段真實發生，後半段僅作為問題分析參考。

歡迎關注我的公眾號，掃二維碼關注獲得更多精彩文章，與你一同成長~

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

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

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

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

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

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

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