線上服務的GC問題，是Java程序非常典型的一類問題，非常考驗工程師排查問題的能力。同時，幾乎是面試必考題，但是能真正答好此題的人並不多，要麼原理沒吃透，要麼缺乏實戰經驗。

過去半年時間里，我們的廣告系統出現了多次和GC相關的線上問題，有Full GC過於頻繁的，有Young GC耗時過長的，這些問題帶來的影響是：GC過程中的程序卡頓，進一步導致服務超時從而影響到廣告收入。

這篇文章，我將以一個FGC頻繁的線上案例作為引子，詳細介紹下GC的排查過程，另外會結合GC的運行原理給出一份實踐指南，希望對你有所幫助。內容分成以下3個部分：

1、從一次FGC頻繁的線上案例說起

2、GC的運行原理介紹

3、排查FGC問題的實踐指南

01 從一次FGC頻繁的線上案例說起

去年10月份，我們的廣告召回系統在程序上線后收到了FGC頻繁的系統告警，通過下面的監控圖可以看到：平均每35分鐘就進行了一次FGC。而程序上線前，我們的FGC頻次大概是2天一次。下面，詳細介紹下該問題的排查過程。

1. 檢查JVM配置

通過以下命令查看JVM的啟動參數：
ps aux | grep “applicationName=adsearch”

-Xms4g -Xmx4g -Xmn2g -Xss1024K
-XX:ParallelGCThreads=5
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80

可以看到堆內存為4G，新生代為2G，老年代也為2G，新生代採用ParNew收集器，老年代採用併發標記清除的CMS收集器，當老年代的內存佔用率達到80%時會進行FGC。

進一步通過 jmap -heap 7276 | head -n20 可以得知新生代的Eden區為1.6G，S0和S1區均為0.2G。

2. 觀察老年代的內存變化

通過觀察老年代的使用情況，可以看到：每次FGC后，內存都能回到500M左右，因此我們排除了內存泄漏的情況。

3. 通過jmap命令查看堆內存中的對象

通過命令 jmap -histo 7276 | head -n20

上圖中，按照對象所佔內存大小排序，显示了存活對象的實例數、所佔內存、類名。可以看到排名第一的是：int[]，而且所佔內存大小遠遠超過其他存活對象。至此，我們將懷疑目標鎖定在了 int[] .

4. 進一步dump堆內存文件進行分析

鎖定 int[] 后，我們打算dump堆內存文件，通過可視化工具進一步跟蹤對象的來源。考慮堆轉儲過程中會暫停程序，因此我們先從服務管理平台摘掉了此節點，然後通過以下命令dump堆內存：

jmap -dump:format=b,file=heap 7276

通過JVisualVM工具導入dump出來的堆內存文件，同樣可以看到各個對象所佔空間，其中int[]佔到了50%以上的內存，進一步往下便可以找到 int[] 所屬的業務對象，發現它來自於架構團隊提供的codis基礎組件。

5. 通過代碼分析可疑對象

通過代碼分析，codis基礎組件每分鐘會生成約40M大小的int數組，用於統計TP99 和 TP90，數組的生命周期是一分鐘。而根據第2步觀察老年代的內存變化時，發現老年代的內存基本上也是每分鐘增加40多M，因此推斷：這40M的int數組應該是從新生代晉陞到老年代。

我們進一步查看了YGC的頻次監控，通過下圖可以看到大概1分鐘有8次左右的YGC，這樣基本驗證了我們的推斷：因為CMS收集器默認的分代年齡是6次，即YGC 6次后還存活的對象就會晉陞到老年代，而codis組件中的大數組生命周期是1分鐘，剛好滿足這個要求。

至此，整個排查過程基本結束了，那為什麼程序上線前沒出現此問題呢？通過上圖可以看到：程序上線前YGC的頻次在5次左右，此次上線后YGC頻次變成了8次左右，從而引發了此問題。

6. 解決方案

為了快速解決問題，我們將CMS收集器的分代年齡改成了15次，改完后FGC頻次恢復到了2天一次，後續如果YGC的頻次超過每分鐘15次還會再次觸發此問題。當然，我們最根本的解決方案是：優化程序以降低YGC的頻率，同時縮短codis組件中int數組的生命周期，這裏就不做展開了。

02 GC的運行原理介紹

上面整個案例的分析過程中，其實涉及到很多GC的原理知識，如果不懂得這些原理就着手處理，其實整個排查過程是很抓瞎的。

這裏，我選擇幾個最核心的知識點，展開介紹下GC的運行原理，最後再給出一份實踐指南。

1. 堆內存結構

大家都知道: GC分為YGC和FGC，它們均發生在JVM的堆內存上。先來看下JDK8的堆內存結構：

可以看到，堆內存採用了分代結構，包括新生代和老年代。新生代又分為：Eden區，From Survivor區（簡稱S0），To Survivor區（簡稱S1區），三者的默認比例為8:1:1。另外，新生代和老年代的默認比例為1:2。

堆內存之所以採用分代結構，是考慮到絕大部分對象都是短生命周期的，這樣不同生命周期的對象可放在不同的區域中，然後針對新生代和老年代採用不同的垃圾回收算法，從而使得GC效率最高。

2. YGC是什麼時候觸發的？

大多數情況下，對象直接在年輕代中的Eden區進行分配，如果Eden區域沒有足夠的空間，那麼就會觸發YGC（Minor GC），YGC處理的區域只有新生代。因為大部分對象在短時間內都是可收回掉的，因此YGC后只有極少數的對象能存活下來，而被移動到S0區（採用的是複製算法）。

當觸發下一次YGC時，會將Eden區和S0區的存活對象移動到S1區，同時清空Eden區和S0區。當再次觸發YGC時，這時候處理的區域就變成了Eden區和S1區（即S0和S1進行角色交換）。每經過一次YGC，存活對象的年齡就會加1。

3. FGC又是什麼時候觸發的？

下面4種情況，對象會進入到老年代中：

1、YGC時，To Survivor區不足以存放存活的對象，對象會直接進入到老年代。

2、經過多次YGC后，如果存活對象的年齡達到了設定閾值，則會晉陞到老年代中。

3、動態年齡判定規則，To Survivor區中相同年齡的對象，如果其大小之和佔到了 To Survivor區一半以上的空間，那麼大於此年齡的對象會直接進入老年代，而不需要達到默認的分代年齡。

4、大對象：由-XX:PretenureSizeThreshold啟動參數控制，若對象大小大於此值，就會繞過新生代, 直接在老年代中分配。

當晉陞到老年代的對象大於了老年代的剩餘空間時，就會觸發FGC（Major GC），FGC處理的區域同時包括新生代和老年代。除此之外，還有以下4種情況也會觸發FGC：

1、老年代的內存使用率達到了一定閾值（可通過參數調整），直接觸發FGC。

2、空間分配擔保：在YGC之前，會先檢查老年代最大可用的連續空間是否大於新生代所有對象的總空間。如果小於，說明YGC是不安全的，則會查看參數 HandlePromotionFailure 是否被設置成了允許擔保失敗，如果不允許則直接觸發Full GC；如果允許，那麼會進一步檢查老年代最大可用的連續空間是否大於歷次晉陞到老年代對象的平均大小，如果小於也會觸發 Full GC。

3、Metaspace（元空間）在空間不足時會進行擴容，當擴容到了-XX:MetaspaceSize 參數的指定值時，也會觸發FGC。

4、System.gc() 或者Runtime.gc() 被顯式調用時，觸發FGC。

4. 在什麼情況下，GC會對程序產生影響？

不管YGC還是FGC，都會造成一定程度的程序卡頓（即Stop The World問題：GC線程開始工作，其他工作線程被掛起），即使採用ParNew、CMS或者G1這些更先進的垃圾回收算法，也只是在減少卡頓時間，而並不能完全消除卡頓。

那到底什麼情況下，GC會對程序產生影響呢？根據嚴重程度從高到底，我認為包括以下4種情況：

