前言

GC（Garbage Collection）是我們在學習 JVM 的過程中不可避免的一道坎，接下來，我們就來系統的學習一下 GC。

做一件事情之前，我們一定要去知道我們為什麼要去做，這裏不僅僅指 GC，更適用我們日常的學習和生活，知其然，知其所以然，方能百戰不殆。

下面我們先去了解為什麼要有 GC，以及 GC 在 JVM 中扮演了一個什麼樣的角色，起到了什麼的作用？

為什麼要有 GC

用過 C++ 的同學可能知道，對象所佔的內存在程序結束運行之前一直被佔用，在明確釋放之前不能分配給其它對象。如果我們不去手動的清除這些無用的對象，內存很快就被佔滿，而在 JVM 中，GC 所起到的作用就是一個清道夫，它可以幫助我們去判定哪些對象是無用對象，怎麼進行垃圾收集，以及決定內存分代和內存分配的策略**。

可能有同學會問了，既然我們的 JVM 會給我們做 GC 的工作，我們為什麼還要去學習 GC 呢，一切交給 JVM 不好嗎？當然，在我們的日常情況下，我們一般不會去關心 GC 的一些細節，但是當我們遇到內存泄露，內存溢出，高併發瓶頸的時候，我們就需要去對 GC 開刀，進行更為細緻的監控和調節。

內存泄露：指程序中己動態分配的堆內存由於某種原因程序未釋放或無法釋放，造成系統內存的浪費，導致程序運行速度減慢甚至系統崩潰等嚴重後果。

內存溢出：應用系統中存在無法回收的內存或使用的內存過多，最終使得程序運行要用到的內存大於能提供的最大內存。

那麼現在問題來了，我們要進行垃圾回收，首先我們需要知道垃圾在哪

垃圾在哪

前面我們講了JVM 的運行時內存區域，知道線程可以分為線程獨佔區和線程共享區，其中線程獨佔區（程序計數器，虛擬機棧，本地方法棧）的內存生命周期是和線程保持一致，且這幾個區域分配的內存大小跟類的大小有關，也就是說，當我們的類結構固定之後，這部分的內存就不會再發生更改，且當方法或線程結束的時候，內存自然就跟隨着回收了.

而線程共享區的堆內存和方法區則不一樣，堆內存和方法區所用的內存是在編譯期間無法確定的，因為一個接口的不同實現，一個方法的不同控制條件分支所執行的代碼可能完全相反，我們只有在運行時才知道會創建哪些對象，這部分的內存的分配和回收是動態的，而我們的 GC 關注的就是該部分的內存。

打個比方來說：JVM 如果是一輛車，線程獨佔區的就像是零件，在出廠時這些零件的壽命基本上都是已知的，線程共享區就像是汽油，汽油的消耗跟我們所採用的路線有關，所以我們關注的部分就是這部分會動態變化的，比如如何開車才能更省油~

知道了垃圾在什麼位置會出現，我們下一步就需要去判定在這些區域的有哪些是垃圾~

下節預告

本節內容到這裏先告一段落，下一節我們來學習，怎麼去判定是否為垃圾~

公眾號

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

【其他文章推薦】

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

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

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

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

 

 

一個月之前瀏覽博客園時發現了這本《阿里工程師的自我修養》，被裡面的其中一個叫做時間管理三八理論吸引到。花了兩個星期看完這本書。看完之後覺得有種豁然開朗的感覺，恰逢自己工作兩年，結合自己兩年以來的工作感受認真思索書中所講到的經驗，覺得有一些內容還是值得記錄下來的。於是趁這個機會總結一下書里我覺得精華的內容，對自己的兩年工作做一個回顧總結，同時按照書中所介紹的一些技巧升級自己的技能。

 

結構化思維

結構化思維 = 邏輯 + 套路

邏輯

四種組織思想的邏輯關係：

1. 因果順序： 大前提，小前提，結論。

2. 步驟順序：第一、第二、第三。首先、然後，再者，最後等。

3. 結構順序：前端，後端，數據。中國，美國，瑞士等。化整為零。

4. 程度順序：最重要，次重要，不重要。

實際上，所有的邏輯關係都在這四種順序之內，只要我們的思想和表達在這四種邏輯順序之內，就是有邏輯的，否則就會顯得沒有邏輯性。

套路

套路是指我們解決問題的方法論。使用合適的方法去解決遇到的問題。如
SWOT分析法
麥肯錫7步分析法
金字塔原理
5w2h分析法

結構化思考的方式：

 1. 建立中心目標
 2. 結構化分析
確定完中心之後，我們需要構建一個結構，使用結構化的思維對問題進行分解。分解的策略就是我們上文提到的四種邏輯順序，即演繹順序，時間順序，空間順序和程度順序。

做分解的時要滿足 MECE原則，即相互獨立，完全窮盡。

個人感悟：

