解Bug之路-記一次JVM堆外內存泄露Bug的查找

前言

JVM的堆外內存泄露的定位一直是個比較棘手的問題。此次的Bug查找從堆內內存的泄露反推出堆外內存，同時對物理內存的使用做了定量的分析，從而實錘了Bug的源頭。筆者將此Bug分析的過程寫成博客，以饗讀者。
由於物理內存定量分析部分用到了linux kernel虛擬內存管理的知識，讀者如果有興趣了解請看ulk3(《深入理解linux內核第三版》)

內存泄露Bug現場

一個線上穩定運行了三年的系統，從物理機遷移到docker環境后，運行了一段時間，突然被監控系統發出了某些實例不可用的報警。所幸有負載均衡，可以自動下掉節點，如下圖所示:

登錄到對應機器上后，發現由於內存佔用太大，觸發OOM，然後被linux系統本身給kill了。

應急措施

緊急在出問題的實例上再次啟動應用，啟動后，內存佔用正常，一切Okay。

奇怪現象

當前設置的最大堆內存是1792M，如下所示:

-Xmx1792m -Xms1792m -Xmn900m -XX:PermSi
ze=256m -XX:MaxPermSize=256m -server -Xss512k 

查看操作系統層面的監控，發現內存佔用情況如下圖所示:

上圖藍色的線表示總的內存使用量，發現一直漲到了4G后，超出了系統限制。
很明顯，有堆外內存泄露了。

查找線索

gc日誌

一般出現內存泄露，筆者立馬想到的就是查看當時的gc日誌。
本身應用所採用框架會定時打印出對應的gc日誌，遂查看，發現gc日誌一切正常。對應日誌如下:

查看了當天的所有gc日誌，發現內存始終會回落到170M左右，並無明顯的增加。要知道JVM進程本身佔用的內存可是接近4G(加上其它進程,例如日誌進程就已經到4G了)，進一步確認是堆外內存導致。

排查代碼

打開線上服務對應對應代碼，查了一圈，發現沒有任何地方顯式利用堆外內存，其沒有依賴任何額外的native方法。關於網絡IO的代碼也是託管給Tomcat，很明顯，作為一個全世界廣泛流行的Web服務器，Tomcat不大可能有堆外內存泄露。

進一步查找

由於在代碼層面沒有發現堆外內存的痕迹，那就繼續找些其它的信息，希望能發現蛛絲馬跡。

Dump出JVM的Heap堆

由於線上出問題的Server已經被kill，還好有其它幾台，登上去發現它們也 佔用了很大的堆外內存，只是還沒有到觸發OOM的臨界點而已。於是就趕緊用jmap dump了兩台機器中應用JVM的堆情況，這兩台留做現場保留不動，然後將其它機器迅速重啟，以防同時被OOM導致服務不可用。
使用如下命令dump:

jmap -dump:format=b，file=heap.bin [pid]

使用MAT分析Heap文件

挑了一個heap文件進行分析，堆的使用情況如下圖所示:

一共用了200多M，和之前gc文件打印出來的170M相差不大，遠遠沒有到4G的程度。
不得不說MAT是個非常好用的工具，它可以提示你可能內存泄露的點:

這個cachedBnsClient類有12452個實例，佔用了整個堆的61.92%。
查看了另一個heap文件，發現也是同樣的情況。這個地方肯定有內存泄露，但是也佔用了130多M，和4G相差甚遠。

查看對應的代碼

系統中大部分對於CachedBnsClient的調用，都是通過註解Autowired的，這部分實例數很少。
唯一頻繁產生此類實例的代碼如下所示:

@Override
    public void fun() {
            BnsClient bnsClient = new CachedBnsClient();
          // do something
    		return  ;
	}

此CachedBnsClient僅僅在方法體內使用，並沒有逃逸到外面，再看此類本身

public class CachedBnsClient   {
    private ConcurrentHashMap<String， List<String>> authCache = new ConcurrentHashMap<String， List<String>>();
    private ConcurrentHashMap<String， List<URI>> validUriCache = new ConcurrentHashMap<String， List<URI>>();
    private ConcurrentHashMap<String， List<URI>> uriCache = new ConcurrentHashMap<String， List<URI>>();
	......
}

沒有任何static變量，同時也沒有往任何全局變量註冊自身。換言之，在類的成員(Member)中，是不可能出現內存泄露的。
當時只粗略的過了一過成員變量，回過頭來細想，還是漏了不少地方的。

更多信息

由於代碼排查下來，感覺這塊不應該出現內存泄露(但是事實確是如此的打臉)。這個類也沒有顯式用到堆外內存，而且只佔了130M，和4G比起來微不足道，還是先去追查主要矛盾再說。

使用jstack dump線程信息

現場信息越多，越能找出蛛絲馬跡。先用jstack把線程信息dump下來看下。
這一看，立馬發現了不同，除了正常的IO線程以及框架本身的一些守護線程外，竟然還多出來了12563多個線程。

