前言： 不知不覺已經工作了快 7 個月了，去年這個時候還躋身在考研的大軍中，不禁有些感慨… 結合這 7 個月發生的一些事情，簡單做一下總結吧…

為獲得更好的閱讀體驗，請訪問原文地址：

一、那時候剛入職

不同於其他同學忙於畢設的 4 月，提早安排趁寒假已經完成畢設的我，已經開始撲在了「找工作」這件事上，有了去年「秋招」打下的基礎，複習起來快了很多，沒過多久就開始投簡歷面試了，面試也總體比較順利，剛面沒幾家就迅速和一家自己看好的初創公司簽下了。

公司使用的技術棧區別於自己熟悉的 Java/ MySQL 這一套，而是主要使用的 Rails/ MongoDB，所以剛入職的一段時間，基本上都是在自己熟悉技術棧，也趁着閑暇的時間，把自己入門時候的一些學習心得寫成了文章發表：

• MongoDB【快速入門】：
• Java轉Ruby【快速入門】：

對於職場小白來說，所謂「職場」還是顯得有些陌生，剛來的時候，雖然跟周圍的同事都稀鬆平常地打了一圈兒招呼，坐下之後，隨着他們又埋頭噼里啪啦敲打鍵盤工作的深入，又頓覺周圍一片陌生，還挺奇妙的，在第一周完的周報裏面我寫道：

剛來公司有些迷茫，只是看着CheckList對照着熟悉一些技術，也不了解自己應該要熟悉到哪種程度，就希望自己能再主動些，不管是技術問題還是其他問題多請教，然後儘快跟其他成員熟悉起來。

剛開始上手的時候也有好多問題不懂，我都習慣性的選擇自己研究一陣兒，因為自己有寫博客的一些經歷，被問過好多一搜索 or 自己一嘗試就能解決的問題，所以比較克制，但是後來「入職 1v1」溝通的時候被說到有問題別自己死磕，半個小時沒解決盡量就找一下旁邊的同事。摁？我一下子就把我的「主動性」發揮了出來。

不過好記性也不如爛筆頭，找了一些工具記錄把這些「問題的答案」都記錄了下來，方便之後再查找，當時對於 Git 都不是很熟悉，也記錄了很多常用的命令在裏面，還有一些問題的反饋，甚至知道了月會要自我介紹，也打了一遍草稿記錄在了這裏：（那段時間真的問了好多問題，周報里也手動感謝了坐我旁邊的兩位大佬..）

入職兩周的時候，雖然已經開始上手做一些簡單的埋點工作，但自己對於 Ruby 還是不是特別了解和熟悉，趁着某一個雙休，抓着一本《Effetive-Ruby》啃了两天，也把自己的學習輸出了一下：

• 《Effective-Ruby》讀書筆記：

二、逐漸能夠上手

就這樣一邊熟悉，一邊開始接一些小需求，我記得我寫下的第一個 BUG，就報出了 6K 條記錄.. 慌慌張張在修復之後我不禁感嘆：「不要太相信用戶的任何數據」。（包括 equal 反寫也是之後在錯誤之中學習到的..）

剛上手沒有一段時間，就接到了一個新項目的需求，跟着一位大佬開發一個新功能，大佬負責搭建基礎代碼和設計，我負責完成其餘的功能代碼，沒敢一絲懈怠，下班回家之後也對照着別人寫的代碼敲敲敲，時間和完成度上倒是沒有一絲耽擱，只是現在回過頭一想，當時沒有什麼單元測試的概念和意識，就自己在本地 Post-Man 測試完就完，所幸比較簡單 + 自己測試得比較仔細，到現在也沒有出現過什麼問題。

工作對我這樣的小白另一個好處就是：「見識和增加技術的廣度」。公司所使用技術棧不論是廣度還是深度，都是自己在大學本科的學習中不可企及的程度，Jekins？Docker？K8S？跳板機？一下子冒出來好多新鮮陌生的名詞，懷着好奇心也嘗試了解了一些：

• 了解【Docker】從這裏開始：
• 「消息隊列」看過來！：
• Kafka【入門】就這一篇！：

也隨着公司的逐漸壯大，各模塊的耦合也越發嚴重，各條業務線之間的協作溝通成本越來越大，逐漸開始提出「微服務」這樣的概念，具體怎麼樣理解就不作討論了，總之就是期望通過梳理/ 重構/ 拆服務的方式來解決「協作」問題，所以期間也開始了解學習一些這方面的東西：

• 什麼是微服務？：
• 《重構：改善既有代碼的設計》讀書筆記：

甚至期間還做了一些「微服務」的調研，我們選用什麼樣的姿勢和技術棧更加合適，所以也輸出了一些關於「Spring Cloud」的東西，但是最終駁回的原因是待我們整個容器化之後 k8s 平台自帶了這麼一套東西，業務同學只需要關心業務代碼就行了，也就沒有繼續深入了：

• 你想了解的「Spring Cloud」都在這裏：

然後我們在拆解的過程中，也借鑒到一些「DDD」的思想，也嘗試進行了一波學習：

• 【吐血推薦】領域驅動設計學習輸出：

總之，這一段時間我一邊通過各種小需求，接觸和了解了公司的系統的大半，一邊學習和了解着各種不同的技術，增加了技術上的廣度。

三、開始負責一些項目

為了加速服務化的推進工作和驗證「DDD」的一些東西，部門老大把一個邊界足夠清晰，也足夠小的一個模塊單獨交給我，期望我快速上線，不過最終交付已經逾期快大半個月了.. 雖然從最終的結果來看，順利交付完成了拆解任務並從 MongoDB 數據庫轉變成了 MySQL.. 但期間也踩過好些坑，當然也學習到一些東西..

例如我真實地意識到「完美」這個詞的理想化。就拿設計 API 來說吧.. 自己就基於 RESTful 風格設計了好幾版.. 左想右想都覺得差一些，有一些接口覺得怎麼設計都不優雅.. 後來糾結一陣子也就放棄了.. 再例如寫代碼這件事情吧，好的代碼整潔的代碼是一次一次迭代和重構中出來的，如果一開始就想着寫出「完美」的代碼，那麼最終的結果可能就是寫不出來代碼。