想要提高自己的能力，需要懂得一些解決問題的套路。我一直以為套路就是一種經驗，面對難題時先如何，再如何，分幾步走，做到自己心中有數，這就是套路。一個初出茅廬的學生可以做事毫無頭緒，但作為一個工作兩年的老鳥，做事應該有一些最基本的套路，哪怕是一個最簡單的先搞清楚問題是什麼再動手，這也是一個好套路。做一個開發，需要做的是先思考再寫代碼。面對一個新的功能時思考設計的時間不應該低於20%，思考的時間越多bug越少。

 

如何在工作中快速成長，致工程師的10個技巧

時間管理三八理論

每個人每天公平的擁有24個小時，第一個8小時用於睡覺；第二個8小時用於工作；第三個8小時用於自由支配。
人與人的差距主要由第三個8小時決定的。第三個8小時用於消費，交易還是投資有着非常大的人生差別。

個人感悟：

記得有人說過體現一個人差距的是工作之後的時間。利用工作之餘時間繼續學習的人一定能夠成長的更快。目前所在的工作單位是事業單位的編製，朝九晚五的工作時間讓我覺得這不是程序員該有的工作節奏，所以更應該珍惜好業餘的時間多學習東西才能不遊走於技術的海平面以下。”力盡不知熱 但惜夏日長“，這是我的微信簽名，出至於白居易的《觀刈麥》，农民在炎熱的夏天割麥子精疲力竭但不覺酷熱，只是珍惜夏日天長。我又何嘗不是一個IT农民工呢？每天超長待機寫代碼寫到暈沉沉，還怕自己沒有學到東西。夏天真的好快就過去了，秋天轉眼就在眼前。沒有在夏天珍惜時間，秋天註定不會有收穫。

 

貴人相助

很多時候我們會覺得身邊缺少貴人，或者貴人離自己太遠。產生這種認知離不開4個方面：

1. 自己不自信，不相信自己能夠影響他人，導致缺乏主要溝通，長期溝通。

2. 自己心態問題，自己的心態若不夠积極正向，沒有貴人敢進入你的思維空間，因為價值不匹配，很難形成認知共識。

3. 職場原因，很多時候可能你的老闆就是你的貴人，但是因為職場，因為上下級，礙於面子，礙於共組，不敢多交流，多請教。

4. 貴人來了又走了，有貴人幫你改變，但是你自己不努力，抱着過去做事的心態和方法在職場上浪跡天涯，進步不明顯，否定了他作為貴人的價值和意義。

你求助時被人之所以願意幫你，是因為他已經看到了你的價值，這種價值幫助他確定了自己的價值，或者未來你可以幫助他。

 

個人感悟：

是否在生活中遇到過貴人呢？在這一點上我覺得我還是遇到過的，讀大學時遇到一個打球好又有耐心的球友，後來跟着他學習了兩年，球技有明顯的提高。現在想想別人為什麼願意教我打球呢？第一是因為我對打球有熱情有興趣，第二我按照他交給我的技巧打球水平有明顯的提升。後來他覺的自己有教球方面的經驗就去開了一個球館。所以說貴人幫助可能是一個互利的過程。個人覺得遇到貴人不是一件很難的事情，如果你不是一個羞澀的人。在某一方面上能夠幫助到你，對於大部分人來說還是願意幫你的，只要你態度謙虛，沒有什麼原則上問題。

 

如果我是一線主管

主管大部分時間都很忙，這就要求下屬在向上管理的時候尤其要注意高效，有質量的溝通。如果我是一線主管，我更希望團隊和我交流的方式是讓我做選擇題、判斷題，而不是問答題，思考題。
如果我是一線主管，我希望下屬這樣幫助我：

1. 主動承擔團隊面臨的挑戰，給出合理的解決方案

2. 及時向我反饋經過整理的信息和數據，甚至是結論，輔助決策

3. 主動關心同事，組織學習，幫助大家進步成長

 

團隊的人可能也有集中特徵：

1. 能力強，在某領域是專家

2. 能力一般，有潛力，但是非常有积極性

3. 能力一般，主動性一般

重要&緊急的事情只能交給能力強的人去做，意願上如果有問題也要說服對方去做，因人成事，可見能力強有多重要。

重要不緊急的事情就可以借事修人，如果做得好，這個人以後就有信心了，做的不好也有能力強的人給保底，不會造成業務問題。

技術想法也可以交給有积極性的人做，這必然會佔用一些時間，那麼這個人手頭上的無關痛癢的只好交給能力一般，主動性一般的人來做。

個人感悟：

不是每個人在工作中都是領導，但一定做過別的學長，師兄。在面對學弟學妹時是不是會覺得有些學弟辦事又快又好，而有些學弟什麼事情都要吩咐他才會去做，甚至告訴他方法也做不好。學長有時就是一個領導角色，學弟按要求將布置的任務完成，就覺得這個可以了，再有餘力可以主動承擔一些擅長的任務，就覺得用起來順手，下次有事找他，有好處也找他。我覺得最好的狀態是在工作之餘改善工作中一些複雜的操作繁瑣的步驟；給整個團隊帶來一些流程上的簡化，增加開發的效率；開發小工具能有效解決某些問題。工作之餘能夠在為團隊付出一些時間，領導應該能看的到。

 

 另外在本書中還看到了一些很優秀的PPT，不會做PPT的開發不是一個好銷售，當然這句話搞笑的很純粹，但是下面的這些PPT確實讓我覺得眼前一亮，顏色搭配，圖形搭配，樸素之中掩蓋不住的一種大氣之感。不尬吹了，直接上圖～

 

 

 

 

 

 

 

 

 

 

 

 

         

 

 

 

 

 

 

 

 

 

 

 

 

 

  

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