"Thread-5" daemon prio=10 tid=0x00007fb79426e000 nid=0x7346 waiting on condition [0x00007fb7b5678000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at com.xxxxx.CachedBnsClient$1.run(CachedBnsClient.java:62)

而且這些正好是運行再CachedBnsClient的run方法上面！這些特定線程的數量正好是12452個，和cachedBnsClient數量一致!

再次check對應代碼

原來剛才看CachedBnsClient代碼的時候遺漏掉了一個關鍵的點!

    public CachedBnsClient(BnsClient client) {
        super();
        this.backendClient = client;
        new Thread() {
            @Override
            public void run() {
                for (; ; ) {
                    refreshCache();
                    try {
                        Thread.sleep(60 * 1000);
                    } catch (InterruptedException e) {
                        logger.error("出錯"， e);
                    }
                }
            }
            ......
        }.start();
    }

這段代碼是CachedBnsClient的構造函數，其在裏面創建了一個無限循環的線程，每隔60s啟動一次刷新一下裏面的緩存!

找到關鍵點

在看到12452個等待在CachedBnsClient.run的業務的一瞬間筆者就意識到，肯定是這邊的線程導致對外內存泄露了。下面就是根據線程大小計算其泄露內存量是不是確實能夠引起OOM了。

發現內存計算對不上

由於我們這邊設置的Xss是512K，即一個線程棧大小是512K，而由於線程共享其它MM單元(線程本地內存是是現在線程棧上的)，所以實際線程堆外內存佔用數量也是512K。進行如下計算:

12563 * 512K = 6331M = 6.3G

整個環境一共4G，加上JVM堆內存1.8G(1792M)，已經明顯的超過了4G。

(6.3G + 1.8G)=8.1G > 4G

如果按照此計算，應用應用早就被OOM了。

怎麼回事呢？

為了解決這個問題，筆者又思考了好久。如下所示:

Java線程底層實現

JVM的線程在linux上底層是調用NPTL(Native Posix Thread Library)來創建的，一個JVM線程就對應linux的lwp(輕量級進程，也是進程，只不過共享了mm_struct，用來實現線程)，一個thread.start就相當於do_fork了一把。
其中，我們在JVM啟動時候設置了-Xss=512K(即線程棧大小)，這512K中然後有8K是必須使用的，這8K是由進程的內核棧和thread_info公用的，放在兩塊連續的物理頁框上。如下圖所示:

眾所周知，一個進程(包括lwp)包括內核棧和用戶棧，內核棧+thread_info用了8K，那麼用戶態的棧可用內存就是:

512K-8K=504K

如下圖所示:

Linux實際物理內存映射

事實上linux對物理內存的使用非常的摳門，一開始只是分配了虛擬內存的線性區，並沒有分配實際的物理內存，只有推到最後使用的時候才分配具體的物理內存，即所謂的請求調頁。如下圖所示:

查看smaps進程內存使用信息

使用如下命令，查看

cat /proc/[pid]/smaps > smaps.txt

實際物理內存使用信息，如下所示:

7fa69a6d1000-7fa69a74f000 rwxp 00000000 00:00 0 
Size:                504 kB
Rss:                  92 kB
Pss:                  92 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        92 kB
Referenced:           92 kB
Anonymous:            92 kB
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB

7fa69a7d3000-7fa69a851000 rwxp 00000000 00:00 0 
Size:                504 kB
Rss:                 152 kB
Pss:                 152 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:       152 kB
Referenced:          152 kB
Anonymous:           152 kB
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB

搜索下504KB，正好是12563個，對了12563個線程，其中Rss表示實際物理內存(含共享庫)92KB，Pss表示實際物理內存(按比例共享庫)92KB(由於沒有共享庫，所以Rss==Pss)，以第一個7fa69a6d1000-7fa69a74f000線性區來看，其映射了92KB的空間，第二個映射了152KB的空間。如下圖所示:

挑出符合條件（即size是504K）的幾十組看了下，基本都在92K-152K之間，再加上內核棧8K

(92+152)/2+8K=130K，由於是估算，取整為128K，即反映此應用平均線程棧大小。

注意，實際內存有波動的原因是由於環境不同，從而走了不同的分支，導致棧上的增長不同。

重新進行內存計算

JVM一開始申請了

-Xmx1792m -Xms1792m

即1.8G的堆內內存，這裡是即時分配，一開始就用物理頁框填充。
12563個線程，每個線程棧平均大小128K，即:

128K * 12563=1570M=1.5G的對外內存

取個整數128K，就能反映出平均水平。再拿這個128K * 12563 =1570M = 1.5G，加上JVM的1.8G，就已經達到了3.3G，再加上kernel和日誌傳輸進程等使用的內存數量，確實已經接近了4G，這樣內存就對應上了！(注:用於定量內存計算的環境是一台內存用量將近4G，但還沒OOM的機器)

為什麼在物理機上沒有應用Down機

筆者登錄了原來物理機，應用還在跑，發現其同樣有堆外內存泄露的現象，其物理內存使用已經達到了5個多G!幸好物理機內存很大，而且此應用發布還比較頻繁，所以沒有被OOM。
Dump了物理機上應用的線程，

一共有28737個線程，其中28626個線程等待在CachedBnsClient上。 

同樣用smaps查看進程實際內存信息，其平均大小依舊為

128K，因為是同一應用的原因

繼續進行物理內存計算

1.8+(28737 * 128k)/1024K =(3.6+1.8)=5.4G

進一步驗證了我們的推理。

這麼多線程應用為什麼沒有卡頓

因為基本所有的線程都睡眠在

 Thread.sleep(60 * 1000);//一次睡眠60s

上。所以僅僅佔用了內存，實際佔用的CPU時間很少。

總結

查找Bug的時候，現場信息越多越好，同時定位Bug必須要有實質性的證據。例如內存泄露就要用你推測出的模型進行定量分析。在定量和實際對不上的時候，深挖下去，你會發現不一樣的風景!

公眾號

關注筆者公眾號，獲取更多乾貨文章:

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

※回頭車貨運收費標準

概覽

上一篇文章介紹了Jackson中的映射器ObjectMapper，以及如何使用它來實現Json與Java對象之間的序列化和反序列化，最後介紹了Jackson中一些序列化/反序列化的高級特性。而本文將會介紹Jackson中的一些常用的（序列化/反序列化）註解，並且通過示例來演示如何使用這些註解，從而來提高我們在處理Json上的工作效率。

序列化註解

@JsonAnyGetter

@JsonAnyGetter註解允許靈活地使用映射（鍵值對，如Map）字段作為標準屬性。

我們聲明如下Java類：

@Data
@Accessors(chain = true)
public static class ExtendableBean {
    public String name;
    private Map<String, String> properties;

    @JsonAnyGetter
    public Map<String, String> getProperties() {
        return properties;
    }
}

編寫測試代碼，測試@JsonAnyGetter：

@Test
public void testJsonAnyGetter() throws JsonProcessingException {
    ExtendableBean extendableBean = new ExtendableBean();
    Map<String, String> map = new HashMap<>();
    map.put("age", "13");
    extendableBean.setName("dxsn").setProperties(map);
    log.info(new ObjectMapper().writeValueAsString(extendableBean));
  	//打印：{"name":"dxsn","age":"13"}
    assertThat(new ObjectMapper().writeValueAsString(extendableBean)).contains("name");
    assertThat(new ObjectMapper().writeValueAsString(extendableBean)).contains("age");
}

如上，可以看properties屬性中的鍵值對（Map）被擴展到了ExtendableBean的Json對象中。

@JsonGetter

@JsonGetter註解是@JsonProperty註解的替代品，用來將一個方法標記為getter方法。

我們創建以下Java類

@Data
@AllArgsConstructor
@NoArgsConstructor
public static class MyBean {
    public int id;
    private String name;

    @JsonGetter("name")
    public String getTheName() {
        return name;
    }
}

如上，我們在類中聲明了一個getTheName()方法，並且使用@JsonGetter(“name”)修飾，此時，該方法將會被Jackson認作是name屬性的get方法。

編寫測試代碼：

@Test
public void testJsonGetter() throws JsonProcessingException {
    MyBean myBean = new MyBean(1, "dxsn");
    String jsonStr = new ObjectMapper().writeValueAsString(myBean);
    log.info(jsonStr);
    assertThat(jsonStr).contains("id");
    assertThat(jsonStr).contains("name");
}

可以看到，jackson將私有屬性name，也進行了序列化。

@JsonPropertyOrder

我們可以使用@JsonPropertyOrder註解來指定Java對象的屬性序列化順序。

@JsonPropertyOrder({"name", "id"})
//order by key's name
//@JsonPropertyOrder(alphabetic = true)
@Data
@Accessors(chain = true)
public static class MyOrderBean {
  public int id;
  public String name;
}

編寫測試代碼：

@Test
public void testJsonPropertyOrder1() throws JsonProcessingException {
    MyOrderBean myOrderBean = new MyOrderBean().setId(1).setName("dxsn");
    String jsonStr = new ObjectMapper().writeValueAsString(myOrderBean);
    log.info(jsonStr);
    assertThat(jsonStr).isEqualTo("{\"name\":\"dxsn\",\"id\":1}");
}

如上，可以看到序列化得到的Json對象中屬性的排列順序正是我們在註解中指定的順序。

@JsonRawValue

@JsonRawValue註解可以指示Jackson按原樣序列化屬性。

在下面的例子中，我們使用@JsonRawValue嵌入一些定製的JSON作為一個實體的值:

@Data
@AllArgsConstructor
@NoArgsConstructor
public static class RawBean {
    public String name;
    @JsonRawValue
    public String json;
}

編寫測試代碼：

@Test
public void testJsonRawValue() throws JsonProcessingException {
    RawBean rawBean = new RawBean("dxsn", "{\"love\":\"true\"}");
    log.info(new ObjectMapper().writeValueAsString(rawBean));
  	//輸出：{"name":"dxsn","json":{"love":"true"}}
    String result = new ObjectMapper().writeValueAsString(rawBean);
    assertThat(result).contains("dxsn");
    assertThat(result).contains("{\"love\":\"true\"}");
}

@JsonValue

@JsonValue表示Jackson將使用一個方法來序列化整個實例。

下面我們創建一個枚舉類：

@AllArgsConstructor
public static enum TypeEnumWithValue {
    TYPE1(1, "Type A"), TYPE2(2, "Type 2");
    private Integer id;
    private String name;

    @JsonValue
    public String getName() {
        return name;
    }
}

如上，我們在getName()上使用@JsonValue進行修飾。

編寫測試代碼：

@Test
public void testJsonValue() throws JsonProcessingException {
    String  jsonStr = new ObjectMapper().writeValueAsString(TypeEnumWithValue.TYPE2);
    log.info(jsonStr);
    assertThat(jsonStr).isEqualTo("Type 2");
}

可以看到，枚舉類的對象序列化后的值即getName()方法的返回值。

@JsonRootName

如果啟用了包裝（wrapping），則使用@JsonRootName註解可以指定要使用的根包裝器的名稱。

下面我們創建一個使用@JsonRootName修飾的Java類：

@JsonRootName(value = "user")
@Data
@AllArgsConstructor
public static class UserWithRoot {
    public int id;
    public String name;
}

編寫測試：

@Test
public void testJsonRootName() throws JsonProcessingException {
    UserWithRoot userWithRoot = new UserWithRoot(1, "dxsn");
    ObjectMapper mapper = new ObjectMapper();
  	//⬇️重點！！！
    mapper.enable(SerializationFeature.WRAP_ROOT_VALUE);
  
    String result = mapper.writeValueAsString(userWithRoot);
    log.info(result);
  	//輸出：{"user":{"id":1,"name":"dxsn"}}
    assertThat(result).contains("dxsn");
    assertThat(result).contains("user");
}

上面代碼中，我們通過開啟ObjectMapper的SerializationFeature.WRAP_ROOT_VALUE。可以看到UserWithRoot對象被序列化后的Json對象被包裝在user中，而非單純的{"id":1,"name":"dxsn"}。

@JsonSerialize

@JsonSerialize註解表示序列化實體時要使用的自定義序列化器。

我們定義一個自定義的序列化器：

public static class CustomDateSerializer extends StdSerializer<Date> {
    private static SimpleDateFormat formatter = new SimpleDateFormat("dd-MM-yyyy hh:mm:ss");

    public CustomDateSerializer() {
        this(null);
    }

    public CustomDateSerializer(Class<Date> t) {
        super(t);
    }

    @Override
    public void serialize(
        Date value, JsonGenerator gen, SerializerProvider arg2) throws IOException, JsonProcessingException {
        gen.writeString(formatter.format(value));
    }
}

使用自定義的序列化器，創建Java類：

@Data
@AllArgsConstructor
public static class Event {
    public String name;
    @JsonSerialize(using = CustomDateSerializer.class)
    public Date eventDate;
}

編寫測試代碼：

@Test
public void testJsonSerialize() throws ParseException, JsonProcessingException {
    SimpleDateFormat formatter = new SimpleDateFormat("dd-MM-yyyy hh:mm:ss");
    String toParse = "20-12-2014 02:30:00";
    Date date = formatter.parse(toParse);
    Event event = new Event("party", date);
    String result = new ObjectMapper().writeValueAsString(event);
    assertThat(result).contains(toParse);
}

可以看到，使用@JsonSerialize註解修飾指定屬性后，將會使用指定的序列化器來序列化該屬性。

反序列化註解

@JsonCreator

我們可以使用@JsonCreator註解來優化/替換反序列化中使用的構造器/工廠。

當我們需要反序列化一些與我們需要獲取的目標實體不完全匹配的JSON時，它非常有用。

現在，有如下一個Json對象：

{"id":1,"theName":"My bean"}

我們聲名了一個Java類：

@Data
public static class BeanWithCreator {
    private int id;
    private String name;
}

此時，在我們的目標實體中沒有theName字段，只有name字段。現在，我們不想改變實體本身，此時可以通過使用@JsonCreator和@JsonProperty註解來修飾構造函數:

@Data
public static class BeanWithCreator {
    private int id;
    private String name;

    @JsonCreator
    public BeanWithCreator(@JsonProperty("id") int id, @JsonProperty("theName") String name) {
        this.id = id;
        this.name = name;
    }
}

編寫測試：

@Test
public void beanWithCreatorTest() throws JsonProcessingException {
    String str = "{\"id\":1,\"theName\":\"My bean\"}";
    BeanWithCreator bean = new ObjectMapper()
        .readerFor(BeanWithCreator.class)
        .readValue(str);
 	 	assertThat(bean.getId()).isEqualTo(1);
    assertThat(bean.getName()).isEqualTo("My bean");
}

可以看到，即使Json對象中的字段名和實體類中不一樣，但由於我們手動指定了映射字段的名字，從而反序列化成功。

@JacksonInject

@JacksonInject表示java對象中的屬性將通過注入來賦值，而不是從JSON數據中獲得其值。

創建如下實體類，其中有字段被@JacksonInject修飾：

public static class BeanWithInject {
    @JacksonInject
    public int id;
    public String name;
}

編寫測試：

@Test
public void jacksonInjectTest() throws JsonProcessingException {
    String json = "{\"name\":\"dxsn\"}";
    InjectableValues inject = new InjectableValues.Std()
        .addValue(int.class, 1);
    BeanWithInject bean = new ObjectMapper().reader(inject)
        .forType(BeanWithInject.class)
        .readValue(json);
    assertThat(bean.id).isEqualTo(1);
    assertThat(bean.name).isEqualTo("dxsn");
}

如上，我們在測試中將json字符串（僅存在name字段）進行反序列化，其中id通過注入的方式對屬性進行賦值。

@JsonAnySetter

@JsonAnySetter允許我們靈活地使用映射（鍵值對、Map）作為標準屬性。在反序列化時，JSON的屬性將被添加到映射中。

創建一個帶有@JsonAnySetter的實體類：

public static class ExtendableBean {
    public String name;
    public Map<String, String> properties;

    @JsonAnySetter
    public void add(String key, String value) {
        if (properties == null) {
            properties = new HashMap<>();
        }
        properties.put(key, value);
    }
}

編寫測試：

@Test
public void testJsonAnySetter() throws JsonProcessingException {
    String json = "{\"name\":\"dxsn\", \"attr2\":\"val2\", \"attr1\":\"val1\"}";
    ExtendableBean extendableBean = new ObjectMapper().readerFor(ExtendableBean.class).readValue(json);
    assertThat(extendableBean.name).isEqualTo("dxsn");
    assertThat(extendableBean.properties.size()).isEqualTo(2);
}

可以看到，json對象中的attr1，attr2屬性在反序列化之後進入了properties。

@JsonSetter

@JsonSetter是@JsonProperty的替代方法，它將方法標記為屬性的setter方法。
當我們需要讀取一些JSON數據，但目標實體類與該數據不完全匹配時，這非常有用，因此我們需要優化使其適合該數據。

創建如下實體類：

@Data
public static class MyBean {
    public int id;
    private String name;

    @JsonSetter("name")
    public void setTheName(String name) {
        this.name = "hello " + name;
    }
}

編寫測試：

@Test
public void testJsonSetter() throws JsonProcessingException {
    String json = "{\"id\":1,\"name\":\"dxsn\"}";
    MyBean bean = new ObjectMapper().readerFor(MyBean.class).readValue(json);
    assertThat(bean.getName()).isEqualTo("hello dxsn");
}

可以看到，json對象中的name屬性為“dxsn”，我們通過在MyBean類中定義了使用@JsonSetter(“name”)註解修飾的方法，這表明該類的對象在反序列話的時候，name屬性將來自此方法。最後MyBean對象中name的值變為了hello dxsn。

@JsonDeserialize

@JsonDeserialize註解指定了在反序列化的時候使用的反序列化器。

如下，定義了一個自定義的反序列化器：

public static class CustomDateDeserializer extends StdDeserializer<Date> {
    private static SimpleDateFormat formatter = new SimpleDateFormat("dd-MM-yyyy hh:mm:ss");

    public CustomDateDeserializer() {
        this(null);
    }

    public CustomDateDeserializer(Class<?> vc) {
        super(vc);
    }

    @Override
    public Date deserialize(JsonParser jsonparser, DeserializationContext context) throws IOException {
        String date = jsonparser.getText();
        try {
            return formatter.parse(date);
        } catch (ParseException e) {
            throw new RuntimeException(e);
        }
    }
}

創建一個使用@JsonDeserialize(using = CustomDateDeserializer.class)修飾的實體類：

public static class Event {
    public String name;
    @JsonDeserialize(using = CustomDateDeserializer.class)
    public Date eventDate;
}

編寫測試：

@Test
public void whenDeserializingUsingJsonDeserialize_thenCorrect()
    throws IOException {
    String json = "{\"name\":\"party\",\"eventDate\":\"20-12-2014 02:30:00\"}";
    SimpleDateFormat df = new SimpleDateFormat("dd-MM-yyyy hh:mm:ss");
    Event event = new ObjectMapper().readerFor(Event.class).readValue(json);
    assertThat(event.name).isEqualTo("party");
    assertThat(event.eventDate).isEqualTo(df.format(event.eventDate));

}

可以看到，在Event對象中，eventDate屬性通過自定義的反序列化器，將“20-12-2014 02:30:00”反序列化成了Date對象。

@JsonAlias

@JsonAlias在反序列化期間為屬性定義一個或多個替代名稱。讓我們通過一個簡單的例子來看看這個註解是如何工作的:

@Data
public static class AliasBean {
    @JsonAlias({"fName", "f_name"})
    private String firstName;
    private String lastName;
}

如上，我們編寫了一個使用@JsonAlias修飾的AliasBean實體類。

編寫測試：

@Test
public void whenDeserializingUsingJsonAlias_thenCorrect() throws IOException {
    String json = "{\"fName\": \"John\", \"lastName\": \"Green\"}";
    AliasBean aliasBean = new ObjectMapper().readerFor(AliasBean.class).readValue(json);
    assertThat(aliasBean.getFirstName()).isEqualTo("John");
}

可以看到，即使json對象中的字段名是fName，但是由於在AliasBean中使用@JsonAlias修飾了firstName屬性，並且指定了兩個別名。所以反序列化之後fName被映射到AliasBean對象的firstName屬性上。

更多

除上述註解之外，Jackson還提供了很多額外的註解，這裏不一一列舉，接下來會例舉幾個常用的註解：

• @JsonProperty：可以在類的指定屬性上添加@JsonProperty註解來表示其對應在JSON中的屬性名。
• @JsonFormat：此註解在序列化對象中的日期/時間類型屬性時可以指定一種字符串格式輸出，如：@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = “dd-MM-yyyy hh:mm:ss”)。
• @JsonUnwrapped：@JsonUnwrapped定義了在序列化/反序列化時應該被扁平化的值。
• @JsonIgnore:序列化/反序列化時忽略被修飾的屬性。
• ……