1、FGC過於頻繁：FGC通常是比較慢的，少則幾百毫秒，多則幾秒，正常情況FGC每隔幾個小時甚至幾天才執行一次，對系統的影響還能接受。但是，一旦出現FGC頻繁（比如幾十分鐘就會執行一次），這種肯定是存在問題的，它會導致工作線程頻繁被停止，讓系統看起來一直有卡頓現象，也會使得程序的整體性能變差。

2、YGC耗時過長：一般來說，YGC的總耗時在幾十或者上百毫秒是比較正常的，雖然會引起系統卡頓幾毫秒或者幾十毫秒，這種情況幾乎對用戶無感知，對程序的影響可以忽略不計。但是如果YGC耗時達到了1秒甚至幾秒（都快趕上FGC的耗時了），那卡頓時間就會增大，加上YGC本身比較頻繁，就會導致比較多的服務超時問題。

3、FGC耗時過長：FGC耗時增加，卡頓時間也會隨之增加，尤其對於高併發服務，可能導致FGC期間比較多的超時問題，可用性降低，這種也需要關注。

4、YGC過於頻繁：即使YGC不會引起服務超時，但是YGC過於頻繁也會降低服務的整體性能，對於高併發服務也是需要關注的。

其中，「FGC過於頻繁」和「YGC耗時過長」，這兩種情況屬於比較典型的GC問題，大概率會對程序的服務質量產生影響。剩餘兩種情況的嚴重程度低一些，但是對於高併發或者高可用的程序也需要關注。

03 排查FGC問題的實踐指南

通過上面的案例分析以及理論介紹，再總結下FGC問題的排查思路，作為一份實踐指南供大家參考。

1. 清楚從程序角度，有哪些原因導致FGC？

1、大對象：系統一次性加載了過多數據到內存中（比如SQL查詢未做分頁），導致大對象進入了老年代。

2、內存泄漏：頻繁創建了大量對象，但是無法被回收（比如IO對象使用完后未調用close方法釋放資源），先引發FGC，最後導致OOM.

3、程序頻繁生成一些長生命周期的對象，當這些對象的存活年齡超過分代年齡時便會進入老年代，最後引發FGC. （即本文中的案例）

4、程序BUG導致動態生成了很多新類，使得 Metaspace 不斷被佔用，先引發FGC，最後導致OOM.

5、代碼中顯式調用了gc方法，包括自己的代碼甚至框架中的代碼。

6、JVM參數設置問題：包括總內存大小、新生代和老年代的大小、Eden區和S區的大小、元空間大小、垃圾回收算法等等。

2. 清楚排查問題時能使用哪些工具

1、公司的監控系統：大部分公司都會有，可全方位監控JVM的各項指標。

2、JDK的自帶工具，包括jmap、jstat等常用命令：

查看堆內存各區域的使用率以及GC情況
jstat -gcutil -h20 pid 1000

查看堆內存中的存活對象，並按空間排序
jmap -histo pid | head -n20

dump堆內存文件
jmap -dump:format=b,file=heap pid

3、可視化的堆內存分析工具：JVisualVM、MAT等

3. 排查指南

1、查看監控，以了解出現問題的時間點以及當前FGC的頻率（可對比正常情況看頻率是否正常）

2、了解該時間點之前有沒有程序上線、基礎組件升級等情況。

3、了解JVM的參數設置，包括：堆空間各個區域的大小設置，新生代和老年代分別採用了哪些垃圾收集器，然後分析JVM參數設置是否合理。

4、再對步驟1中列出的可能原因做排除法，其中元空間被打滿、內存泄漏、代碼顯式調用gc方法比較容易排查。

5、針對大對象或者長生命周期對象導致的FGC，可通過 jmap -histo 命令並結合dump堆內存文件作進一步分析，需要先定位到可疑對象。

6、通過可疑對象定位到具體代碼再次分析，這時候要結合GC原理和JVM參數設置，弄清楚可疑對象是否滿足了進入到老年代的條件才能下結論。

04 最後的話

這篇文章通過線上案例並結合GC原理詳細介紹了FGC的排查過程，同時給出了一份實踐指南。

後續會以類似的方式，再分享一個YGC耗時過長的案例，希望能幫助大家吃透GC問題排查，如果覺得本文對你有幫助，請大家關注我的個人公眾號！

– End –

作者簡介：程序員，985碩士，前亞馬遜Java工程師，現58轉轉技術總監。持續分享技術和管理方向的文章。如果感興趣，可微信掃描下面的二維碼關注我的公眾號：『IT人的職場進階』

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

※教你寫出一流的銷售文案?

前言

　　本文主要是結合源碼去線程池執行任務的過程，基於JDK 11，整個過程基本與JDK 8相同。

　　個人水平有限，文中若有表達有誤的，歡迎大夥留言指出，謝謝了！

一、線程池簡介

　　1.1 使用線程池的優點

　　　　1）通過復用已創建的線程，降低資源的消耗（線程的創建/銷毀是要消耗資源的）、提高響應速度；

　　　　2）管理線程的個數，線程的個數在初始化線程池的時候指定；

　　　　3）統一管理線程，比如停止，stop()方法；

　　1.2 線程池執行任務過程

　　　　線程池執行任務的過程如下圖所示，主要分為以下4步，其中參數的含義會在後面詳細講解：

　　　　1）判斷工作的線程是否小於核心線程數據（workerCountOf(c) < corePoolSize），若小於則會新建一個線程去執行任務，這一步僅僅的是根據線程個數決定；

　　　　2）若核心線程池滿了，就會判斷線程池的狀態，若是running狀態，則嘗試加入任務隊列，若加入成功后還會做一些事情，後面詳細說；

　　　　3）若任務隊列滿了，則加入失敗，此時會判斷整個線程池線程是否滿，若沒有則創建非核心線程執行任務；

　　　　4）若線程池滿了，則根據拒絕測試處理無法執行的任務；

　　　　整體過程如下圖：

二、ThreadPoolExecutor類解析

　　2.1 ThreadPoolExecutor的構造函數

　　　　ThreadPoolExecutor類一共提供了4個構造函數，涉及5~7個參數，下面就5個必備參數的構造函數進行說明：

public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue) {
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
             Executors.defaultThreadFactory(), defaultHandler);
    }

　　　　1）corePoolSize ：初始化核心線程池中線程個數的大小；

　　　　2）maxmumPoolSize：線程池中線程大小；

　　　　3）keepAliveTime：非核心線程的超時時長；

　　　　　　非核心線程空閑時常大於該值就會被終止。

　　　　4）unit ：keepAliveTime的單位，類型可以參見TimeUnit類；

　　　　5）BlockingQueue workQueue：阻塞隊列，維護等待執行的任務；

　　2.2  私有類Worker

　　　　在ThreadPoolExecutor類中有兩個集合類型比較重要，一個是用於放置等待任務的workQueue，其類型是阻塞對列；一個是用於用於存放工作線程的works，其是Set類型，其中存放的類型是Worker。

　　　　進一步簡化線程池執行過程，可以理解為works中的工作線程不停的去阻塞對列中取任務，執行結束，線程重新加入大works中。

　　　　為此，有必要簡單了解一下Work類型的組成。

private final class Worker
        extends AbstractQueuedSynchronizer
        implements Runnable
    {
        /** Thread this worker is running in.  Null if factory fails. */
        //工作線程，由線程的工廠類初始化
        final Thread thread;
        /** Initial task to run.  Possibly null. */
        Runnable firstTask;
        /** Per-thread task counter */
        volatile long completedTasks;
        //不可重入的鎖
        protected boolean tryAcquire(int unused) {
            if (compareAndSetState(0, 1)) {
                setExclusiveOwnerThread(Thread.currentThread());
                return true;
            }
            return false;
        }

        .......
    }