另外一個小插曲是，在做數據遷移的時候，我差點把線上服務器搞掛了.. 我在測試環境驗證了一把之後，就直接在線上進行操作了，因為當時對於數據庫的操作管控還沒有那麼嚴格，加上自己對於線上環境的複雜程度認識不足，我就起了 50 個線程，去分批量地讀取 MongoDB 的數據遷移到 MySQL，造成了線上庫的性能報警，就趕緊停了.. 緊接着就被一群大佬抓進了一個會議室做事件的復盤..

說實話，我緊張壞了，第一次經歷這樣的算是「事故」的情況吧，差一點線上就被我搞掛啦，一時間不知所措… 讓人感到溫暖的是部門老大隨即丟來的消息：

那天還有一些相關的同事都陪我寫復盤郵件到了晚上 10：30，現在想來都十分感謝他們。後來回到家我還打電話給我媽，我說我在工作中犯錯了，我做了xxxx這些動作，你覺得我做的怎麼樣呢，老媽的回復也讓人安心，只是現在想來，一些後續的動作可以做得更好的…

因為「埋點」這件事涉及到系統的方方面面，我也藉此了解了很多不同的模塊，也是拜這一點所賜吧，後來我被派到各種各樣的支援任務中，同樣也因為對不同模塊都還不算陌生，都還算完成得不錯吧…

時間一晃，在公司就四個月過去了，也在這個過程中從各個大佬那兒都學到了一些東西，在 8 月底發的周報裏面我寫下了以下的總結：

之後也跟着大佬碰了一些公司的核心模塊，期間也沒有停止在工作中不斷地做學習輸出：

• Git 原理入門解析：
• Java計時新姿勢√：
• Java8流操作-基本使用&性能測試：
• 《代碼整潔之道》讀書筆記：
• React 入門學習：
• 談一談依賴倒置原則：

四、回顧做的不好的部分

• 對代碼還沒有保持足夠的敬畏之心。

特別是一開始上手的時候，有時候甚至是在線上環境搞測試，後來越來越注重 codereview 和單元測試好了很多。

• 溝通還不夠深入/ 到位

有一次是臨時接到一個需求，因為「通用語言」沒有達成一致，導致最終交付的結果不符合產品的期望，最終我們所有相關人員在一起開了一個會，統一了「通用語言」，造成了額外的工作和負擔，拿到需求就應該確認好相關事宜的，越底層越細節越好，這方面的能力我仍然欠缺，但我已經持續在注意當中。

另一次也是因為這一點，我需要幫助 A 系統擁有某一項功能，之前 A 系統已經介入了 B 系統完成了部分功能，我因為沒有進一步地確認 B 系統的現狀，就去接入了有完整功能的 C 系統，但其實 B 系統已經在上一周和開發 C 系統和 A 系統的同學對接好了，並完成了相關功能的接入，少了這一部分的溝通，就造成了不少額外的工作量.. 所以「溝通」還是非常重要的，也只能說持續進步吧…

• 缺少一些主動性

當我頭上掛着一些事情的時候，還是能夠保持着效率的，只是當我做完了，就時常缺乏一些主動地思考了，通常都是被動地去詢問同小組的同事有什麼事情是需要幫忙的.. 雖然也积極地參与到自己感興趣的那些技術評審之類的事情之中，但似乎效果都不佳.. 也沒有什麼實際好的輸出..

• 接了一些私活兒黑活兒（沒有充分考慮團隊之間的配合）

因為「埋點」會接觸各個平台的童鞋，並且時常變化和有一些新的需求，有時候直接繞過了一些環節，直接找上我了，我心想直接自己弄弄改改就可以了，也就沒多想… 但是現在想來，這樣跨團隊的事情，不能越過「頂頭上司」私自進行，一方面經常我的 BOSS 不知道我接了活兒，另一方面這樣的私自對接就會造成一些信息的流失，對於團隊之內還是團隊之間都會造成影響…

五、回顧做得好的部分

• 養成了閱讀的習慣

公司買書是免費的，也有自己的圖書館，同事也不乏喜歡閱讀學習的，所以跟着跟着就養成了閱讀的習慣，期間也學習到了一些方法論的東西，貼一下入職以來讀過的那些書吧：（技術類的就沒有囊括了）

其實每天閱讀的時間也不長，想我大學總共捧起的那麼些課外書，不禁有些唏噓…

• 早睡早起 + 晨間日記

早睡早起，從步入職場以來，就發現這樣的習慣會帶來一些額外的價值，例如一些閱讀我會放在早上，後來還加入了「晨間日記」，用來「回顧前一天的事情」和提前部署「今天的任務」，這不禁讓我多了一份清醒，也讓現在不怎麼鍛煉的我每一天精力更加好一些：（目前正在從印象筆記往 Notion 逐步遷移的過程中）

• 學習撰寫 Commit Message && 遵守一些 Git 規範

起初使用 Git 十分不規範，後來向大佬那兒學習到了如何標準地提交 Commit，包括 Commit Message 應該怎麼寫，我覺得這是一個很好的習慣，每一個 Commit 都有上下文，並且還帶上了 JIRA 號，任務也很好跟蹤，雖然公司並沒有大範圍地盛行起來，但我覺得這樣好習慣應該堅持下來：

• 任務進度及時反饋給相關人員

自己比較注意這一點，因為不這樣做會讓別人感受不怎麼好.. 光是自己心裏清楚是不行的.. 要保持信息的通暢才行，及時反饋是很重要的一步..

• 自己先 review 一遍代碼

犯過一些白痴錯誤之後，就有些擔心，逐步養成了自己先 review 一遍代碼的習慣..

六、小結 && 展望

總的來說，看着自己這樣一步一步成長過來，沒有很懈怠，自己就算比較滿意了，在工作中學習了很多東西，不管是技術上的硬技能，還是溝通中的軟技能，也認識到了很多厲害的大佬和有趣的小夥伴們..

感恩在路上相遇，有幸共同行走過一段已然算是幸運，突然翻看起自己的朋友圈有一句話說得好：「成長從來都不是告別過去，成長是更加堅定的看向未來！」

期待一路同行的大家，都能夠 Be Better！

按照慣例黏一個尾巴：

歡迎轉載，轉載請註明出處！
獨立域名博客：wmyskxz.com
簡書ID：
github：
歡迎關注公眾微信號：wmyskxz
分享自己的學習 & 學習資料 & 生活
想要交流的朋友也可以加qq群：3382693
錢

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

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

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

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

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