總結

本文主要介紹了Jackson常用的序列化/反序列化註解，最後介紹了幾個常用的通用註解。Jackson中提供的註解除了本文列舉的還有很多很多，使用註解可以讓我們的序列化/反序列化工作更加輕鬆。如果你想將某庫換成Jackson，希望這篇文章可以幫到你。

本文涉及的代碼地址：https://gitee.com/jeker8chen/jackson-annotation-demo

歡迎訪問筆者博客：blog.dongxishaonian.tech

關注筆者公眾號，推送各類原創/優質技術文章 ⬇️

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

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準

※網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

　　今天是2020年3月13日星期五。不知不覺已經在家待了這麼多天了，從上一節EM算法開始，數學推導越來越多，用mathtype碼公式真的是太漫長了。本來該筆記是打算把《統計學習方法》這本書做詳細的解讀，起初面對書里大量的數學推導，感到非常恐懼。假期“空窗”時間不少，才有了細嚼慢咽學習的機會。其實很大的原因是自己掌握的東西太少，知道的算法太少，所以才對這本書恐懼。買了一直放着不願意學。現在到隱馬爾可夫模型，再有一章條件隨機場，監督學習部分就結束了。這一個月來，最大的收穫是知道了“怎麼學”。

　　新的章節拋出一個新的算法模型，往往丈二和尚摸不着頭腦，什麼都是新的。越是拖延進度越慢，更不能一口吃個胖子指望看一遍就能懂。書讀百遍，其意自見，一遍不懂就再看一遍，一遍有一遍的收穫。但這個過程千萬不要盯着一本書看，一定要多找博客，多看知乎、CSDN，保持審視的態度，保留自己的見解。另外，我是喜歡直接看文字，實在不懂了才去翻視頻看，覺得這種模式挺適合我。