　　　　Worker類繼承於隊列同步器（AbstractQueueSynchronizer），隊列同步器是採取鎖或其他同步組件的基礎框架，其主要結構是自旋獲取鎖的同步隊列和等待喚醒的等待隊列，其方法因此可以分為兩類：對state改變的方法 和 入、出隊列的方法，即獲取獲取鎖的資格的變化（可能描述的不準確）。關於隊列同步器後續博客會詳細分析，此處不展開討論。

　　　　Work類中通過CAS設置狀態失敗后直接返回false，而不是判斷當前線程是否已獲取鎖來實現不可重入的鎖，源碼註釋中解釋這樣做的原因是因為避免work tash重新獲取到控制線程池全局的方法，如setCorePoolSize。

　　2.3  拒絕策略類

　　　　ThreadPoolExecutor的拒絕策略類是以私有類的方式實現的，有四種策略：

　　　　1）AbortPolicy：丟棄任務並拋出RejectedExecutionException異常（默認拒絕處理策略）。

　　　　  2）DiscardPolicy：拋棄新來的任務，但是不拋出異常。

　　　　  3）DiscardOldestPolicy：拋棄等待隊列頭部（最舊的）的任務，然後重新嘗試執行程序（失敗則會重複此過程）。

　　　　  4）CallerRunsPolicy：由調用線程處理該任務。

　　　　其代碼相對簡單，可以參考源碼。

三、任務執行過程分析

　　3.1 execute(Runnable)方法

　　　　execute(Runnable)方法的整體過程如上文1.2所述，其實現方式如下：