開篇明意

　　ThreadLocal是JDK包提供的線程本地變量，如果創建了ThreadLocal<T>變量，那麼訪問這個變量的每個線程都會有這個變量的一個副本，在實際多線程操作的時候，操作的是自己本地內存中的變量，從而規避了線程安全問題。

　　ThreadLocal很容易讓人望文生義，想當然地認為是一個“本地線程”。其實，ThreadLocal並不是一個Thread，而是Thread的一個局部變量，也許把它命名ThreadLocalVariable更容易讓人理解一些。

　　來看看官方的定義：這個類提供線程局部變量。這些變量與正常的變量不同，每個線程訪問一個(通過它的get或set方法)都有它自己的、獨立初始化的變量副本。ThreadLocal實例通常是類中的私有靜態字段，希望將狀態與線程關聯(例如，用戶ID或事務ID)。

源碼解析

　　1.核心方法之   set(T t)

 1     /**
 2      * Sets the current thread's copy of this thread-local variable
 3      * to the specified value.  Most subclasses will have no need to
 4      * override this method, relying solely on the {@link #initialValue}
 5      * method to set the values of thread-locals.
 6      *
 7      * @param value the value to be stored in the current thread's copy of
 8      *        this thread-local.
 9      */
10     public void set(T value) {
11         Thread t = Thread.currentThread();
12         ThreadLocalMap map = getMap(t);
13         if (map != null)
14             map.set(this, value);
15         else
16             createMap(t, value);
17     }

解析：

　　當調用ThreadLocal的set(T t)的時候，代碼首先會獲取當前線程的 ThreadLocalMap（ThreadLocal中的靜態內部類，同時也作為Thread的成員變量存在，後面會進一步了解ThreadLocalMap），如果ThreadLocalMap存在，將ThreadLocal作為map的key，要保存的值作為value來put進map中（如果map不存在就先創建map，然後再進行put）；

　　2.核心方法值 get()

/**
     * Returns the value in the current thread's copy of this
     * thread-local variable.  If the variable has no value for the
     * current thread, it is first initialized to the value returned
     * by an invocation of the {@link #initialValue} method.
     *
     * @return the current thread's value of this thread-local
     */
    public T get() {
       Thread t = Thread.currentThread();
       ThreadLocalMap map = getMap(t);        //此處和set方法一致，也是通過當前線程獲取對應的成員變量ThreadLocalMap，map中存放的是Entry(ThreadLocalMap的內部類（繼承了弱引用）)
　　　　if (map != null) {
　　　　　　ThreadLocalMap.Entry e = map.getEntry(this);
　　　　　　if (e != null) { 
　　　　　　　 @SuppressWarnings("unchecked")
　　　　　　 　T result = (T)e.value; 
　　　　　　　　return result;
　　　　　　}
　　　　} 
　　　 return setInitialValue(); 
    }

解析：

　　剛才把對象放到set到map中，現在根據key將其取出來，值得注意的是這裏的map裏面存的可不是鍵值對，而是繼承了WeakReference<ThreadLocal<?>> 的Entry對象，關於ThreadLocalMap.Entry類，後面會有更加詳盡的講述。

核心方法之  remove()

    /**
     * Removes the current thread's value for this thread-local
     * variable.  If this thread-local variable is subsequently
     * {@linkplain #get read} by the current thread, its value will be
     * reinitialized by invoking its {@link #initialValue} method,
     * unless its value is {@linkplain #set set} by the current thread
     * in the interim.  This may result in multiple invocations of the
     * {@code initialValue} method in the current thread.
     *
     * @since 1.5
     */
     public void remove() {
         ThreadLocalMap m = getMap(Thread.currentThread());
         if (m != null)
             m.remove(this);
     }

解析：

　　通過getMap方法獲取Thread中的成員變量ThreadLocalMap，在map中移除對應的ThreadLocal，由於ThreadLocal（key）是一種弱引用，弱引用中key為空，gc會回收變量value，看一下核心的m.remove(this);方法

        /**
         * Remove the entry for key.
         */
        private void remove(ThreadLocal<?> key) {
            Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1); //定義Entry在數組中的標號 for (Entry e = tab[i];              //通過循環的方式remove掉Thread中所有的Entry
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {   
                if (e.get() == key) {
                    e.clear();
                    expungeStaleEntry(i);
                    return;
                }
            }
        } 

靈魂提問

　　問：threadlocal是做什麼用的，用在哪些場景當中？　　

　　　　結合官方對ThreadLocal類的定義，threadLocal主要滿足某些變量或者示例是線程隔離的，但是在相同線程的多個類或者方法中都能使用的到，並且當線程結束時該變量也應該銷毀。通俗點講：ThreadLocal保證每個線程有自己的數據副本，當線程結束后可　　以獨立回收。由於ThreadLocal的特性，同一線程在某地方進行設置，在隨後的任意地方都可以獲取到。從而可以用來保存線程上下文信息。常用的比如每個請求怎麼把一串後續關聯起來，就可以用ThreadLocal進行set，在後續的任意需要記錄日誌的方法裏面進行get獲取到請求id，從而把整個請求串起來。 　　　　使用場景有很多，比如：

• 基於用戶請求線程的數據隔離（每次請求都綁定userId，userId的值存在於ThreadLoca中）
• 跟蹤一個請求，從接收請求，處理到返回的整個流程，有沒有好的辦法   思考：微服務中的鏈路追蹤是否利用了ThreadLocal特性
• 數據庫的讀寫分離
• 還有比如Spring的事務管理，用ThreadLocal存儲Connection，從而各個DAO可以獲取同一Connection，可以進行事務回滾，提交等操作。

  　　
問：如果我啟動另外一個線程。那麼在主線程設置的Threadlocal值能被子線程拿到嗎? 　　　　原始的ThreadLocal是不具有繼承(或者說傳遞)特性的   　　
問：那該如何解決ThreadLocal無法傳遞的問題呢？ 　　　　用ThreadLocal的子類 InheritableThreadLocal，InheritableThreadLocal是具有傳遞性的