　　學到第十章，發現書中的很多東西，沒必要面面俱到，要適當的取捨和放過。因為畢竟這本書不是一次性消耗品，是值得深究和研習的。第一次不懂的東西，完全可以學習完所有章節，建立大的思維格局后，再重新考慮小細節。

　　接下來的所有章節，從例子出發，引入各個概念；手寫推導過程；圖解算法流程；最後實現代碼。掰扯開來，其實也就是三個問題：該模型是什麼樣子的（考慮如何引入）；該模型為什麼可以這樣做（考慮如何理解推導過程）；該模型怎麼應用（考慮代碼實現和應用場景）。

 GitHub：https://github.com/wangzycloud/statistical-learning-method

 隱馬爾科夫模型

引入

　　隱馬爾科夫模型描述由隱藏的馬爾可夫鏈隨機生成觀測序列的過程，屬於生成模型。把這句話倒着思考一下：(1)該模型屬於生成模型，會不會類似EM算法中考慮的，一個觀測數據y的生成，中間需要經過一個隱藏狀態z。(2)很明顯這裏生成的不是單個數據，而是單個數據構成的一個序列，並存在時序關係。（3）馬爾可夫鏈是什麼？在生成數據序列的過程中扮演什麼角色？

　　先區分兩個概念，“狀態and觀測”。在我的理解里，“狀態”也好，“觀測”也罷，不過是表達隨機變量的一個說法。狀態會有多個狀態，觀測會有多個觀測，但同時只允許一個狀態或者一個觀測出現。例如，現在有四個盒子（灰、黃、綠、藍），李華在五天內選盒子取球，規定每天只能取一個盒子（每個盒子被選的概率一樣大）。問，李華這五天可能會有多少種取盒子的序列，並問取到某種序列的概率是多少？如下：