【其他文章推薦】

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

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

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

※南投搬家前需注意的眉眉角角，別等搬了再說!

本文源碼： ||

一、生活場景

通常一款互聯網應用的開發流程如下：業務需求，規劃產品，程序開發，測試交付。現在基於模板方法模式進行該過程描述。

public class C01_InScene {
    public static void main(String[] args) {
        DevelopApp developApp = new DevelopApp() ;
        developApp.templateMethod() ;
    }
}
/**
 * 軟件開發抽象類
 */
abstract class SoftDevelop {
    public void templateMethod(){
        //調用基本方法
        doBiz ();
        doProduct();
        doDevelop();
        doTest();
    }
    public abstract void doBiz () ;
    public abstract void doProduct () ;
    public abstract void doDevelop () ;
    public abstract void doTest () ;
}
/**
 * APP開發具體類
 */
class DevelopApp extends SoftDevelop {
    @Override
    public void doBiz() {
        System.out.println("整理App業務");
    }
    @Override
    public void doProduct() {
        System.out.println("輸出App產品");
    }
    @Override
    public void doDevelop() {
        System.out.println("進行App開發");
    }
    @Override
    public void doTest() {
        System.out.println("進行App測試");
    }
}

二、模板方法模式

1、基礎概念

模板方法模式是類的行為模式。準備一個抽象類，將部分邏輯以具體方法以及具體構造函數的形式實現，然後聲明一些抽象方法來迫使子類實現剩餘的邏輯。不同的子類可以用不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。簡單說，模板方法模式定義流程中的核心的框架，而將實際的業務操作延遲到子類中，使得子類可以不改變流程的結構，但可以重定義業務程序。

2、模式圖解

3、核心角色

• 抽象模板角色

類中實現了模板方法(template)，定義流程結構，具體業務需求子類需要去實現。

• 具體模板角色

實現父類所定義的一個或多個抽象方法，是整個流程的組成方法。抽象模板角色都可以有任意多個具體模板角色與之對應，具體模板角色都可以給出這些抽象方法的不同實現。

4、源碼實現

/**
 * 抽象模板角色
 */
abstract class AbstractTemplate {
    /**
     * 模板方法
     */
    public void templateMethod(){
        //調用基本方法
        abstractMethod();
        hookMethod();
        concreteMethod();
    }
    /**
     * 相關基本方法
     */
    protected abstract void abstractMethod();
    protected void hookMethod(){}
    private final void concreteMethod(){}
}
/**
 * 具體模板角色
 */
class ConcreteTemplate extends AbstractTemplate{
    /**
     * 基本方法的實現
     */
    @Override
    public void abstractMethod() {
    }
    /**
     * 重寫父類的方法
     */
    @Override
    public void hookMethod(){
    }
}

5、不同方法描述

• 模板方法

定義在抽象類中的，把基本操作方法組合在一起形成一個總流程的方法，可以有任意多個模板方法。

• 基本方法

1. 抽象方法：抽象方法由抽象類聲明，由具體子類實現。
2. 具體方法：具體方法由抽象類聲明並實現，而子類並不實現。
3. 鈎子方法：鈎子方法由抽象類聲明並實現，而子類可以加以擴展。

三、JavaEE應用

HttpServlet擔任抽象模板角色，模板方法：由service()方法擔任。基本方法：由doPost()、doGet()等方法擔任。service()方法流程，省略了部分判斷邏輯。該方法調用七個do方法中的一個或幾個，完成對客戶端請求的響應。這些do方法需要由HttpServlet的具體子類提供，在JavaEE中使用時，通常會自己實現相關方法。在API的封裝是典型的模板方法模式。

protected void service(HttpServletRequest req, HttpServletResponse resp) 
    throws ServletException, IOException {
    if (method.equals("GET")) {
        this.doGet(req, resp);
    } else if (method.equals("HEAD")) {
        this.doHead(req, resp);
    } else if (method.equals("POST")) {
        this.doPost(req, resp);
    } else if (method.equals("PUT")) {
        this.doPut(req, resp);
    } else if (method.equals("DELETE")) {
        this.doDelete(req, resp);
    } else if (method.equals("OPTIONS")) {
        this.doOptions(req, resp);
    } else if (method.equals("TRACE")) {
        this.doTrace(req, resp);
    } else {
        String errMsg = lStrings.getString("http.method_not_implemented");
        Object[] errArgs = new Object[]{method};
        errMsg = MessageFormat.format(errMsg, errArgs);
        resp.sendError(501, errMsg);
    }
}

四、源代碼地址

GitHub·地址
https://github.com/cicadasmile/model-arithmetic-parent
GitEE·地址
https://gitee.com/cicadasmile/model-arithmetic-parent

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

【其他文章推薦】

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

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

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