　　/**
　　* 重寫Threadlocal類中的getMap方法，在原Threadlocal中是返回
　　* t.theadLocals，而在這麼卻是返回了inheritableThreadLocals，因為
　　* Thread類中也有一個要保存父子傳遞的變量
　　*/
    ThreadLocalMap getMap(Thread t) {
       return t.inheritableThreadLocals;
    }

    /**  * 同理，在創建ThreadLocalMap的時候不是給t.threadlocal賦值  *而是給inheritableThreadLocals變量賦值  *  */

    void createMap(Thread t, T firstValue) {
        t.inheritableThreadLocals = new ThreadLocalMap(this, firstValue);
    }

解析：因為InheritableThreadLocal重寫了ThreadLocal中的getMap 和createMap方法，這兩個方法維護的是Thread中的另外一個成員變量  inheritableThreadLocals，線程在創建的時候回複製inheritableThreadLocals中的值 ；

/* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
　　//Thread類中維護的成員變量,ThreadLocal會維護該變量

    ThreadLocal.ThreadLocalMap threadLocals = null;

    /*
     * InheritableThreadLocal values pertaining to this thread. This map is
     * maintained by the InheritableThreadLocal class.
     */
//Thread中維護的成員變量 ，InheritableThreadLocal 中維護該變量

ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;

//Thread init方法中的關鍵代碼，簡單來說是將父類中inheritableThreadLocals中的值拷貝到當前線程的inheritableThreadLocals中（淺拷貝，拷貝的是value的地址引用）

 if (inheritThreadLocals && parent.inheritableThreadLocals != null) this.inheritableThreadLocals = ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);

總結

• ThreadLocal類封裝了getMap()、Set()、Get()、Remove()4個核心方法。
• 通過getMap()獲取每個子線程Thread持有自己的ThreadLocalMap實例, 因此它們是不存在併發競爭的。可以理解為每個線程有自己的變量副本。
• ThreadLocalMap中Entry[]數組存儲數據，初始化長度16，後續每次都是1.5倍擴容。主線程中定義了幾個ThreadLocal變量，Entry[]才有幾個key。
• Entry的key是對ThreadLocal的弱引用，當拋棄掉ThreadLocal對象時，垃圾收集器會忽略這個key的引用而清理掉ThreadLocal對象， 防止了內存泄漏。

　　　　tips：上面四個總結來源於其他技術博客，個人認為總結的比較合理所以直接摘抄過來了

拓展：

　　ThreadLocal在線程池中使用容易發生的問題： 內存泄漏，先看下圖

　　每個thread中都存在一個map, map的類型是ThreadLocal.ThreadLocalMap. Map中的key為一個threadlocal實例. 這個Map的確使用了弱引用,不過弱引用只是針對key. 每個key都弱引用指向threadlocal. 當把threadlocal實例置為null以後,沒有任何強引用指向threadlocal實例,所以threadlocal將會被gc回收. 但是,我們的value卻不能回收,因為存在一條從current thread連接過來的強引用. 只有當前thread結束以後, current thread就不會存在棧中,強引用斷開, Current Thread, Map, value將全部被GC回收.

　　所以得出一個結論就是只要這個線程對象被gc回收，就不會出現內存泄露，但在threadLocal設為null和線程結束這段時間不會被回收的，就發生了我們認為的內存泄露。其實這是一個對概念理解的不一致，也沒什麼好爭論的。最要命的是線程對象不被回收的情況，這就發生了真正意義上的內存泄露。比如使用線程池的時候，線程結束是不會銷毀的，會再次使用的。就可能出現內存泄露。　　

　　PS.Java為了最小化減少內存泄露的可能性和影響，在ThreadLocal的get,set的時候都會清除線程Map里所有key為null的value。所以最怕的情況就是，threadLocal對象設null了，開始發生“內存泄露”，然後使用線程池，這個線程結束，線程放回線程池中不銷毀，這個線程一直不被使用，或者分配使用了又不再調用get,set方法，那麼這個期間就會發生真正的內存泄露。 

1. JVM利用設置ThreadLocalMap的Key為弱引用，來避免內存泄露。
2. JVM利用調用remove、get、set方法的時候，回收弱引用。
3. 當ThreadLocal存儲很多Key為null的Entry的時候，而不再去調用remove、get、set方法，那麼將導致內存泄漏。
4. 當使用static ThreadLocal的時候，延長ThreadLocal的生命周期，那也可能導致內存泄漏。因為，static變量在類未加載的時候，它就已經加載，當線程結束的時候，static變量不一定會回收。那麼，比起普通成員變量使用的時候才加載，static的生命周期加長將更容易導致內存泄漏危機。

　　參考鏈接：

在線程池中使用ThreadLocal

通過上面的分析可以知道InheritableThreadLocal是通過Thread()的inint方法實現父子之間的傳遞的，但是線程池是統一創建線程並實現復用的，這樣就好導致下面的問題發生：

• 　　線程不會銷毀，ThreadLocal也不會被銷毀，這樣會導致ThreadLoca會隨着Thread的復用而復用
• 　　子線程無法通過InheritableThreadLocal實現傳遞性（因為沒有單獨的調用Thread的Init方法進行map的複製），子線程中get到的是null或者是其他線程復用的錯亂值（疑問點還沒搞清楚原因，後續補充：:在異步線程中會出現null的情況，同步線程不會出現）     

　　　　ps:線程池中的線程是什麼時候創建的？

　　解決方案：

　　　　下面兩個鏈接有詳細的說明，我就不重複寫了，後續我會將本文進一般優化並添加一些例子來幫助說明，歡迎收藏，關於本文有不同的意見歡迎評論指正……

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

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

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

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

本文為 SnailClimb 的原創，目前已經收錄自我開源的 中（61.5 k Star!【Java學習+面試指南】 一份涵蓋大部分Java程序員所需要掌握的核心知識。歡迎 Star!）。

另外推薦一篇原創：

Java 併發基礎常見面試題總結

1. 什麼是線程和進程?

1.1. 何為進程?

進程是程序的一次執行過程，是系統運行程序的基本單位，因此進程是動態的。系統運行一個程序即是一個進程從創建，運行到消亡的過程。

在 Java 中，當我們啟動 main 函數時其實就是啟動了一個 JVM 的進程，而 main 函數所在的線程就是這個進程中的一個線程，也稱主線程。

如下圖所示，在 windows 中通過查看任務管理器的方式，我們就可以清楚看到 window 當前運行的進程（.exe 文件的運行）。

1.2. 何為線程?