　　你知道的，這個組合數不小。因為每個盒子被選到的概率一樣大，所以每個序列出現的概率相同。李華每天在盒子里取球（紅、白），現在限制每個盒子紅球、白球數目相同(紅、白球各有五個)。問，李華五天內取到球的顏色的序列有多少種，並問取到某種序列的概率是多少？

 　　顯然，這個組合數要小一些。因為每個盒子中紅白球數目相同，且此時盒子的選擇（狀態）對球的選取無影響，所以每個序列出現的概率相同。可是如果每個盒子中，紅白球的數量不是五五開，各不相同呢？李華五天內取球的某個序列的概率，就不再相同了。另外，除了受到盒子內紅白球的概率分佈影響，還要受到某天會抽到哪個盒子的概率分佈影響。

　　在上述例子中，把可能取到的盒子情況，稱作“狀態”；把可能會取到的球的情況，稱作“觀測”。在隱馬爾科夫模型中，盒子會取到的各種狀態，我們是觀測不到的。而球的各種情況我們是知道的，可以被觀測到。

　　取球要受到盒子所在狀態的影響，示意圖如下：

　　此時，還不能叫做隱馬爾可夫模型的示例。需要繼續給“取盒子->取球->得到觀測序列”的過程施加限制條件。比如說，t時刻取到某個盒子，要受到t-1時刻盒子的狀態影響。一個簡單的例子，t-1時刻盒子是綠盒子，t時刻一定取灰色盒子，且t-1時刻取到綠盒子不對t+1、t+2、…、T時刻產生影響。具體一點，就是讓“當前時刻隱藏狀態”只受上一時刻“隱藏狀態”影響，且與所處的時刻t無關。