public void execute(Runnable command) {
        //執行的任務為空，直接拋出異常
        if (command == null)
            throw new NullPointerException();
        //ctl是ThreadPoolExecutor中很關鍵的一個AtomicInteger,主線程池的控制狀態
        int c = ctl.get();
        //1、判斷是否小於核心線程池的大小，若是則直接嘗試新建一個work線程
        if (workerCountOf(c) < corePoolSize) {
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        //2、大於核心線程池的大小或新建work失敗（如創建thread失敗），會先判斷線程池是否是running狀態，若是則加入阻塞對列
        if (isRunning(c) && workQueue.offer(command)) {
            int recheck = ctl.get();
            //重新驗證線程池是否為running，若否，則嘗試從對列中刪除，成功后執行拒絕策略
            if (! isRunning(recheck) && remove(command))
                reject(command);
            //若線程池的狀態為shutdown則，嘗試去執行完阻塞對列中的任務
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        //3、新建非核心線程去執行任務，若失敗，則採取拒絕策略
        else if (!addWorker(command, false))
            reject(command);
    }

　　3.2 addWorker(Runnable,boole)方法

　　　　execute(Runnable)方法中，新建（非）核心線程執行任務主要是通過addWorker方法實現的，其執行過程如下：

private boolean addWorker(Runnable firstTask, boolean core) {
        //此處反覆檢查線程池的狀態以及工作線程是否超過給定的值
        retry:
        for (int c = ctl.get();;) {
            // Check if queue empty only if necessary.
            if (runStateAtLeast(c, SHUTDOWN)
                && (runStateAtLeast(c, STOP)
                    || firstTask != null
                    || workQueue.isEmpty()))
                return false;

            for (;;) {
            //核心和非核心線程的區別
                if (workerCountOf(c)
                    >= ((core ? corePoolSize : maximumPoolSize) & COUNT_MASK))
                    return false;
                if (compareAndIncrementWorkerCount(c))
                    break retry;
                c = ctl.get();  // Re-read ctl
                if (runStateAtLeast(c, SHUTDOWN))
                    continue retry;
                // else CAS failed due to workerCount change; retry inner loop
            }
        }

        boolean workerStarted = false;
        boolean workerAdded = false;
        Worker w = null;
        try {
            w = new Worker(firstTask);
            //通過工廠方法初始化，可能失敗，即可能為null
            final Thread t = w.thread;
            if (t != null) {
            //獲取全局鎖
                final ReentrantLock mainLock = this.mainLock;
                mainLock.lock();
                try {
                    // Recheck while holding lock.
                    // Back out on ThreadFactory failure or if
                    // shut down before lock acquired.
                    int c = ctl.get();
                    //線程池處於running狀態
                    //或shutdown狀態但無需要執行的task，個人理解為用於去阻塞隊列中取任務執行
                    if (isRunning(c) ||
                        (runStateLessThan(c, STOP) && firstTask == null)) {
                        if (t.isAlive()) // precheck that t is startable
                            throw new IllegalThreadStateException();
                        workers.add(w);
                        int s = workers.size();
                        if (s > largestPoolSize)
                            largestPoolSize = s;
                        workerAdded = true;
                    }
                } finally {
                    mainLock.unlock();
                }
                if (workerAdded) {
                    //執行任務，這裡會執行thread的firstTask獲取阻塞對列中取任務
                    t.start();
                    workerStarted = true;
                }
            }
        } finally {
            if (! workerStarted)
            //開始失敗，則會從workers中刪除新建的work,work數量減1，嘗試關閉線程池，這些過程會獲取全局鎖
                addWorkerFailed(w);
        }
        return workerStarted;
    }

　　3.3  runWorker(this) 方法

 　　　　在3.2 中當新建的worker線程加入在workers中成功后，就會啟動對應任務，其調用的是Worker類中的run()方法，即調用runWorker(this)方法，其過程如下：

final void runWorker(Worker w) {
        Thread wt = Thread.currentThread();
        Runnable task = w.firstTask;
        w.firstTask = null;
        w.unlock(); // allow interrupts
        boolean completedAbruptly = true;
        try {
        //while()循環中，前者是新建線程執行firstTask，對應線程個數小於核心線程和阻塞隊列滿的情況，
        //getTask()則是從阻塞對列中取任務執行
            while (task != null || (task = getTask()) != null) {
                w.lock();
                // If pool is stopping, ensure thread is interrupted;
                // if not, ensure thread is not interrupted.  This
                // requires a recheck in second case to deal with
                // shutdownNow race while clearing interrupt
                //僅線程池狀態為stop時，線程響應中斷，這裏也就解釋了調用shutdown時，正在工作的線程會繼續工作
                if ((runStateAtLeast(ctl.get(), STOP) ||
                     (Thread.interrupted() &&
                      runStateAtLeast(ctl.get(), STOP))) &&
                    !wt.isInterrupted())
                    wt.interrupt();
                try {
                    beforeExecute(wt, task);
                    try {
                    //執行任務
                        task.run();
                        afterExecute(task, null);
                    } catch (Throwable ex) {
                        afterExecute(task, ex);
                        throw ex;
                    }
                } finally {
                    task = null;
                    //完成的個數+1
                    w.completedTasks++;
                    w.unlock();
                }
            }
            completedAbruptly = false;
        } finally {
            //處理後續工作
            processWorkerExit(w, completedAbruptly);
        }
    }

 　　3.4 processWorkerExit（Worker,boole）方法

　　　　當任務執行結果后，在滿足一定條件下會新增一個worker線程，代碼如下：

private void processWorkerExit(Worker w, boolean completedAbruptly) {
        if (completedAbruptly) // If abrupt, then workerCount wasn't adjusted
            decrementWorkerCount();

        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            completedTaskCount += w.completedTasks;
            //對工作線程的增減需要加全局鎖
            workers.remove(w);
        } finally {
            mainLock.unlock();
        }
        //嘗試終止線程池
        tryTerminate();

        int c = ctl.get();
        if (runStateLessThan(c, STOP)) {
        //線程不是中斷，會維持最小的個數
            if (!completedAbruptly) {
                int min = allowCoreThreadTimeOut ? 0 : corePoolSize;
                if (min == 0 && ! workQueue.isEmpty())
                    min = 1;
                if (workerCountOf(c) >= min)
                    return; // replacement not needed
            }
            //執行完任務后，線程重新加入workers中
            addWorker(null, false);
        }
    }

　　至此，線程池執行任務的過程分析結束，其他方法的實現過程可以參考源碼。

 

Ref：

[1]http://concurrent.redspider.group/article/03/12.html

[2]《Java併發編程的藝術》

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準

代碼倉庫: https://github.com/brandonlyg/cute-dl

目標

        上階段cute-dl已經可以構建基礎的RNN模型。但對文本相模型的支持不夠友好, 這個階段的目標是, 讓框架能夠友好地支持文本分類和本文生成任務。具體包括:

1. 添加嵌入層, 為文本尋找高效的向量表示。
2. 添加類別抽樣函數, 根據模型輸出的類別分佈抽樣得到生成的文本。
3. 使用imdb-review數據集驗證文本分類模型。
4. 使用一個古詩數據集驗證文本生成模型。

        這階段涉及到的代碼比較簡單因此接下來會重點描述RNN語言相關模型中涉及到的數學原理和工程方法。

數學原理

文本分類模型

        可以把文本看成是一個詞的序列\(W=[w_1, w_2, …, w_T]\), 在訓練數據集中每個文本屬於一個類別\(a_i\), \(a_i∈A\), 集合 \(A = \{ a_1, a_2, …, a_k \}\) 是一個類別別集合. 分類模型要做的是給定一個文本W, 計算所有類別的后驗概率:

\[P(a_i|W) = P(a_i|w_1,w_2,…,w_T), \quad i=1,2,…k \]

        那麼文本序列W的類別為:

\[a = arg \max_{a_i} P(a_i|w_1,w_2,…,w_T) \]

        即在給定文本的條件下, 具有最大后驗概率的類別就是文本序列W所屬的類別.

文本預測模型

        設任意一個文本序列為\(W=[w_1,w_2,…,W_T]\), 任意一個詞\(w_i ∈ V\), V是所有詞彙的集合，也叫詞彙表, 這裏需要強調的是\(w_i\)在V中是無序的, 但在W中是有序的, 文本預測的任務是, 計算任意一個詞\(w_i ∈ V\)在給定一個序列中的任意一個位置出現的概率:

\[P(w_1,…,W_T) = ∏_{t=1}^T P(w_t|w_1,…,w_{t-1}) \]

        文本預測輸出一個\(w_i ∈ V\)的分佈列, 根據這個分佈列從V中抽取一個詞即為預測結果。不同於分類任務，這裏不是取概率最大的詞, 這裏的預測結果是某個詞出現的在一個序列特定位置的個概率，只要概率不是0都有可能出現，所以要用抽樣的方法確定某次預測的結果。

詞的数字化表示

        任意一條數據在送入模型之前都要表示為一個数字化的向量, 文本數據也不例外。一個文本可以看成詞的序列，因此只要把詞数字化了，文本自然也就数字化了。對於詞來說，最簡單的方式是用詞在詞彙表中的唯一ID來表示, ID需要遵守兩個最基本的規則:

1. 每個詞的ID在詞彙表中必須是唯一的.
2. 每個詞的ID一旦確定不能變化.

        這種表示很難表達詞之間的關係, 例如: 在詞彙表中把”好”的ID指定為100, 如果希望ID能夠反映詞意的關係, 需要把”好”的近意詞: “善”, “美”, “良”, “可以”編碼為98, 99, 101, 102. 目前為止這看起還行. 如果還希望ID能夠反映詞之間的語法關係, “好”前後經常出現的詞: “友”, “人”, “的”, 這幾個詞的ID就很難選擇, 不論怎樣, 都會發現兩個詞它們在語義和語法上的關係都很遠，但ID卻很接近。這也說明了標量的表達能力很有限，無法表達多個維度的關係。為了能夠表達詞之間多個維度的的關係，多維向量是一個很好的選擇. 向量之間的夾大小衡量它們之間的關係:

\[cos(θ) = \frac{<A, B>}{|A||B|} \]

        對於兩個向量A, B使用它們的點積, 模的乘積就能得到夾角θ餘弦值。當cos(θ)->1表示兩個向量的相似度高, cos(θ)->0 表示兩個向量是不相關的, cos(θ)->-1 表示兩個向量是相反的。

        把詞的ID轉換成向量，最簡單的辦法是使用one-hot編碼, 這樣得到的向量有兩個問題:

1. 任意兩個向量A,B, <A,B>=0, 夾角的餘弦值cos(θ)=0, 不能表達詞之間的關係.
2. 向量的維度等於詞彙表的大小, 而且是稀疏向量，這和導致模型有大量的參數，模型訓練過程的運算量也很大.

        詞嵌入技術就是為解決詞表示的問題而提出的。詞嵌入把詞ID映射到一個合適維度的向量空間中, 在這個向量空間中為每個ID分配一個唯一的向量, 把這些向量當成參數看待, 在特定任務的模型中學習這些參數。當模型訓練完成后, 這些向量就是詞在這個特定任務中的一個合適的表示。詞嵌入向量的訓練步驟有:

1. 收集訓練數據集中的詞彙, 構建詞彙表。
2. 為詞彙表中的每個詞分配一個唯一的ID。假設詞彙表中的詞彙量是N, 詞ID的取值為:0,1,2,…,N-1, 對人任意一個0<ID<N-1, 必然存在ID-1, ID+1.
3. 隨機初始化N個D維嵌入向量, 向量的索引為0,1,2,…,N-1. 這樣詞ID就成了向量的索引.
4. 定義一個模型, 把嵌入向量作為模型的輸入層參与訓練.
5. 訓練模型.

嵌入層實現

        代碼: cutedl/rnn_layers.py, Embedding類.

        初始化嵌入向量, 嵌入向量使用(-1, 1)區間均勻分佈的隨機變量初始化:

'''
dims 嵌入向量維數
vocabulary_size 詞彙表大小
need_train 是否需要訓練嵌入向量
'''
def __init__(self, dims, vocabulary_size, need_train=True):
    #初始化嵌入向量
    initializer = self.weight_initializers['uniform']
    self.__vecs = initializer((vocabulary_size, dims))

    super().__init__()

    self.__params = None
    if need_train:
        self.__params = []
        self.__cur_params = None
        self.__in_batch = None

        初始化層參數時把所有的嵌入向量變成參与訓練的參數:

def init_params(self):
    if self.__params is None:
        return

    voc_size, _ = self.__vecs.shape
    for i in range(voc_size):
        pname = 'weight_%d'%i
        p = LayerParam(self.name, pname, self.__vecs[i])
        self.__params.append(p)

        向前傳播時, 把形狀為(m, t)的數據轉換成(m, t, n)形狀的數據, 其中t是序列長度, n是嵌入向量的維數.

'''
in_batch shape=(m, T)
return shape (m, T, dims)
'''
def forward(self, in_batch, training):
    m,T = in_batch.shape
    outshape = (m, T, self.outshape[-1])
    out = np.zeros(outshape)

    #得到每個序列的嵌入向量表示
    for i in range(m):
        out[i] = self.__vecs[in_batch[i]]

    if training and self.__params is not None:
        self.__in_batch = in_batch

    return out

        反向傳播時只關注當前批次使用到的向量, 注意同一個向量可能被多次使用, 需要累加同一個嵌入向量的梯度.

def backward(self, gradient):
    if self.__params is None:
        return

    #pdb.set_trace()
    in_batch = self.__in_batch
    params = {}
    m, T, _ = gradient.shape
    for i in range(m):
        for t in range(T):
            grad = gradient[i, t]
            idx = self.__in_batch[i, t]

            #更新當前訓練批次的梯度
            if idx not in params:
                #當前批次第一次發現該嵌入向量
                params[idx] = self.__params[idx]
                params[idx].gradient = grad
            else:
                #累加當前批次梯度
                params[idx].gradient += grad

    self.__cur_params = list(params.values())

驗證

imdb-review數據集上的分類模型

        代碼: examples/rnn/text_classify.py.

        數據集下載地址: https://pan.baidu.com/s/13spS_Eac_j0uRvCVi7jaMw 密碼: ou26

數據集處理

        數據集處理時有幾個需要注意的地方:

1. imdb-review數據集由長度不同的文本構成, 送入模型的數據形狀為(m, t, n), 至少要求一個批次中的數據具有相同的序列長度, 因此在對數據進行分批時, 對數據按批次填充.
2. 一般使用0為填充編碼. 在構建詞彙表時, 假設有v個詞彙, 詞彙的編碼為1,2,…,v.
3. 由於對文本進行分詞, 編碼比較耗時。可以把編碼后的數據保存起來，作為數據集的預處理數據, 下次直接加載使用。

模型

def fit_gru():
    print("fit gru")
    model = Model([
                rnn.Embedding(64, vocab_size+1),
                wrapper.Bidirectional(rnn.GRU(64), rnn.GRU(64)),
                nn.Filter(),
                nn.Dense(64),
                nn.Dropout(0.5),
                nn.Dense(1, activation='linear')
            ])
    model.assemble()
    fit('gru', model)

        訓練報告:

這個模型和tensorflow給出的模型略有差別, 少了一個RNN層wrapper.Bidirectional(rnn.GRU(32), rnn.GRU(32)), 這個模型經過16輪的訓練達到了tensorflow模型的水平.

文本生成模型

        我自己收集了一個古由詩詞構成的小型數據集, 用來驗證文本生成模型. 代碼: examples/rnn/text_gen.py.

        數據集下載地址: https://pan.baidu.com/s/14oY_wol0d9hE_9QK45IkzQ 密碼: 5f3c

        模型定義:

def fit_gru():
    vocab_size = vocab.size()
    print("vocab size: ", vocab_size)
    model = Model([
                rnn.Embedding(256, vocab_size),
                rnn.GRU(1024, stateful=True),
                nn.Dense(1024),
                nn.Dropout(0.5),
                nn.Dense(vocab_size, activation='linear')
            ])

    model.assemble()
    fit("gru", model)

        訓練報告:

        生成七言詩:

def gen_text():
    mpath = model_path+"gru"

    model = Model.load(mpath)
    print("loadding model finished")
    outshape = (4, 7)

    print("vocab size: ", vocab.size())

    def do_gen(txt):
        #編碼
        #pdb.set_trace()
        res = vocab.encode(sentence=txt)

        m, n = outshape

        for i in range(m*n - 1):
            in_batch = np.array(res).reshape((1, -1))
            preds = model.predict(in_batch)
            #取最後一維的預測結果
            preds = preds[:, -1]
            outs = dlmath.categories_sample(preds, 1)
            res.append(outs[0,0])

        #pdb.set_trace()
        txt = ""
        for i in range(m):
            txt = txt + ''.join(vocab.decode(res[i*n:(i+1)*n])) + "\n"

        return txt


    starts = ['雲', '故', '畫', '花']
    for txt in starts:
        model.reset()
        res = do_gen(txt)
        print(res)

        生成的文本:

雲填纜首月悠覺
纜濯醉二隱隱白
湖杖雨遮雙雨鄉
焉秣都滄楓寓功

故民民時都人把
陳雨積存手菜破
好纜簾二龍藕卻
趣晚城矣中村桐

畫和春覺上蓋騎
滿楚事勝便京兵
肯霆唇恨朔上楊
志月隨肯八焜著

花夜維他客陳月
客到夜狗和悲布
關欲摻似瓦闊靈
山商過牆灘幽惘

        是不是很像李商隱的風格？

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

※教你寫出一流的銷售文案?

目錄

一.介紹

二.問題提出

　　2.1內存原理圖

　　2.2幾個問題

三.回答問題

　　3.1為什麼會出現內存泄漏

　　3.2若Entry使用弱引用

　　3.3弱引用配合自動回收

四.總結　　

 

 

 

一.介紹

　　之前使用ThreadLocal的時候，就聽過ThreadLocal怎麼怎麼的可能會出現內存泄漏，具體原因也沒去深究，就是一種不清不楚的狀態。最近在看JDK的源碼，其中就包含ThreadLocal，在對ThreadLocal的使用場景介紹以及源碼的分析后，對於ThreadLocal中可能存在的內存泄漏問題也搞清楚了，所以這裏專門寫一篇博客分析一下。

　　在分析內存泄漏之前，先了解2個概念，就是內存泄漏和內存溢出：

　　內存溢出（memory overflow）：是指不能申請到足夠的內存進行使用，就會發生內存溢出，比如出現的OOM（Out Of Memory）

　　內存泄漏（memory lack）：內存泄露是指在程序中已經動態分配的堆內存由於某種原因未釋放或者無法釋放（已經沒有用處了，但是沒有釋放），造成系統內存的浪費，這種現象叫“內存泄露”。

　　當內存泄露到達一定規模后，造成系統能申請的內存較少，甚至無法申請內存，最終導致內存溢出，所以內存泄露是導致內存溢出的一個原因。

 

二.問題提出

2.1內存原理圖

　　下圖是程序運行中的內存分布圖，簡要介紹一下這種圖：當前線程有一個threadLocals屬性（ThreadLocalMap屬性），該map的底層是數組，每個數組元素時Entry類型，Entry類型的key是ThreadLocal類型（也就是創建的ThreadLocal對象），而value是則是ThreadLocal.set()方法設置的value。

　　

　　需要注意的是ThreadLocalMap的Entry，繼承自弱引用，定義如下，關於Java的引用介紹，可以參考：Java-強引用、軟引用、弱引用、虛引用

/**
 * ThreadLocalMap中存放的元素類型，繼承了弱引用類
 */
static class Entry extends WeakReference<ThreadLocal<?>> {
    // key對應的value，注意key是ThreadLocal類型
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

 

2.2問題提出

　　在看了上面ThreadLocal和ThreadLocalMap相關的內存分佈以及關聯后，提出這樣幾個問題：

　　1.ThreadLocal為什麼會出現內存溢出？

　　2.Entry的key為什麼要用弱引用？

　　3.使用弱引用是否就能解決內存溢出？

　　為了回答上面這3個問題，我寫了一段代碼，後面根據這段代碼進行分析：

public void step1() {
    // some action
    
    step2();
    step3();
    
    // other action
}

// 在stepX中都會創建threadLocal對象
public void step2() {
    ThreadLocal<String> tl = new ThreadLocal<>();
    tl.set("this is value");
}
public void step3() {
    ThreadLocal<Integer> tl = new ThreadLocal<>();
    tl.set(99);
}

　　在step1中會調用step2和step3，step2和step3都會創建ThreadLocal對象，當step2和step3執行完畢后，其中的棧內存中ThreadLocal引用就會被清除。

 

三.回答問題

 

　　

　　現在針對這個圖，一步一步的分析問題，中途會得出一些臨時的結論，但是最終的結論才是正確的。

 

3.1為什麼會出現內存泄露

　　現在有2點假設，本小節的分析都是基於這兩個假設之上的：

　　1.Entry的key使用強引用，key對ThreadLocal對象使用強引用，也就是上面圖中連線5是強引用（key強引用ThreadLocal對象）；

　　2.ThreadLocalMap中不會對過期的Entry進行清理。

　　上面代碼中，如果ThreadLocalMap的key使用強引用，那麼即使棧內存的ThreadLocal引用被清除，但是堆中的ThreadLocal對象卻並不會被清除，這是因為ThreadLocalMap中Entry的key對ThreadLocal對象是強引用。

　　如果當前線程不結束，那麼堆中的ThreadLocal對象將會一直存在，對應的內存就不會被回收，與之關聯的Entry也不會被回收（Entry對應的value也不會被回收），當這種情況出現數量比較多的時候，未釋放的內存就會上升，就可能出現內存泄漏的問題。

　　上面的結論是暫時的，有前提假設！！！最終結論還需要看後面分析。

 

3.2若Entry使用弱引用

　　

　　仍舊有1個假設，就是ThreadLocalMap中不會對過期的Entry進行清理，陳舊的Entry是指Entry的key為null。

　　按照源碼，Entry繼承弱引用，其Key對ThreadLocal是弱引用，也就是上圖中連線5是弱引用，連線6仍為強引用。

　　同樣以上面代碼為例，step2和step3創建了ThreadLocal對象，step2和step3執行完后，棧中的ThreadLocal引用被清除了；由於堆內存中ThreadLocalMap的Entry key弱引用ThreadLocal對象，根據垃圾收集器對弱引用對象的處理：

當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯的對象。

　　此時堆中ThreadLocal對象會被gc回收（因為現在沒有對ThreadLocal的強引用，只有一個弱引用ThreadLocal對象），Entry的key為null，但是value不為null，且value也是強引用（連線6），所以Entry仍舊不能回收，只能釋放ThreadLocal的內存，仍舊可能導致內存泄漏。

　　在沒有自動清理陳舊Entry的前提下，即使Entry使用弱引用，仍可能出現內存泄漏。

 

3.3弱引用配合自動回收

　　通過3.2的分析，其實只要陳舊的Entry能自動被回收，就能解決內存泄漏的問題，其實JDK就是這麼做的。

　　如果看過源碼，就知道，ThreadLocalMap底層使用數組來保存元素，使用“線性探測法”來解決hash衝突，關於線性探測法的介紹可以查看：利用線性探測法解決hash衝突

　　在每次調用ThreadLocal類的get、set、remove這些方法的時候，內部其實都是對ThreadLocalMap進行操作，對應ThreadLocalMap的get、set、remove操作。

　　重點來了！重點來了！重點來了！

　　ThreadLocalMap的每次get、set、remove，都會清理過期的Entry，下面以get操作解釋，其他操作也是一個意思，大致如下：

　　1.ThreadLocalMap底層用數組保存元素，當get一個Entry時，根據key的hash值（非hashCode）計算出該Entry應該出在什麼位置；

　　2.計算出的位置可能會有衝突，比如預期位置是position=5，但是position=5的位置已經有其他Entry了；

　　3.出現衝突后，會使用線性探測法，找position=6位置上的Entry是否匹配（匹配是指hash相同），如果匹配，則返回position=6的Entry。

　　4.在這個過程中，如果position=5位置上的Entry已經是陳舊的Entry（Entry的key為null），此時position=5的key就應該被清理；

　　5.光清理position=5的Entry還不夠，為了保證線性探測法的規則，需要判斷數組中的其他元素是否需要調整位置（如果需要，則調整位置），在這個過程中，也會進行清理陳舊Entry的操作。

　　上面這5個步驟就保證了每次get都會清理數組中（map）的陳舊Entry，清理一個陳舊的Entry，就是下面這三行代碼：

Entry.value = null; // 將Entry的value設為null
table[index] = null;// 將數組中該Entry的位置設置null
size--;	// map的size減一

　　對於ThreadLocal的set、remove也類似這個原理。

　　有了自動回收陳舊Entry的操作，需要注意的是，在這個時候，key使用弱引用就是至關重要的一點！！！

　　因為key使用弱引用后，當弱引用的ThreadLocal對象被會回收后，該key的引用為null，則該Entry在下一次get、set、remove的時候就才會被清理，從未避免內存泄漏的問題。

　　

四.總結

　　在上面的分析中，看到ThreadLocal基本不會出現內存泄漏的問題了，因為ThreadLocalMap中會在get、set、remove的時候清理陳舊的Entry，與Entry的key使用弱引用密不可分。

　　當然我們也可以在代碼中手動調用ThreadLocal的remove方法進行清除map中key為該threadLocal對象的Entry，同時清理過期的Entry。

　　

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

新車還針對霧燈區域裝飾調整，而大燈光源也更換為LED光源，照明效果更出眾。煥然一新的全新哈弗H6無疑是耐看的。要知道 耐看 向來就是比較難以保證的，在面對不斷變化的消費者眼光，懂得適時微調車型造型是一件識時務的事。

前幾天，奔赴北京，試駕了全新哈弗H6超豪型。與全新哈弗H6超豪型近距離接觸了幾天，哈弗H6已經是一款非常熟悉的SUV車型，對於它的了解也已經比較深刻；但是一款重點的全新換代，還是會讓人有不少的期待，更何況哈弗H6是一款在銷量上讓眾多同級別競品汗顏的熱銷產品，全新換代後會呈現怎樣的產品力，不得不說十分令人期待。

畢竟這是一場試駕為主的活動，所以更多的是衝著這款車本身的試駕感受去的，那文章的開始就先聊聊全新哈弗H6超豪型的駕駛體驗好了。

我從來不會擔心哈弗H6的底盤質感，在第一代哈弗H6上市后我就對它厚實穩重的底盤姿態感到十分的欣喜，而全新哈弗H6的底盤在此基礎上做了更加深度和全面的優化，底盤噪音降至一個很低的水平，在行駛過程中的舒適性得以充分保障；前麥弗遜，后多連桿的前後獨立懸架將路面振動過濾得比較徹底，而且避震響應動作同樣也比較利落，在面對常見顛簸路面的時候不會有晃晃悠悠的動作，行駛姿態非常從容。

其次動力總成的變化同樣讓人印象深刻，新的1.5T渦輪增壓發動機新增了長城自己正向研發的可變氣門升程技術，新技術的引入不僅改善了油耗水平，更在功率和峰值扭矩上做了12.7%和35.7%的提升，讓哈弗H6的綜合性能有了明顯的提高。

雙離合變速箱的標定水平也是有了長足的進步，這款濕式雙離合變速箱在實際駕駛中可以很明顯的感知到工程師在對它進行標定的時候極大程度上考慮到了行駛平順的重要性，換擋平順程度十分友好，不會有明顯突兀的頓挫感。

除了駕駛感受給留下不錯的印象，對哈弗H6的外觀印象也越來越好了。

全新哈弗H6超豪型藍標版的前臉有着比較大變化，新車用上了面積更大的進氣格柵，且鍍鉻裝飾條數量增加為五條；前保險杠處的通風口更換為網狀設計；而新車尾部整體造型變化不大。整車看起來更時尚、動感了。

至於全新哈弗H6超豪型紅標版呢？外觀也是有着不容忽視的變化。與藍標版的改變相似，紅標版新車型的進氣格柵也稍微變大了，且有着5條鍍鉻裝飾條；新車還針對霧燈區域裝飾調整，而大燈光源也更換為LED光源，照明效果更出眾。

煥然一新的全新哈弗H6無疑是耐看的。要知道 耐看 向來就是比較難以保證的，在面對不斷變化的消費者眼光，懂得適時微調車型造型是一件識時務的事。哈弗H6就很好地做到這一點，全新哈弗H6超豪型更符合當下年輕消費者的口味，潛在消費人群無疑會也進一步擴大。

進入車內，可以感受到全新哈弗H6超豪型的座椅包裹性有了明顯改善，增強了乘坐舒適性。不僅如此，新車內飾是蒙皮經純植物提取的香料處理了，還配有pM2.5粉塵過濾系統，車內的乘坐環境更為舒適。此外，新車還在後排空調出風口下方設計了兩個USB接口，車內配備了0.82㎡的超大全景天窗、前排座椅加熱等配置，這一切都令全新哈弗H6超豪型的駕乘舒適性達到了新的高度。

儲物空間方面，哈弗的工程師針對換擋桿前方置物盒造型進行優化，優化后的儲物盒能容納下更多更大的隨身物品。而新車的後備廂經優化后，整體容積增大近20L，實用性更強了。

安全，也是全新哈弗H6超豪型所注重的。新車增加了四項主動安全配置，包含半自動泊車系統、ACC自適應巡航系統、360°環視系統、FCW前碰撞預警系統+AEB自動剎車系統。此外，全新哈弗H6超豪型配備了側氣簾。主/被動安全系統更加完善的哈弗H6有助於對乘客進行全方位智能防護。

比你優秀的人不可怕，可怕的是比你優秀的人比你更努力。哈弗H6就是那個很努力的優秀“人”。作為國產緊湊型SUV市場的常勝將軍，哈弗H6一向都是走實力派路線的。試駕過很多版本的哈弗H6，可以說是看着它將自己的小毛病一個一個地改掉，到近年來接近完美的狀態。至於經多方升級的全新哈弗H6超豪型，我們有理由相信它未來將助力哈弗H6家族繼續在SUV市場叱吒風雲。

本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

以不到30萬的價格買到一輛混動的大7座SUV，還要什麼入門BBA。再來看看同樣換新顏、尺寸大一號的全新秦pro，新車搭載一套由BYD476ZQA型1。5T發動機、電動機和鋰電池組構成的插電式混動系統后，工信部申報綜合油耗僅為1升/百公里。

前幾天正巧試駕了朋友剛提不久的雷克薩斯CT200h，除了非常不錯的操控感和車身動態表現之外，讓我印象最深刻的就是油耗，在一頓猛踩和駕駛模式來回切換之後，平均油耗也不過7L/百公里，我相信還有其他車主做出了更漂亮的數據。

雖然當初一早就布局混動車型市場的CT200h並沒有因此而大賣，但發展到今天，隨着混動技術的不斷成熟和國內市場政策的風雲變幻，已經有越來越多的消費者被混動車型的諸多優勢所打動，比如省油、安靜、駕駛體驗等等。所以今天就給大家盤點一下，北京車展之後都有哪些混動車型是值得消費者密切關注的。

1、卡羅拉/雷凌pHEV插電混動版

卡羅拉和雷凌可以說是豐田的兩個“開掛”車型，從燃油版到HEV油電混動版（雙擎）從來都不愁賣，而此次北京車展上豐田終於兌現了兩年前的承諾，在國內正式發布了卡羅拉/雷凌pHEV插電混動版車型。

這兩款新車可以說是含着金鑰匙出生的“富二代”，畢竟豐田多年以來經營的品牌形象、技術實力和市場口碑為這二者打下了堅實的銷量基礎，所以目測上市后月銷1萬輛是基本操作，想要入手的朋友們可要盯緊了。

在外形上兩款新車與普通版的差別並不大，僅針對細節進行了微調，比如車頭和車尾部分都加入了藍色元素。此外，由於插電混動版搭載了更大容量的電池組，所以內部空間與普通版車型稍有差異。

值得一提的是，這兩款車屬於中國特供車，意味着自帶銷量BUG，並且其搭載了1.8L自然吸氣發動機+電動機組，同時還配備容量為9-13kWh的鋰離子電池組，純電動條件下的續航里程可超過100km。

這是神馬概念？起碼就目前我國市場上銷售的插電混動車型，大部分純電動續航里程都只在50-80km以內，並且考慮到緊湊級車推出pHEV版本的多是自主品牌車型，而它們的老對手軒逸、朗逸等還沒加入這個市場，所以此次亮相的卡羅拉和雷凌pHEV版本只要定價合適，銷量應該不成問題，別忘了它們還可獲得一部分政策補貼哦（雙擎版本沒有）。

2、領克01 pHEV插電混動版

說領克01 pHEV版之前必先提一提燃油版領克01，這款車型自去年11月上市以來便憑藉優秀的做工和沃爾沃技術的加持迅速圈粉，獲得市場的好評如潮。本以為領克會按部就班、穩紮穩打地推出新能源產品，不過眼看WEY氣勢洶洶地推出了p8之後，領克怕也是坐不太住了，於是便適時地推出了領克01 pHEV版。

在外觀和內飾方面，該車和之前的燃油版車型基本相同，只是在前進氣格柵以及前翼子板處增加了藍色元素進行點綴，表明其新能源型的身份。而尾部右下側還貼有“01 pHEV”的字樣。

動力方面，領克01 pHEV則搭載了1.5T發動機和電動機所組成的插電式混合動力系統，發動機最大凈功率約180馬力，動力電池為鎳鈷錳三元鋰離子電池，官方宣稱該車的百公里油耗僅為1.8L，同時其純電動模式下最大行駛里程為51km。如果想要入手朋友，其量產車型最快會在今年年內上市，所以準備好鈔票就是了。

3、比亞迪唐DM/秦pro

我們都知道，自從前奧迪設計師艾格入主比亞迪之後，旗下打頭陣車型瞬間秒變高富帥，就連之前被人嫌棄的“BYD”都多了一個洋氣的註釋–Build Your Dream！如果你還沒什麼畫面感的話，在此貢獻兩張圖讓大家感受一下：

了解更多點擊視頻：

全新一代唐从里裡外外都整了個遍，多了幾分國際范。首先在外觀上採用了家族最新的Dragon Face設計語言，整體大氣而又十分吸睛；

內飾同樣話題性十足，其中最搶眼的部分當屬中控可90°旋轉的超級大屏，同時全液晶儀錶和藍色氛圍燈增加了車內的科技感。

動力方面，其將搭載2.0T發動機與電動機組成的插電式混動系統，系統綜合最大功率超過500馬力，而高配車型百公里加速僅需4.5秒，咳咳划重點了–奔馳GLC43 AMG的成績為4.9秒。

值得一提的是，新一代唐標配7座布局，其長寬高分別為4870/1940/1720mm，軸距為2820mm，相比上一代車型在軸距和寬度上有所增加，所以能帶來更寬敞的乘坐體驗。另外在此次北京車展，新一代唐公布預售價–補貼后25萬起步。港真！以不到30萬的價格買到一輛混動的大7座SUV，還要什麼入門BBA！

再來看看同樣換新顏、尺寸大一號的全新秦pro，新車搭載一套由BYD476ZQA型1.5T發動機、電動機和鋰電池組構成的插電式混動系統后，工信部申報綜合油耗僅為1升/百公里！並且根據車尾標判斷，新車的官方百公里加速時間或為5.9秒，看來是充分體現了什麼叫“雨露均沾”了。

4、廣汽謳歌CDX混動版

每每提到謳歌這個品牌，總有兩道跨不過的坎，一個是跟長安LOGO抹不去的姻緣，另一個就是跟隔壁家的雷克薩斯比境遇，很顯然以上兩項都是招黑的。不過也必須承認，痛定思痛的謳歌如今似乎也有點重新步入正軌的意思了。

在此次北京車展，廣汽謳歌就帶來了CDX的混動版本，並且從售價上看還是蠻有誠意的。新車共推出了三款車型，售價區間為29.98-35.28萬元，同時新車外觀顏色增加磨砂皓灰和混動版專屬的藍紫色車漆，內飾則增加了紅色內飾可選，而頂配版車型還將增配Acura Watch。

畢竟謳歌也是“本田大法”的受益者，所以混動版車型相比同級別對手的較大優勢就體現在動力系統上。新車將搭載本田的i-MMD混合動力系統，其由一台2.0L的阿特金森循環自然吸氣發動機、由驅動電機和發電機組成的“電動CVT”直驅傳動機構、動力控制單元及鋰電池組等組成。

這套系統可以根據負載和使用條件的不同，在純電動、混合動力和發動機直驅三種模式之間無縫切換。參數方面，2.0L發動機最大功率146馬力，混動系統綜合最大功率215馬力，而官方公布的綜合油耗為5.0L/百公里。所以三十萬買一台省油的豪華SUV，好像很不錯的樣子！

5、雷克薩斯ES混動版

此次北京車展雷克薩斯的展台只放了兩台車，沒錯！只有兩台！在大多數人看來這就是典型的“寒酸”，而在雷粉眼裡這就叫“傲嬌”，因為雷克薩斯選擇把ES混動版的全球首發放在了中國，雖說一直不願意國產，雖說看展的觀眾不一定get到這樣做的用心良苦，但足以說明其對中國市場的看重。

雷克薩斯全新一代ES基於TNGA平台打造，除搭載全新2.0L發動機外，還配有2.5L多級混合動力系統，也就是全新凱美瑞上用的那一套，沒錯，就是傳說中41%熱效率的那一款名機。同時它還搭載了結構更緊湊的全新一代E-CVT电子無極變速系統，以及布局更為合理的鎳氫電池組。另外，最高純電巡航時速由前一代的75km/h提升到120km/h。

如想了解更多，點擊下方視頻：

結語

從當初雷克薩斯CT200h的“天生異質”，到如今各家廠商混合動力車型的日漸成熟，可以說能活下來的、能在市場上銷售的技術都是好技術。不管是自主品牌的比亞迪、長城、吉利，還是合資品牌的兩田，甚至是進口品牌，都在加緊布局新能源戰線，所以這對我們消費者來說無疑是個大利好。至於混動車型值不值得買這樣俗套的話題，我想就不用多糾結了，畢竟買車從來都是按需購買的。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

Quick Start: https://spark.apache.org/docs/latest/quick-start.html

 

在Spark 2.0之前，Spark的編程接口為RDD (Resilient Distributed Dataset)。而在2.0之後，RDDs被Dataset替代。Dataset很像RDD，但是有更多優化。RDD仍然支持，不過強烈建議切換到Dataset，以獲得更好的性能。 RDD文檔： https://spark.apache.org/docs/latest/rdd-programming-guide.html Dataset文檔： https://spark.apache.org/docs/latest/sql-programming-guide.html  

一、最簡單的Spark Shell交互分析

scala> val textFile = spark.read.textFile("README.md")   # 構建一個Dataset
textFile: org.apache.spark.sql.Dataset[String] = [value: string]

scala> textFile.count()  # Dataset的簡單計算
res0: Long = 104 

scala> val linesWithSpark = textFile.filter(line => line.contain("Spark"))  # 由現有Dataset生成新Dataset
res1: org.apache.spark.sql.Dataset[String] = [value: string]
# 等價於:
# res1 = new Dataset()
# for line in textFile:
#     if line.contain("Spark"):
#         res1.append(line)
# linesWithSpark = res1

scala> linesWithSpark.count()
res2: Long = 19

# 可以將多個操作串行起來
scala> textFile.filter(line => line.contain("Spark")).count()
res3: Long = 19

 

進一步的Dataset分析：

scala> textFile.map(line => line.split(" ").size).reduce((a,b) => if (a > b) a else b)
res12: Int = 16
# 其實map和reduce就是兩個普通的算子，不要被MapReduce中一個map配一個reduce、先map后reduce的思想所束縛
# map算子就是對Dataset的元素X計算fun(X)，並且將所有f(X)作為新的Dataset返回
# reduce算子其實就是通過兩兩計算fun(X,Y)=Z，將Dataset中的所有元素歸約為1個值

# 也可以引入庫進行計算
scala> import java.lang.Math
import java.lang.Math

scala> textFile.map(line => line.split(" ").size).reduce((a, b) => Math.max(a, b))
res14: Int = 16

# 還可以使用其他算子
scala> val wordCounts = textFile.flatMap(line => line.split(" ")).groupByKey(identity).count()

# flatMap算子也是對Dataset的每個元素X執行fun(X)=Y，只不過map的res是
#     res.append(Y)，如[[Y11, Y12], [Y21, Y22]]，結果按元素區分
# 而flatMap是
#     res += Y，如[Y11, Y12, Y21, Y22]，各元素結果合在一起

# groupByKey算子將Dataset的元素X作為參數傳入進行計算f(X)，並以f(X)作為key進行分組，返回值為KeyValueGroupedDataset類型
# 形式類似於(key: k; value: X1, X2, ...)，不過KeyValueGroupedDataset不是一個Dataset，value列表也不是一個array
# 注意：這裏的textFile和textFile.flatMap都是Dataset，不是RDD，groupByKey()中可以傳func；如果以sc.textFile()方法讀文件，得到的是RDD，groupByKey()中間不能傳func

# identity就是函數 x => x，即返回自身的函數

# KeyValueGroupedDataset的count()方法返回(key, len(value))列表，結果是Dataset類型

scala> wordCounts.collect()
res37: Array[(String, Long)] = Array((online,1), (graphs,1), ...
# collect操作：將分佈式存儲在集群上的RDD/Dataset中的所有數據都獲取到driver端

 

數據的cache：

scala> linesWithSpark.cache()  # in-memory cache，讓數據在分佈式內存中緩存
res38: linesWithSpark.type = [value: string]

scala> linesWithSpark.count()
res41: Long = 19

 

二、最簡單的獨立Spark任務（spark-submit提交）

需提前安裝sbt，sbt是scala的編譯工具（Scala Build Tool），類似java的maven。 brew install sbt   1）編寫SimpleApp.scala

import org.apache.spark.sql.SparkSession

object SimpleApp {
    def main(args: Array[String]) {
        val logFile = "/Users/dxm/work-space/spark-2.4.5-bin-hadoop2.7/README.md"
        val spark = SparkSession.builder.appName("Simple Application").getOrCreate()
        val logData = spark.read.textFile(logFile).cache()
        val numAs = logData.filter(line => line.contains("a")).count()  # 包含字母a的行數
        val numBs = logData.filter(line => line.contains("b")).count()  # 包含字母b的行數
        println(s"Lines with a: $numAs, Lines with b: $numBs")
        spark.stop()
    }
}

 

2）編寫sbt依賴文件build.sbt

name := "Simple Application"

version := "1.0"

scalaVersion := "2.12.10"

libraryDependencies += "org.apache.spark" %% "spark-sql" % "2.4.5"

 

其中，”org.apache.spark” %% “spark-sql” % “2.4.5”這類庫名可以在網上查到，例如https://mvnrepository.com/artifact/org.apache.spark/spark-sql_2.10/1.0.0

 

3）使用sbt打包 目錄格式如下，如果SimpleApp.scala和build.sbt放在一個目錄下會編不出來

$ find .
.
./build.sbt
./src
./src/main
./src/main/scala
./src/main/scala/SimpleApp.scala

 

sbt目錄格式要求見官方文檔 https://www.scala-sbt.org/1.x/docs/Directories.html

src/
  main/
    resources/
       <files to include in main jar here>
    scala/
       <main Scala sources>
    scala-2.12/
       <main Scala 2.12 specific sources>
    java/
       <main Java sources>
  test/
    resources
       <files to include in test jar here>
    scala/
       <test Scala sources>
    scala-2.12/
       <test Scala 2.12 specific sources>
    java/
       <test Java sources>

 

使用sbt打包

# 打包
$ sbt package
...
[success] Total time: 97 s (01:37), completed 2020-6-10 10:28:24
# jar包位於 target/scala-2.12/simple-application_2.12-1.0.jar

 

4）提交並執行Spark任務

$ bin/spark-submit --class "SimpleApp" --master spark://xxx:7077 ../scala-tests/SimpleApp/target/scala-2.12/simple-application_2.12-1.0.jar
# 報錯：Caused by: java.lang.ClassNotFoundException: scala.runtime.LambdaDeserialize
# 參考：https://stackoverflow.com/questions/47172122/classnotfoundexception-scala-runtime-lambdadeserialize-when-spark-submit
# 這是spark版本和scala版本不匹配導致的

 

查詢spark所使用的scala的版本

$ bin/spark-shell --master spark://xxx:7077

scala> util.Properties.versionString
res0: String = version 2.11.12

 

修改build.sbt： scalaVersion := “2.11.12” 從下載頁也可驗證，下載的spark 2.4.5使用的是scala 2.11  

 

重新sbt package，產出位置變更為target/scala-2.11/simple-application_2.11-1.0.jar 再次spark-submit，成功

 

$ bin/spark-submit --class "SimpleApp" --master spark://xxx:7077 ../scala-tests/SimpleApp/target/scala-2.11/simple-application_2.11-1.0.jar 
Lines with a: 61, Lines with b: 30

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準