線程與進程相似，但線程是一個比進程更小的執行單位。一個進程在其執行的過程中可以產生多個線程。與進程不同的是同類的多個線程共享進程的堆和方法區資源，但每個線程有自己的程序計數器、虛擬機棧和本地方法棧，所以系統在產生一個線程，或是在各個線程之間作切換工作時，負擔要比進程小得多，也正因為如此，線程也被稱為輕量級進程。

Java 程序天生就是多線程程序，我們可以通過 JMX 來看一下一個普通的 Java 程序有哪些線程，代碼如下。

public class MultiThread {
    public static void main(String[] args) {
        // 獲取 Java 線程管理 MXBean
    ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
        // 不需要獲取同步的 monitor 和 synchronizer 信息，僅獲取線程和線程堆棧信息
        ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false);
        // 遍歷線程信息，僅打印線程 ID 和線程名稱信息
        for (ThreadInfo threadInfo : threadInfos) {
            System.out.println("[" + threadInfo.getThreadId() + "] " + threadInfo.getThreadName());
        }
    }
}

上述程序輸出如下（輸出內容可能不同，不用太糾結下面每個線程的作用，只用知道 main 線程執行 main 方法即可）：

[5] Attach Listener //添加事件
[4] Signal Dispatcher // 分發處理給 JVM 信號的線程
[3] Finalizer //調用對象 finalize 方法的線程
[2] Reference Handler //清除 reference 線程
[1] main //main 線程,程序入口

從上面的輸出內容可以看出：一個 Java 程序的運行是 main 線程和多個其他線程同時運行。

2. 請簡要描述線程與進程的關係,區別及優缺點？

從 JVM 角度說進程和線程之間的關係

2.1. 圖解進程和線程的關係

下圖是 Java 內存區域，通過下圖我們從 JVM 的角度來說一下線程和進程之間的關係。如果你對 Java 內存區域 (運行時數據區) 這部分知識不太了解的話可以閱讀一下這篇文章：

從上圖可以看出：一個進程中可以有多個線程，多個線程共享進程的堆和方法區 (JDK1.8 之後的元空間)資源，但是每個線程有自己的程序計數器、虛擬機棧 和 本地方法棧。

總結： 線程 是 進程 劃分成的更小的運行單位。線程和進程最大的不同在於基本上各進程是獨立的，而各線程則不一定，因為同一進程中的線程極有可能會相互影響。線程執行開銷小，但不利於資源的管理和保護；而進程正相反

下面是該知識點的擴展內容！

下面來思考這樣一個問題：為什麼程序計數器、虛擬機棧和本地方法棧是線程私有的呢？為什麼堆和方法區是線程共享的呢？

2.2. 程序計數器為什麼是私有的?

程序計數器主要有下面兩個作用：

1. 字節碼解釋器通過改變程序計數器來依次讀取指令，從而實現代碼的流程控制，如：順序執行、選擇、循環、異常處理。
2. 在多線程的情況下，程序計數器用於記錄當前線程執行的位置，從而當線程被切換回來的時候能夠知道該線程上次運行到哪兒了。

需要注意的是，如果執行的是 native 方法，那麼程序計數器記錄的是 undefined 地址，只有執行的是 Java 代碼時程序計數器記錄的才是下一條指令的地址。

所以，程序計數器私有主要是為了線程切換后能恢復到正確的執行位置。

2.3. 虛擬機棧和本地方法棧為什麼是私有的?

• 虛擬機棧： 每個 Java 方法在執行的同時會創建一個棧幀用於存儲局部變量表、操作數棧、常量池引用等信息。從方法調用直至執行完成的過程，就對應着一個棧幀在 Java 虛擬機棧中入棧和出棧的過程。
• 本地方法棧： 和虛擬機棧所發揮的作用非常相似，區別是： 虛擬機棧為虛擬機執行 Java 方法 （也就是字節碼）服務，而本地方法棧則為虛擬機使用到的 Native 方法服務。 在 HotSpot 虛擬機中和 Java 虛擬機棧合二為一。

所以，為了保證線程中的局部變量不被別的線程訪問到，虛擬機棧和本地方法棧是線程私有的。

2.4. 一句話簡單了解堆和方法區

堆和方法區是所有線程共享的資源，其中堆是進程中最大的一塊內存，主要用於存放新創建的對象 (所有對象都在這裏分配內存)，方法區主要用於存放已被加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。

3. 說說併發與并行的區別?

• 併發： 同一時間段，多個任務都在執行 (單位時間內不一定同時執行)；
• 并行： 單位時間內，多個任務同時執行。

4. 為什麼要使用多線程呢?

先從總體上來說：

• 從計算機底層來說： 線程可以比作是輕量級的進程，是程序執行的最小單位,線程間的切換和調度的成本遠遠小於進程。另外，多核 CPU 時代意味着多個線程可以同時運行，這減少了線程上下文切換的開銷。
• 從當代互聯網發展趨勢來說： 現在的系統動不動就要求百萬級甚至千萬級的併發量，而多線程併發編程正是開發高併發系統的基礎，利用好多線程機制可以大大提高系統整體的併發能力以及性能。

再深入到計算機底層來探討：

• 單核時代： 在單核時代多線程主要是為了提高 CPU 和 IO 設備的綜合利用率。舉個例子：當只有一個線程的時候會導致 CPU 計算時，IO 設備空閑；進行 IO 操作時，CPU 空閑。我們可以簡單地說這兩者的利用率目前都是 50%左右。但是當有兩個線程的時候就不一樣了，當一個線程執行 CPU 計算時，另外一個線程可以進行 IO 操作，這樣兩個的利用率就可以在理想情況下達到 100%了。
• 多核時代: 多核時代多線程主要是為了提高 CPU 利用率。舉個例子：假如我們要計算一個複雜的任務，我們只用一個線程的話，CPU 只會一個 CPU 核心被利用到，而創建多個線程就可以讓多個 CPU 核心被利用到，這樣就提高了 CPU 的利用率。

5. 使用多線程可能帶來什麼問題?

併發編程的目的就是為了能提高程序的執行效率提高程序運行速度，但是併發編程並不總是能提高程序運行速度的，而且併發編程可能會遇到很多問題，比如：內存泄漏、上下文切換、死鎖還有受限於硬件和軟件的資源閑置問題。

6. 說說線程的生命周期和狀態?

Java 線程在運行的生命周期中的指定時刻只可能處於下面 6 種不同狀態的其中一個狀態（圖源《Java 併發編程藝術》4.1.4 節）。