　　通過一步步施加的各個條件，此時可以稱作隱馬爾可夫模型的示例了。

隱馬爾科夫模型的基本概念

　　先上例子，盒子和球模型。

　　在這個例子中有兩個隨機序列，一個是盒子的序列（狀態序列），也就是每次選取到的盒子序列，這個過程是隱藏的，觀測不到從哪個盒子取球；一個是球的顏色序列（觀測序列），我們只能知道取出來的各個球的顏色。

　　先分析一下取盒子環節，這是一個環環相扣的過程。從當前t-1時刻的盒子出發，考慮t時刻會取到哪個盒子，要符合規則。如當前盒子是1，根據上述規則，下一個盒子一定是盒子2。考慮t+2時刻會取到哪個盒子，要站在t+1時刻的盒子狀態上，決定取哪一個盒子。所謂的馬爾可夫性，很重要的一點，就是t-1時刻的狀態只決定t時刻的狀態（盒子1之後一定會取到盒子2），並不能決定t+1時刻狀態的取值（盒子1之後，決定不了盒子2之後會取哪個盒子）。

　　再看一下取球環節，對應着描述中的從盒子中隨機取球的過程。每個盒子裡邊紅、白球的數目不同，不同的盒子取到紅色球的概率不同。當前盒子有屬於自己的概率分佈，取球的概率不盡相同。

　　用數學語言完善完善以下過程：盒子可以構成一個集合；當前時刻的盒子如何確定下一個盒子，需要有狀態轉移概率；球可以夠成一個集合；從不同盒子裡邊取球，需要知道每個盒子的概率分佈；取了多少個球，需要有序列長度；最開始怎麼選第一個盒子。

　　根據所給的條件，有以下：

　　重點看一下狀態轉移矩陣。

　　熟悉了這個例子，再來理解數學上的各個概念。

　　這裏的狀態隨機序列就是每次取到盒子組成的序列，觀測序列就是球顏色的序列。隱馬爾科夫模型由狀態的初始概率分佈、狀態中間的轉移概率分佈以及觀測概率分佈組成。

　　對應着看，Q就是例子中盒子的集合，V就是球顏色的集合，I是盒子序列，O是顏色序列。

　　令A為狀態轉移矩陣：

　　這裏的變量i有點混亂，注意區分。公式10.2中，(1)a_ij中的i是狀態轉移矩陣A中的第i行的意思，a_ij也就是矩陣A中的第i行第j個元素，該值表示從第i個元素轉移到第j個元素的概率；(2)i_t+1、i_t中的i是指該狀態序列中的第t+1、第t個狀態，這裏i是序列的意思；(3)q_i中的i是在狀態集合中取到哪個狀態的意思。

　　t+1時刻能夠取到哪個狀態，要受到t時刻狀態的影響。也就是在t時刻狀態取某個值的條件下，t+1時刻才會有什麼樣的取值。矩陣A維度為N*N，也就是要知道該時刻每個狀態對下一時刻每個狀態的影響。

　　觀測有M種，v_k可以理解為觀測集合V中的第k個觀測。在盒子和球的例子中，可以看到每個觀測的取值，是由隱變量的狀態->哪個盒子決定的，並且只與當前的盒子有關係，每個盒子有各自取球的概率分佈。用概率符號表示就是公式10.4，表示在狀態為第j個盒子的情況下，觀測到v_k的概率。

　　用π來表示初始概率向量，也就是t=1序列起始時，根據一定的概率分佈選擇第一個盒子。

　　在這裏，狀態轉移概率矩陣A與初始狀態概率向量π確定了隱藏的馬爾可夫鏈，可生成不可觀測的狀態序列。觀測概率矩陣B確定了如何從狀態生成觀測，與狀態序列綜合確定了如何產生觀測序列。

　　從上述描述及定義10.1可以看到，隱馬爾科夫模型做了兩個基本假設：

　　(1)再次回顧盒子和球模型，盒子的選擇是不是只規定了時序上前後相鄰的盒子該怎麼選；而沒有第一次選盒子1，第三次一定會選到盒子3這樣的規定。也就是在任意時刻t的狀態只依賴於其前一時刻t-1的狀態，這就是馬爾科夫鏈“齊次”的重要性質。

　　(2)觀測獨立性假設是指我們觀測到的每一次現象（紅球、白球），只與該球所在盒子的概率分佈有關，與其它盒子的概率分佈沒有一點關係！與其它時刻的觀測沒有一點關係！

　　觀測序列的生成過程可以由算法10.1描述。

 　　HMM和CRF，與之前學習的各個模型，差別是比較大的，學習思路是要換一換。理解了隱馬爾科夫模型的基本概念，下一步就是要考慮該模型可以做什麼？怎麼做？這裏我接觸的不多，只能順着書本的思路，學習隱馬爾可夫模型的三個基本問題。

　　1）概率計算問題。很自然的，考慮一下某個觀測序列O出現的概率P(O|λ)。

　　2）學習問題。已知觀測序列，用極大似然估計的方法估計模型參數λ=（A,B,π）。

　　3）預測問題，也稱解碼問題。知道模型參數，給定觀測序列，求最有可能的對應的狀態序列。

概率計算算法

1）直接計算

　　已知模型參數λ=（A,B,π）和觀測序列O=(o1,o2,…,oT)，計算觀測序列O出現的概率P(O|λ)。很容易想到，可以按照概率公式直接進行計算。把得到觀測數據的過程，想象成兩個階段：選取狀態和生成觀測。第一步得到狀態序列，第二步得到觀測序列，可以應用乘法原理。不同的觀測序列可以得到不同的觀測序列，可以應用加法原理。類似於全概率公式，通過列舉所有可能的狀態序列I，求各個狀態序列I上生成觀測O的概率（也就是I,O的聯合概率），然後對所有可能的狀態序列求和，得到P(O|λ)。

　　容易理解，公式(10.10)為全部狀態序列中某個狀態序列I的概率計算公式；公式(10.11)為在該狀態序列I條件下，觀測序列為O時的條件概率計算方法；公式(10.12)為聯合概率公式；公式(10.13)對所有可能的狀態I求和，也就是求O的邊緣概率（考慮在I出現的所有情況條件下，O出現的概率）。簡單分析下，若狀態數目為N，一共有T個狀態序列，所以狀態序列的可能性為N^T。每一種狀態序列都要相應乘T個觀測概率，所以最後的時間複雜度為O(TN^T)。用這種方法計算觀測序列O出現的概率，是非常低效的。接下來介紹高效的計算方式，前向-後向算法。

2）前向算法

　　先來看一個新概念“前向概率”：

　　放在示意圖上，如藍色虛線框α₃(i)=P(o₁,o₂,o₃,i_t=q_i|λ)，可以從聯合概率的角度理解。具體為 α_t=3(灰色盒子)=P(o₁=紅球,o₂=白球,o₃=紅球,i_t=3=灰色盒子|λ)：

　　在前向概率的基礎上，定義前向算法為：

　　步驟(1),計算初值。注意這裏α₁(i)應用向量來表示，在t=1，觀測取到o₁時，各個隱藏狀態i都有到達o₁的概率。計算分兩步，從初始概率π_i到隱狀態q_i，再從q_i經發射矩陣到觀測o₁，需要對每個隱藏狀態i計算。

　　步驟(2)，前向算法遞推公式。α_t(i)遞推到α_t+1(i)，公式(10.16)中的b_i(o_t+1)可以理解為下圖第二步，由所在的狀態q_i經發射矩陣得到觀測o_t+1；a_ji可以理解為下圖中的第一步，也就是由t時刻狀態q_j經轉移矩陣在t+1時刻狀態為q_i的過程。

　　公式(10.16)中的求和符號，實際上反映的是t+1時刻取q_i時，其實t時刻的任何一個狀態都可以轉移到q_i，因此要把t時刻的每種狀態都考慮到。

　　步驟(3)，終止。公式(10.17)的求和符號挺好理解的，因為，對i_T=q_i求和，實際上相當於求觀測序列O的邊緣概率。

　　再來看一下書中的詳細解釋：

 　　通過畫圖，是不是要好理解一些~前向算法高效就高效在利用先前的局部計算結果，通過路徑結構將局部結果“遞推”到全局。

　　看一下例10.2，基本上就可以理解這個計算過程了。

3）後向算法

　　相應的，後向算法先了解“後向概率”這個概念。

 　　放在示意圖上，如綠色虛線框β₂(i)=P(o₃,…,o_T-1,o_T,i_t=q_i|λ)，可從條件概率的角度理解。具體為β_t=2(綠色盒子)=P(o₃=紅球,o_T-1=紅,o_T=紅球|i_t=2=綠色盒子,λ)：

 　　　在後向概率的基礎上，定義後向算法為：

　　步驟（1），初始化後向概率。這裏將最終時刻的所有狀態q_i規定為β_T(i)=1以下示意圖簡單分析。

　　這就好像是β_t(i)=P(o_t+1,o_t+2,…,o_T|i_t=q_i, λ)變成了β_t(i)=P(i_t=q_i, λ)，此時對於i_t的所有取值，i_t=q_i，是一個不爭的事實。

　　步驟（2），後向算法遞推公式。這裏的遞推方向是反向由T+1遞推到T,圖示如下：

　　這裏由T+1遞推到T，仍然需要①②兩處的連接。①是公式(10.20)中的a_ij，②是公式(10.20)中的b_j(o_t+1)。求和符號是t時刻q_i到t+1時刻q_j所有情況的匯總。取(q_i=灰色盒子，o_t+1=白球)進行分析：

　　　T+1遞推到T，我覺得圖畫的應該差不多了…①②部分是怎樣起到連接作用的…大概就是上圖這樣吧…我解釋不出來…當然了，知乎也好CSDN也好，有詳細推導公式，我就不班門弄斧了。書面解釋如下：

　　於是，利用前向概率和後向概率的定義，可以將觀測序列概率P(O|λ)同一寫成：

　　示意圖好像是這個樣子：

　　公式(10.22)中，先來看前向概率的求和部分，i=1時，α_t(1)是t時刻盒子為灰盒子，觀測序列為(o1,o2,…ot,it=q1)的概率；相應的，α_t(2)是t時刻盒子為黃盒子，觀測序列為(o1,o2,…ot,it=q2)的概率；α_t(3)是t時刻盒子為綠盒子，觀測序列為(o1,o2,…ot,it=q3)的概率；α_t(4)是t時刻盒子為藍盒子，觀測序列為(o1,o2,…ot,it=q4)的概率。那麼求和自然就代表着，不考慮盒子的影響，觀測序列為(o1,o2,…ot)的邊緣概率。對應示意圖，也就是消除了t時刻狀態的影響。

　　同理，後向概率的求和部分，在示意圖中相當於消除了t+1時刻狀態的影響。①對應着公式(10.22)中的a_ij，建立連接。②對應着公式(10.22)中的b_j(o_t+1)，將o_t+1時刻的觀測計入統計。

4）一些概率與期望值的計算

　　利用前向概率和後向概率，可以得到關於單個狀態和兩個狀態概率的計算公式。頭幾遍看這幾個公式的時候，丈二和尚摸不着頭腦，不知道這幾個概率計算有什麼用，就沒怎麼好好看。編寫這部分代碼的時候，發現這幾個公式挺重要的。在學習算法小結，對估計模型參數非常有用。公式介紹的挺具體的，這裏就不在畫圖了…學習的時候隨手畫畫圖，就能理解了~

　　1)求單個狀態的條件概率：

　　還是畫吧，這裏γ_t(i)反映是在給定觀測序列O條件下，t時刻處於狀態q_i的概率。如下圖，γ_t(i=灰色盒子)。

　　2)求兩個連續狀態的條件概率：

　　　如下圖所示ξ_t(i,j)反映的是，在給定觀測序列O的條件下，t時刻狀態為灰色盒子、t+1時刻狀態為綠色盒子的條件概率。

　　3)一些有用的期望，在學習算法小節可以看到用處：