線程在生命周期中並不是固定處於某一個狀態而是隨着代碼的執行在不同狀態之間切換。Java 線程狀態變遷如下圖所示（圖源《Java 併發編程藝術》4.1.4 節）：

由上圖可以看出：線程創建之後它將處於 NEW（新建） 狀態，調用 start() 方法后開始運行，線程這時候處於 READY（可運行） 狀態。可運行狀態的線程獲得了 CPU 時間片（timeslice）后就處於 RUNNING（運行） 狀態。

操作系統隱藏 Java 虛擬機（JVM）中的 RUNNABLE 和 RUNNING 狀態，它只能看到 RUNNABLE 狀態（圖源：：），所以 Java 系統一般將這兩個狀態統稱為 RUNNABLE（運行中） 狀態 。

當線程執行 wait()方法之後，線程進入 WAITING（等待） 狀態。進入等待狀態的線程需要依靠其他線程的通知才能夠返回到運行狀態，而 TIME_WAITING(超時等待) 狀態相當於在等待狀態的基礎上增加了超時限制，比如通過 sleep（long millis）方法或 wait（long millis）方法可以將 Java 線程置於 TIMED WAITING 狀態。當超時時間到達后 Java 線程將會返回到 RUNNABLE 狀態。當線程調用同步方法時，在沒有獲取到鎖的情況下，線程將會進入到 BLOCKED（阻塞） 狀態。線程在執行 Runnable 的run()方法之後將會進入到 TERMINATED（終止） 狀態。

7. 什麼是上下文切換?

多線程編程中一般線程的個數都大於 CPU 核心的個數，而一個 CPU 核心在任意時刻只能被一個線程使用，為了讓這些線程都能得到有效執行，CPU 採取的策略是為每個線程分配時間片並輪轉的形式。當一個線程的時間片用完的時候就會重新處於就緒狀態讓給其他線程使用，這個過程就屬於一次上下文切換。

概括來說就是：當前任務在執行完 CPU 時間片切換到另一個任務之前會先保存自己的狀態，以便下次再切換回這個任務時，可以再加載這個任務的狀態。任務從保存到再加載的過程就是一次上下文切換。

上下文切換通常是計算密集型的。也就是說，它需要相當可觀的處理器時間，在每秒幾十上百次的切換中，每次切換都需要納秒量級的時間。所以，上下文切換對系統來說意味着消耗大量的 CPU 時間，事實上，可能是操作系統中時間消耗最大的操作。

Linux 相比與其他操作系統（包括其他類 Unix 系統）有很多的優點，其中有一項就是，其上下文切換和模式切換的時間消耗非常少。

8. 什麼是線程死鎖?如何避免死鎖?

8.1. 認識線程死鎖

多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由於線程被無限期地阻塞，因此程序不可能正常終止。

如下圖所示，線程 A 持有資源 2，線程 B 持有資源 1，他們同時都想申請對方的資源，所以這兩個線程就會互相等待而進入死鎖狀態。

下面通過一個例子來說明線程死鎖,代碼模擬了上圖的死鎖的情況 (代碼來源於《併發編程之美》)：

public class DeadLockDemo {
    private static Object resource1 = new Object();//資源 1
    private static Object resource2 = new Object();//資源 2

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (resource1) {
                System.out.println(Thread.currentThread() + "get resource1");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resource2");
                synchronized (resource2) {
                    System.out.println(Thread.currentThread() + "get resource2");
                }
            }
        }, "線程 1").start();

        new Thread(() -> {
            synchronized (resource2) {
                System.out.println(Thread.currentThread() + "get resource2");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resource1");
                synchronized (resource1) {
                    System.out.println(Thread.currentThread() + "get resource1");
                }
            }
        }, "線程 2").start();
    }
}

Output

Thread[線程 1,5,main]get resource1
Thread[線程 2,5,main]get resource2
Thread[線程 1,5,main]waiting get resource2
Thread[線程 2,5,main]waiting get resource1

線程 A 通過 synchronized (resource1) 獲得 resource1 的監視器鎖，然後通過Thread.sleep(1000);讓線程 A 休眠 1s 為的是讓線程 B 得到執行然後獲取到 resource2 的監視器鎖。線程 A 和線程 B 休眠結束了都開始企圖請求獲取對方的資源，然後這兩個線程就會陷入互相等待的狀態，這也就產生了死鎖。上面的例子符合產生死鎖的四個必要條件。

學過操作系統的朋友都知道產生死鎖必須具備以下四個條件：

1. 互斥條件：該資源任意一個時刻只由一個線程佔用。
2. 請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。
3. 不剝奪條件:線程已獲得的資源在末使用完之前不能被其他線程強行剝奪，只有自己使用完畢后才釋放資源。
4. 循環等待條件:若干進程之間形成一種頭尾相接的循環等待資源關係。

8.2. 如何避免線程死鎖?

我們只要破壞產生死鎖的四個條件中的其中一個就可以了。

破壞互斥條件

這個條件我們沒有辦法破壞，因為我們用鎖本來就是想讓他們互斥的（臨界資源需要互斥訪問）。

破壞請求與保持條件

一次性申請所有的資源。

破壞不剝奪條件

佔用部分資源的線程進一步申請其他資源時，如果申請不到，可以主動釋放它佔有的資源。

破壞循環等待條件

靠按序申請資源來預防。按某一順序申請資源，釋放資源則反序釋放。破壞循環等待條件。

我們對線程 2 的代碼修改成下面這樣就不會產生死鎖了。

        new Thread(() -> {
            synchronized (resource1) {
                System.out.println(Thread.currentThread() + "get resource1");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resource2");
                synchronized (resource2) {
                    System.out.println(Thread.currentThread() + "get resource2");
                }
            }
        }, "線程 2").start();

Output

Thread[線程 1,5,main]get resource1
Thread[線程 1,5,main]waiting get resource2
Thread[線程 1,5,main]get resource2
Thread[線程 2,5,main]get resource1
Thread[線程 2,5,main]waiting get resource2
Thread[線程 2,5,main]get resource2

Process finished with exit code 0

我們分析一下上面的代碼為什麼避免了死鎖的發生?