學習算法

　　書中提到，我們進行隱馬爾可夫模型的學習，也就是對模型參數進行估計。根據訓練數據是包括觀測序列和對應的狀態序列，還是只有觀測序列，可以分別由監督學習和無監督學習實現，這裏監督學習方法實際上就是利用極大似然估計。

　　1)監督學習方法。書中直接給出了參數估計公式，這裏簡單摘抄下~

 　　2)無監督學習方法。顧名思義，無監督方法也就是只有觀測序列，進行參數估計的方法。由於監督學習需要使用標註的訓練數據，而人工標註訓練數據往往代價很高。因此有時候就會利用無監督學習的方法。我們可以將觀測序列數據看作EM算法中的不完全數據，狀態序列數據看作EM算法中不可觀測的隱數據，那麼隱馬爾可夫模型就可以看作是含有隱變量的概率模型。於是，可以通過EM算法求解。

　　詳細過程如下：

　　1.確定完全數據的對數似然函數

　　2.EM算法的E步：求Q函數Q(λ,λ^)

　　3.EM算法的M步：極大化Q函數Q(λ,λ^)求模型參數A,B,π

　　書本上有詳細的推導公式，看懂了2/3，先不摘抄了。有空了把理解了的整理上來，參數估計公式如下：

　　於是，有以下Baum-Welch算法，從這裏可以發現一些期望的用處：

預測算法　　

　　預測算法，也就是根據已知的觀測序列，找到概率最大的狀態序列（最有可能的對應的狀態序列）。

　　應用維特比算法，相當於有向無環圖求最短路徑，網上有大量詳細的資料，暫不整理了~

代碼效果

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

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準

※網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

標緻4008的內飾採用了飛航式設計理念，飛機推桿式的檔把和撥片式的功能鍵顯得頗為新穎，小尺寸方向盤給人以一種很強烈的戰鬥氣息。350THp車型搭載的是一台1。6T渦輪增壓發動機，最大馬力167匹，峰值扭矩245牛米，傳動系統也是一款6AT手自一體變速箱。

做汽車編輯久了，總會碰到很多朋友問同一個問題，就是預算二十來萬，買一台合資SUV有啥好的車型？往往這個問題後面會帶上一句：不買日系車。

在這個預算區間現在可以購買的合資SUV已經非常非常多，這次就根據小編個人所開過和感受過車型做一個推薦，前提是，今兒不說日系。

操控至上—福特翼虎

指導價格：19.38-27.58萬

推薦車型：EcoBoost 180 兩驅豪翼型

指導價格：22.98萬

福特翼虎在更換了家族式盾型前臉之後確實顯得更加漂亮了，大嘴式的進氣格柵讓它有了更加威武的視覺效果，車身線條方正，車尾的銀色下護板和雙邊排氣管也體現出了一種運動氛圍。

翼虎的內飾呈現環抱式設計，駕駛感受更接近一台轎車，而且有着良好的開車視野，車內座椅填充柔軟度適中，乘坐人員也不會顯得難受膈應。

EcoBoost 180搭載的是一台1.5T的渦輪增壓發動機，最大馬力181匹，峰值扭矩240牛米，傳動系統使用的是福特自家的6AT手自一體變速箱。

福特翼虎是二十萬級別裏面操控性能和運動感較好的一台SUV，轉向精準，動力儲備也很足，雖然1.5T的發動機在低扭時候感覺那麼一點拖沓，但是由於福特一貫將油門初段調校得較為敏感的特性，所以起步感覺並不會顯得太肉；而2000轉的時候會迎來扭矩爆發，加速超車稍微給油，翼虎的動力響應還是可以讓人滿意的類型。

個性為先—標緻4008

指導價格：18.57-23.37萬

推薦車型：2017款 350THp豪華版

指導價格：23.07萬

標緻4008的外觀設計秉承了法系車天馬行空的創意，但卻比以往的標緻品牌車型要來的更加和諧，車身肌肉感很強烈，給人以一種比較明顯的力量感，不同於普通SUV使用相對方正的設計理念，標緻4008的外觀顯得流線型更加強烈，視覺效果更加時尚。

標緻4008的內飾採用了飛航式設計理念，飛機推桿式的檔把和撥片式的功能鍵顯得頗為新穎，小尺寸方向盤給人以一種很強烈的戰鬥氣息。

350THp車型搭載的是一台1.6T渦輪增壓發動機，最大馬力167匹，峰值扭矩245牛米，傳動系統也是一款6AT手自一體變速箱。

標緻4008從外觀上說是一款非常個性前衛的SUV；標緻車型以往給人的感覺似乎一直與操控感和運動格調相關聯，但本次的標緻4008則更趨向於一台普羅大眾所理解的歐系SUV，底盤和懸挂調校偏向舒適，但扭矩爆發平台會來得比福特翼虎更早，1400轉就可以達到峰值扭矩，所以超車感覺還是相當暢快。

均衡主義—現代途勝

指導價格：15.99-23.99萬

推薦車型：2015款 1.6T 雙離合四驅尊貴型

指導價格：21.59萬

途勝的外觀設計延續了現代集團的設計理念，細節之處還是比較個性的類型，但整體看上去比較中庸，從外觀上就給人一種比較溫柔的親和力形象。

內飾的設計也是走的柔和路線，類似展翼的設計語言看上去比較溫馨，加之韓系車型血統，人機工程學的設計布局也十分符合我們中國消費者的使用習慣，溝通感比較優秀。

動力層面途勝使用的1.6T發動機最大馬力177匹，峰值扭矩265牛米，傳動系統使用的是一套7速雙離合變速箱。

途勝的性格是一款比較溫順好用的家用SUV，1.6T的動力平台也比較早，1500轉就可以輸出最大扭矩，雙離合變速箱也比較平順好用。車內布局也是非常舒適，從家用層面來說著實是一款不錯的SUV。

全文總結：以上三款車，從家用務實的角度來看小編推薦的是現代途勝，韓系SUV一直都以比較舒適、平和的性格在市場上立足，而且定價不高，21萬出頭的價格可以購買四驅版本，這是歐美系同級別SUV難以企及的配置，有四驅，在泥濘爛路的信心也更加充足。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準

※網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!