線程 1 首先獲得到 resource1 的監視器鎖,這時候線程 2 就獲取不到了。然後線程 1 再去獲取 resource2 的監視器鎖，可以獲取到。然後線程 1 釋放了對 resource1、resource2 的監視器鎖的佔用，線程 2 獲取到就可以執行了。這樣就破壞了破壞循環等待條件，因此避免了死鎖。

9. 說說 sleep() 方法和 wait() 方法區別和共同點?

• 兩者最主要的區別在於：sleep 方法沒有釋放鎖，而 wait 方法釋放了鎖 。
• 兩者都可以暫停線程的執行。
• Wait 通常被用於線程間交互/通信，sleep 通常被用於暫停執行。
• wait() 方法被調用后，線程不會自動蘇醒，需要別的線程調用同一個對象上的 notify() 或者 notifyAll() 方法。sleep() 方法執行完成后，線程會自動蘇醒。或者可以使用wait(long timeout)超時后線程會自動蘇醒。

10. 為什麼我們調用 start() 方法時會執行 run() 方法，為什麼我們不能直接調用 run() 方法？

這是另一個非常經典的 java 多線程面試問題，而且在面試中會經常被問到。很簡單，但是很多人都會答不上來！

new 一個 Thread，線程進入了新建狀態;調用 start() 方法，會啟動一個線程並使線程進入了就緒狀態，當分配到時間片后就可以開始運行了。 start() 會執行線程的相應準備工作，然後自動執行 run() 方法的內容，這是真正的多線程工作。 而直接執行 run() 方法，會把 run 方法當成一個 main 線程下的普通方法去執行，並不會在某個線程中執行它，所以這並不是多線程工作。

總結： 調用 start 方法方可啟動線程並使線程進入就緒狀態，而 run 方法只是 thread 的一個普通方法調用，還是在主線程里執行。

開源項目推薦

作者的其他開源項目推薦：

1. ：【Java學習+面試指南】 一份涵蓋大部分Java程序員所需要掌握的核心知識。
2. : 適合新手入門以及有經驗的開發人員查閱的 Spring Boot 教程（業餘時間維護中，歡迎一起維護）。
3. : 我覺得技術人員應該有的一些好習慣！
4. :從零入門 ！Spring Security With JWT（含權限驗證）後端部分代碼。

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

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

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

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

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

1. Overview

Adaptive softmax算法在鏈接1中的論文中提出，該算法目的是為了提高softmax函數的運算效率，適用於一些具有非常大詞彙量的神經網絡。

在NLP的大部分任務中，都會用到softmax,但是對於詞彙量非常大的任務，每次進行完全的softmax會有非常大的計算量，很耗時(每次預測一個token都需要O(|V|)的時間複雜度)。

所以paper中提出adaptive softmax來提升softmax的運算效率。

1) 該算法的提出利用到了單詞分佈不均衡的特點(unbalanced word distribution)來形成clusters, 這樣在計算softmax時可以避免對詞彙量大小的線性依賴關係，降低計算時間；

2) 另外通過結合現代架構和矩陣乘積操作的特點，通過使其更適合GPU單元的方式進一步加速計算。

2. Introduction

2.1 一般降低softmax計算複雜度的兩種方式

1) 考慮原始分佈：近似原始概率分佈或近似原始概率分佈的子集

2) 構造近似模型，但是產生準確的概率分佈。比如：hierarchical softmax.

(上述兩個方法可以大致區分為：一是準確的模型產生近似概率分佈，二是用近似模型產生準確的概率分佈)

2.2 本文貢獻點

paper中主要採用的上述(2)的方式，主要借鑒的是hierarchical softmax和一些變型。與以往工作的不同在於，本paper結合了GPU的特點進行了計算加速。主要

1. 定義了一種可以生成 近似層次模型 的策略，該策略同時考慮了矩陣乘積運算的計算時間。這個計算時間並非與矩陣的維數是簡單線性關係。

2. 在近來的GPU上對該模型進行了實證分析。在所提出的優化算法中也包含了對實際計算時間模型的定義。

3. 與一般的softmax相比，有2× 到 10× 的加速。這等價於在同等算力限制下提高了準確度。另外一點非常重要，該paper所提出的這種高效計算的方法與一些通過并行提高效率的方法相比，在給定一定量的training data下，對準確度並沒有損失。

3. Adaptive Softmax 

3.1 矩陣乘積運算的計算時間模型

hidden states: (B × d); Word representation: (d × k); 這兩個矩陣的乘積運算時間: g(k, B)。其中B是batch size, d: hidden layer 的size, k vectors的數量。

(1) 固定B,d, 探究k值大小與g(k)的關係：

在K40、 M40兩種GPU model中進行實驗，發現k在大約為$k_0 \approx 50$的範圍之內，g(k)是常數級別的，在$k > k_0$后，呈線性依賴關係。其計算模型為：

同樣的，關於B的計算時間的函數也呈現這樣的關係。這可以表示，矩陣相乘時，當其中一個維度很小時，矩陣乘法是低效的。

如何理解呢？比如對於 $k_1 = 2^2$, $k_2 = 2^4$，它們均在同樣的常量時間內完成運算，那麼顯然對於$k1$量級有算力被浪費了。

那麼這也說明，一些words的層次結構，其每個節點只具有少量的子節點(比如huffman 編碼的tree)，是次優的。

(2) 探究batch size B值大小與g(B)的關係：

同樣的，當探究計算用時與batch size $B$，的關係時，發現在矩陣乘法運算中，其中一個維度很小時計算並不高效。因此會導致：

(i) 在層次結構中，因為每個節點只有少數一些孩子節點 (比如Huffman 樹)，其計算效率是次優的；

(ii) 對於按照詞頻劃分clusters后，那些只包含稀有詞的cluster，被選擇的概率為p, 並且其batch size也縮減為 $p B$，也會出現以上所述的低效的矩陣乘積運算問題。

(3) 本文的計算模型

所以paper中綜合考慮了k與B，提出了下面的計算模型：

對於Adaptive Softmax， 其核心思想是根據詞頻大小，將不同詞頻區間的詞分為不同的clusters，按照詞頻高的優先訪問的原則，來對每個cluster整體，進而對cluster中的每個詞進行訪問，進行softmax操作。

那麼paper中首先以2個clusters為例，對該模型進行講解，之後推廣到多個clusters的一般情況。

3.2 Two-Clusters Case

根據Zipf定律，在Penn TreeBank中 20%的詞，可以覆蓋一般文檔中87%的出現過的詞。

直觀地，可以將字典$V$中的詞分為$V_h$、$V_t$兩個部分。其中$V_h$表示高頻詞集合(head)，$V_t$表示低頻詞集合(tail)。一般地，$|V_h| << |V_t|$，$P(V_h) >> P(V_t)$。

(1) Clusters 的組織

直觀地可以想到對於這兩個clusters有兩種組織方式：(i) 兩個clusters都是2層的樹結構，(ii) 將head部分用一個短列表保存，對tail部分用二層樹結構。何種方式更優可以就其計算效率和準確率進行比較：

在準確率方面，(i) 較之 (ii) 一般有 5 ~ 10 %的下降。原因如下：

對於屬於cluster $c$的每個詞$w$的概率計算為： 

若採用(i):  $P(c | h) * P(w | c, h)$

若採用(ii): 對於高頻詞head部分可以直接計算獲得 $P(w | h)$，其更為簡單直接。

因此，除非(i)(ii)的計算時間有非常大的差別，否則選擇(ii)的組織方式。

(2) 對計算時間的縮短

圖2. Two clusters示意圖

如圖2所示，$k_h = |V_h|, k_t = k – k_h, p_t = 1 – p_h$

(i) 對於第一層：對於batch size 為B的輸入，在head中對$k_h$個高頻詞以及1個單位的二層cluster的向量（加陰影部分），共$k_h + 1$個向量，做softmax，

這樣占文檔中$p_h$的詞可以基本確定下來，在head 的 short list 部分找到對應的單詞；

而如果與陰影部分進行softmax值更大，表明待預測的詞，在第二層的低頻詞部分；

第一層的計算開銷為：$g(k_h + 1, B)$

(ii) 在short list 中確定了 $p_h × B$ 的內容后，還剩下 $p_t B$的輸入需要在tail中繼續進行softmax來確定所預測的詞。

第二層中需要對$k_t$個向量做softmax；

第二層的計算開銷為：$g(k_t, pB)$

綜上，總的計算開銷為：$$C = g(k_h + 1, B) + g(k_t, p_t B)$$

相比於最初的softmax，分母中需要對詞典中的每個詞的向量逐一進行計算；採用adaptive softmax可以使得該過程分為兩部分進行，每部分只需對該部分所包含的詞的向量進行計算即可，降低了計算用時。

論文中的Figure 2显示了，對於$k_h$的合理劃分，最高可以實現相較於完全softmax的5x加速。

(3) 不同cluster的分類器能力不同

由於每個cluster基本是獨立計算的，它們並不要求有相同的能力(capacity)。

一般可以為高頻詞的cluster予以更高的capacity，而可以適當降低詞頻詞的cluster的capacity。因為低頻詞在文檔中很少出現，因此對其capacity的適當降低並不會非常影響總體的性能。

在本文中，採取了為不同的clusters共享隱層，通過加映射矩陣的方式降低分類器的輸入大小。一般的，tail部分的映射矩陣將其大小從$d$維縮小到$d_t = d / 4$維。

3.3 一般性情況

在3.2中以分為2個cluster為例，介紹了adaptive softmax如何組織並計算的，這裏將其拓展為一般情況，即可以分為多個clusters時的處理方式。

假設將整個詞典分為一個head部分和J個詞頻詞cluster部分，那麼有：

$$V = V_h \cup V_1 … V_j, V_i \cap V_j = \phi$$

其中$V_h$在第一層，其餘均在第二層，如圖Figure 3所示。

每個cluster中的詞向量的數目為$k_i = |V_i|$，單詞$w$屬於某個cluster的概率為：$p_i = \sum_{w \in V_i} p(w)$.

那麼，

計算head部分的時間開銷為：$C_h = g(J + k_h, B)$

計算每個二層cluster的時間開銷為：$\forall_i, C_i = g(k_i, p_i B)$

那麼總的時間開銷為：$C = g(J + k_h, B) + \sum_i g(k_i, p_i B) \tag8$

回顧公式(7):

$$g(k,B) = max(c + \lambda k_0 B_0, c + \lambda k B) \tag7$$

這裡有兩部分，一個是常數部分$c + \lambda k_0 B_0$，一個是線性變換部分$c + \lambda k B$。

通過3.1可知，在常數部分GPU的算力並未得到充分利用，因此應盡量避免落入該部分。那麼需要滿足：

$kB \geq k_0B_0$，這樣在求max時，可以利用以上的第二部分。

將(8)式代入(7)的第二部分得：

那麼接下來的目標就是根據(10) 以最小化時間開銷C. 

在(10)中，$J ,B$是固定的，那麼可以重點關注$\sum_i p_ik_i$與$k_h$。

(1) $\sum_i p_ik_i$

假設$p_{i + j} = p_i + p_j$, 那麼 $p_jk_j = (p_{i + j} – p_i) k_j$

$p_ik_i + p_jk_j = p_i(k_i – k_j) + p_{i + j}k_j \tag{11}$  

假設$k_i > k_j, p_{i + j}$， $k_j$均固定，那麼(11)中只有$p_i$可變，可以通過減小$p_i$的方式使(11)式減小。=> 也即$k_i > k_j$ 且 $p_i$盡量小，即包含越多詞的cluster，其概率越小。

(2) $k_h$

減小$k_h$可以使(10)式減小。 => 即為可以使高頻詞所在的cluster包含更少的詞。

綜上，給定了cluster的個數J，與batch size B，可以通過給大的cluster分配以更小的概率降低時間開銷C.

另外paper中講到可以用動態規劃的方法，在給定了J后，對$k_i$的大小進行劃分。

cluster的劃分個數$J$。paper中實驗了採用不同的J所導致的不同計算時間。如圖Figure 4所示。雖然在$10 ~ 15$區間內效果最好，但$ > 5$之後效果沒有非常明顯的提升。所以文中建議採用2~5個clusters。

實驗主要在text8, europarl, one billion word三個數據集上做的，通過比較ppl發現，adaptive softmax仍能保持低的ppl，並且相比於原模型有2x到10x的提速。

參考鏈接：

1. Efficient softmax approximation for GPUs: 

Some of us get dipped in flat, some in satin, some in gloss. But every once in a while you find someone who’s iridescent, and when you do, nothing will ever compare. ~ Flipped

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

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

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

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