作者：Lucida

• 微博：@peng_gong

本文謝絕轉載，如需轉載需徵得作者本人同意，謝謝。

本文是深入理解Java 8 Lambda系列的第二篇，主要介紹Java 8針對新增語言特性而新增的類庫（例如Streams API、Collectors和並行）。

關於

Java SE 8增加了新的語言特性（例如lambda表示式和預設方法），為此Java SE 8的類庫也進行了很多改進，本文簡要介紹了這些改進。在閱讀本文前，你應該先閱讀 深入淺出Java 8 Lambda（語言篇），以便對Java SE 8的新增特性有一個全面瞭解。

背景（Background）

自從lambda表示式成為Java語言的一部分之後，Java集合（Collections）API就面臨著大幅變化。而

• 為現有的介面（例如 Collection， List和 Stream）增加擴充套件方法；
• 在類庫中增加新的 流（stream，即 java.util.stream.Stream）抽象以便進行聚集（aggregation）操作；
• 改造現有的型別使之可以提供流檢視（stream view）；
• 改造現有的型別使之可以容易的使用新的程式設計模式，這樣使用者就不必拋棄使用以久的類庫，例如 ArrayList和 HashMap（當然這並不是說集合API會常駐永存，畢竟集合API在設計之初並沒有考慮到lambda表示式。我們可能會在未來的JDK中新增一個更現代的集合類庫）。

除了上面的改進，還有一項重要工作就是提供更加易用的並行（Parallelism）庫。儘管Java平臺已經對並行和併發提供了強有力的支援，然而開發者在實際工作（將序列程式碼並行化）中仍然會碰到很多問題。因此，我們希望Java類庫能夠既便於編寫序列程式碼也便於編寫並行程式碼，因此我們把程式設計的重點從具體執行細節（how computation should be formed）轉移到抽象執行步驟（what computation should be perfomed）。除此之外，我們還需要在將並行變的 容易

內部迭代和外部迭代（Internal vs external iteration）

集合類庫主要依賴於 外部迭代（external iteration）。 Collection實現 Iterable介面，從而使得使用者可以依次遍歷集合的元素。比如我們需要把一個集合中的形狀都設定成紅色，那麼可以這麼寫：

for (Shape shape: shapes) {
  shape.setColor(RED);
}

這個例子演示了外部迭代：for-each迴圈呼叫 shapes的 iterator()方法進行依次遍歷。外部迴圈的程式碼非常直接，但它有如下問題：

• Java的for迴圈是序列的，而且必須按照集合中元素的順序進行依次處理；
• 集合框架無法對控制流進行優化，例如通過排序、並行、短路（short-circuiting）求值以及惰性求值改善效能。

儘管有時for-each迴圈的這些特性（序列，依次）是我們所期待的，但它對改善效能造成了阻礙。

我們可以使用 內部迭代（internal iteration）替代外部迭代，使用者把對迭代的控制權交給類庫，並向類庫傳遞迭代時所需執行的程式碼。

下面是前例的內部迭代程式碼：

shapes.forEach(s -> s.setColor(RED));

儘管看起來只是一個小小的語法改動，但是它們的實際差別非常巨大。使用者把對操作的控制權交還給類庫，從而允許類庫進行各種各樣的優化（例如亂序執行、惰性求值和並行等等）。總的來說，內部迭代使得外部迭代中不可能實現的優化成為可能。

外部迭代同時承擔了 做什麼（把形狀設為紅色）和 怎麼做（得到 Iterator例項然後依次遍歷）兩項職責，而內部迭代只負責 做什麼，而把 怎麼做留給類庫。通過這樣的職責轉變：使用者的程式碼會變得更加清晰，而類庫則可以進行各種優化，從而使所有使用者都從中受益。

流（Stream）

流是Java SE 8類庫中新增的關鍵抽象，它被定義於 java.util.stream（這個包裡有若干流型別： Stream<T>代表物件引用流，此外還有一系列特化（specialization）流，比如 IntStream代表整形數字流）。每個流代表一個值序列，流提供一系列常用的聚集操作，使得我們可以便捷的在它上面進行各種運算。集合類庫也提供了便捷的方式使我們可以以操作流的方式使用集合、陣列以及其它資料結構。

流的操作可以被組合成 流水線（Pipeline）。以前面的例子為例，如果我們只想把藍色改成紅色：

shapes.stream()
      .filter(s -> s.getColor() == BLUE)
      .forEach(s -> s.setColor(RED));

在 Collection上呼叫 stream()會生成該集合元素的流檢視（stream view），接下來 filter()操作會產生只包含藍色形狀的流，最後，這些藍色形狀會被 forEach操作設為紅色。

如果我們想把藍色的形狀提取到新的 List裡，則可以：

List<Shape> blue = shapes.stream()
                         .filter(s -> s.getColor() == BLUE)
                         .collect(Collectors.toList());

collect()操作會把其接收的元素聚集（aggregate）到一起（這裡是 List）， collect()方法的引數則被用來指定如何進行聚集操作。在這裡我們使用 toList()以把元素輸出到 List中。（如需更多 collect()方法的細節，請閱讀Collectors一節）

如果每個形狀都被儲存在 Box裡，然後我們想知道哪個盒子至少包含一個藍色形狀，我們可以這麼寫：

Set<Box> hasBlueShape = shapes.stream()
                              .filter(s -> s.getColor() == BLUE)
                              .map(s -> s.getContainingBox())
                              .collect(Collectors.toSet());

map()操作通過對映函式（這裡的對映函式接收一個形狀，然後返回包含它的盒子）對輸入流裡面的元素進行依次轉換，然後產生新流。

如果我們需要得到藍色物體的總重量，我們可以這樣表達：

int sum = shapes.stream()
                .filter(s -> s.getColor() == BLUE)
                .mapToInt(s -> s.getWeight())
                .sum();

這些例子演示了流框架的設計，以及如何使用流框架解決實際問題。

流和集合（Streams vs Collections）

集合和流盡管在表面上看起來很相似，但它們的設計目標是不同的：集合主要用來對其元素進行有效（effective）的管理和訪問（access），而流並不支援對其元素進行直接操作或直接訪問，而只支援通過宣告式操作在其上進行運算然後得到結果。除此之外，流和集合還有一些其它不同：

• 無儲存：流並不儲存值；流的元素源自資料來源（可能是某個資料結構、生成函式或I/O通道等等），通過一系列計算步驟得到；
• 天然的函式式風格（Functional in nature）：對流的操作會產生一個結果，但流的資料來源不會被修改；
• 惰性求值：多數流操作（包括過濾、對映、排序以及去重）都可以以惰性方式實現。這使得我們可以用一遍遍歷完成整個流水線操作，並可以用短路操作提供更高效的實現；
• 無需上界（Bounds optional）：不少問題都可以被表達為無限流（infinite stream）：使用者不停地讀取流直到滿意的結果出現為止（比如說，列舉 完美數這個操作可以被表達為在所有整數上進行過濾）。集合是有限的，但流不是（操作無限流時我們必需使用短路操作，以確保操作可以在有限時間內完成）；

從API的角度來看，流和集合完全互相獨立，不過我們可以既把集合作為流的資料來源（ Collection擁有 stream()和 parallelStream()方法），也可以通過流產生一個集合（使用前例的 collect()方法）。 Collection以外的型別也可以作為 stream的資料來源，比如JDK中的 BufferedReader、 Random和 BitSet已經被改造可以用做流的資料來源， Arrays.stream()則產生給定陣列的流檢視。事實上，任何可以用 Iterator描述的物件都可以成為流的資料來源，如果有額外的資訊（比如大小、是否有序等特性），庫還可以進行進一步的優化。

惰性（Laziness）

過濾和對映這樣的操作既可以被 急性求值（以 filter為例，急性求值需要在方法返回前完成對所有元素的過濾），也可以被 惰性求值（用 Stream代表過濾結果，當且僅當需要時才進行過濾操作）在實際中進行惰性運算可以帶來很多好處。比如說，如果我們進行惰性過濾，我們就可以把過濾和流水線裡的其它操作混合在一起，從而不需要對資料進行多遍遍歷。相類似的，如果我們在一個大型集合裡搜尋第一個滿足某個條件的元素，我們可以在找到後直接停止，而不是繼續處理整個集合。（這一點對無限資料來源是很重要，惰性求值對於有限資料來源起到的是優化作用，但對無限資料來源起到的是決定作用，沒有惰性求值，對無限資料來源的操作將無法終止）

對於過濾和對映這樣的操作，我們很自然的會把它當成是惰性求值操作，不過它們是否真的是惰性取決於它們的具體實現。另外，像 sum()這樣生成值的操作和 forEach()這樣產生副作用的操作都是“天然急性求值”，因為它們必須要產生具體的結果。

以下面的流水線為例：

int sum = shapes.stream()
                .filter(s -> s.getColor() == BLUE)
                .mapToInt(s -> s.getWeight())
                .sum();

這裡的過濾操作和對映操作是惰性的，這意味著在呼叫 sum()之前，我們不會從資料來源提取任何元素。在 sum操作開始之後，我們把過濾、對映以及求和混合在對資料來源的一遍遍歷之中。這樣可以大大減少維持中間結果所帶來的開銷。

大多數迴圈都可以用資料來源（陣列、集合、生成函式以及I/O管道）上的聚合操作來表示：進行一系列惰性操作（過濾和對映等操作），然後用一個急性求值操作（ forEach， toArray和 collect等操作）得到最終結果——例如過濾—對映—累積，過濾—對映—排序—遍歷等組合操作。惰性操作一般被用來計算中間結果，這在Streams API設計中得到了很好的體現——與其讓 filter和 map返回一個集合，我們選擇讓它們返回一個新的流。在Streams API中，返回流物件的操作都是惰性操作，而返回非流物件的操作（或者無返回值的操作，例如 forEach()）都是急性操作。絕大多數情況下，潛在的惰性操作會被用於聚合，這正是我們想要的——流水線中的每一輪操作都會接收輸入流中的元素，進行轉換，然後把轉換結果傳給下一輪操作。

在使用這種 資料來源—惰性操作—惰性操作—急性操作流水線時，流水線中的惰性幾乎是不可見的，因為計算過程被夾在資料來源和最終結果（或副作用操作）之間。這使得API的可用性和效能得到了改善。

對於 anyMatch(Predicate)和 findFirst()這些急性求值操作，我們可以使用短路（short-circuiting）來終止不必要的運算。以下面的流水線為例：

Optional<Shape> firstBlue = shapes.stream()
                                  .filter(s -> s.getColor() == BLUE)
                                  .findFirst();

由於過濾這一步是惰性的， findFirst在從其上游得到一個元素之後就會終止，這意味著我們只會處理這個元素及其之前的元素，而不是所有元素。 findFirst()方法返回 Optional物件，因為集合中有可能不存在滿足條件的元素。 Optional是一種用於描述可缺失值的型別。

在這種設計下，使用者並不需要顯式進行惰性求值，甚至他們都不需要了解惰性求值。類庫自己會選擇最優化的計算方式。

並行（Parallelism）

流水線既可以序列執行也可以並行執行，並行或序列是流的屬性。除非你顯式要求使用並行流，否則JDK總會返回序列流。（序列流可以通過 parallel()方法被轉化為並行流）

儘管並行是顯式的，但它並不需要成為侵入式的。利用 parallelStream()，我們可以輕鬆的把之前重量求和的程式碼並行化：

int sum = shapes.parallelStream()
                .filter(s -> s.getColor = BLUE)
                .mapToInt(s -> s.getWeight())
                .sum();

並行化之後和之前的程式碼區別並不大，然而我們可以很容易看出它是並行的（此外我們並不需要自己去實現並行程式碼）。

因為流的資料來源可能是一個可變集合，如果在遍歷流時資料來源被修改，就會產生干擾（interference）。所以在進行流操作時，流的資料來源應保持不變（held constant）。這個條件並不難維持，如果集合只屬於當前執行緒，只要lambda表示式不修改流的資料來源就可以。（這個條件和遍歷集合時所需的條件相似，如果集合在遍歷時被修改，絕大多數的集合實現都會丟擲 ConcurrentModificationException）我們把這個條件稱為無干擾性（non-interference）。

我們應避免在傳遞給流方法的lambda產生副作用。一般來說，列印除錯語句這種輸出變數的操作是安全的，然而在lambda表示式裡訪問可變變數就有可能造成資料競爭或是其它意想不到的問題，因為lambda在執行時可能會同時執行在多個執行緒上，因而它們所看到的元素有可能和正常的順序不一致。無干擾性有兩層含義：

1. 不要干擾資料來源；
2. 不要干擾其它lambda表示式，當一個lambda在修改某個可變狀態而另一個lambda在讀取該狀態時就會產生這種干擾。

只要滿足無干擾性，我們就可以安全的進行並行操作並得到可預測的結果，即便對執行緒不安全的集合（例如 ArrayList）也是一樣。

例項（Examples）

下面的程式碼源自JDK中的 Class型別（ getEnclosingMethod方法），這段程式碼會遍歷所有宣告的方法，然後根據方法名稱、返回型別以及引數的數量和型別進行匹配：

for (Method method : enclosingInfo.getEnclosingClass().getDeclaredMethods()) {
  if (method.getName().equals(enclosingInfo.getName())) {
    Class< ? >[] candidateParamClasses = method.getParameterTypes();
    if (candidateParamClasses.length == parameterClasses.length) {
      boolean matches = true;
      for (int i = 0; i < candidateParamClasses.length; i += 1) {
        if (!candidateParamClasses[i].equals(parameterClasses[i])) {
          matches = false;
          break;
        }
      }
      if (matches) { // finally, check return type
        if (method.getReturnType().equals(returnType)) {
          return method;
        }
      }
    }
  }
}
throw new InternalError("Enclosing method not found");

通過使用流，我們不但可以消除上面程式碼裡面所有的臨時變數，還可以把控制邏輯交給類庫處理。通過反射得到方法列表之後，我們利用 Arrays.stream將它轉化為 Stream，然後利用一系列過濾器去除型別不符、引數不符以及返回值不符的方法，然後通過呼叫 findFirst得到 Optional<Method>，最後利用 orElseThrow返回目標值或者丟擲異常。

return Arrays.stream(enclosingInfo.getEnclosingClass().getDeclaredMethods())
             .filter(m -> Objects.equal(m.getName(), enclosingInfo.getName()))
             .filter(m -> Arrays.equal(m.getParameterTypes(), parameterClasses))
             .filter(m -> Objects.equals(m.getReturnType(), returnType))
             .findFirst()
             .orElseThrow(() -> new InternalError("Enclosing method not found"));

相對於未使用流的程式碼，這段程式碼更加緊湊，可讀性更好，也不容易出錯。

流操作特別適合對集合進行查詢操作。假設有一個“音樂庫”應用，這個應用裡每個庫都有一個專輯列表，每張專輯都有其名稱和音軌列表，每首音軌表都有名稱、藝術家和評分。

假設我們需要得到一個按名字排序的專輯列表，專輯列表裡面的每張專輯都至少包含一首四星及四星以上的音軌，為了構建這個專輯列表，我們可以這麼寫：

List<Album> favs = new ArrayList<>();
for (Album album : albums) {
  boolean hasFavorite = false;
  for (Track track : album.tracks) {
    if (track.rating >= 4) {
      hasFavorite = true;
      break;
    }
  }
  if (hasFavorite)
    favs.add(album);
}
Collections.sort(favs, new Comparator<Album>() {
  public int compare(Album a1, Album a2) {
    return a1.name.compareTo(a2.name);
  }
});

我們可以用流操作來完成上面程式碼中的三個主要步驟——識別一張專輯是否包含一首評分大於等於四星的音軌（使用 anyMatch）；按名字排序；以及把滿足條件的專輯放在一個 List中：

List<Album> sortedFavs =
    albums.stream()
          .filter(a -> a.tracks.anyMatch(t -> (t.rating >= 4)))
          .sorted(Comparator.comparing(a -> a.name))
          .collect(Collectors.toList());

Compartor.comparing方法接收一個函式（該函式返回一個實現了 Comparable介面的排序鍵值），然後返回一個利用該鍵值進行排序的 Comparator（請參考下面的比較器工廠一節）。

收集器（Collectors）

在之前的例子中，我們利用 collect()方法把流中的元素聚合到 List或 Set中。 collect()接收一個型別為 Collector的引數，這個引數決定了如何把流中的元素聚合到其它資料結構中。 Collectors類包含了大量常用收集器的工廠方法， toList()和 toSet()就是其中最常見的兩個，除了它們還有很多收集器，用來對資料進行對複雜的轉換。

Collector的型別由其輸入型別和輸出型別決定。以 toList()收集器為例，它的輸入型別為 T，輸出型別為 List<T>， toMap是另外一個較為複雜的 Collector，它有若干個版本。最簡單的版本接收一對函式作為輸入，其中一個函式用來生成鍵（key），另一個函式用來生成值（value）。 toMap的輸入型別是 T，輸出型別是 Map<K, V>，其中 K和 V分別是前面兩個函式所生成的鍵型別和值型別。（複雜版本的 toMap收集器則允許你指定目標 Map的型別或解決鍵衝突）。舉例來說，下面的程式碼以目錄數字為鍵值建立一個倒排索引：

Map<Integer, Album> albumsByCatalogNumber =
    albums.stream()
          .collect(Collectors.toMap(a -> a.getCatalogNumber(), a -> a));

groupingBy是一個與 toMap相類似的收集器，比如說我們想要把我們最喜歡的音樂按歌手列出來，這時我們就需要這樣的 Collector：它以 Track作為輸入，以 Map<Artist, List<Track>>作為輸出。 groupingBy收集器就可以勝任這個工作，它接收分類函式（classification function），然後根據這個函式生成 Map，該 Map的鍵是分類函式的返回結果，值是該分類下的元素列表。

Map<Artist, List<Track>>favsByArtist =
    tracks.stream()
          .filter(t -> t.rating >= 4)
          .collect(Collectors.groupingBy(t -> t.artist));

收集器可以通過組合和複用來生成更加複雜的收集器，簡單版本的 groupingBy收集器把元素按照分類函式為每個元素計算出分類鍵值，然後把輸入元素輸出到對應的分類列表中。除了這個版本，還有一個更加通用（general）的版本允許你使用 其它收集器來整理輸入元素：它接收一個分類函式以及一個下流（downstream）收集器（單引數版本的 groupingBy使用 toList()作為其預設下流收集器）。舉例來說，如果我們想把每首歌曲的演唱者收集到 Set而非 List中，我們可以使用 toSet收集器：

Map<Artist, Set<Track>>favsByArtist =
    tracks.stream()
          .filter(t -> t.rating >= 4)
          .collect(Collectors.groupingBy(t -> t.artist,
                                         Collectors.toSet()));

如果我們需要按照歌手和評分來管理歌曲，我們可以生成多級 Map：

Map<Artist, Map<Integer, List<Track>>> byArtistAndRating =
    tracks.stream()
          .collect(groupingBy(t -> t.artist,
                              groupingBy(t -> t.rating)));

在最後的例子裡，我們建立了一個歌曲標題裡面的詞頻分佈。我們首先使用 Stream.flatMap()得到一個歌曲流，然後用 Pattern.splitAsStream把每首歌曲的標題打散成詞流；接下來我們用 groupingBy和 String.toUpperCase對這些詞進行不區分大小寫的分組，最後使用 counting()收集器計算每個詞出現的次數（從而無需建立中間集合）。

Pattern pattern = Pattern.compile("\\s+");
Map<String, Integer> wordFreq =
    tracks.stream()
          .flatMap(t -> pattern.splitAsStream(t.name)) // Stream<String>
          .collect(groupingBy(s -> s.toUpperCase(),
                              counting()));

flatMap接收一個返回流（這裡是歌曲標題裡的詞）的函式。它利用這個函式將輸入流中的每個元素轉換為對應的流，然後把這些流拼接到一個流中。所以上面程式碼中的 flatMap會返回所有歌曲標題裡面的詞，接下來我們不區分大小寫的把這些詞分組，並把詞頻作為值（value）儲存。

Collectors類包含大量的方法，這些方法被用來創造各式各樣的收集器，以便進行查詢、列表（tabulation）和分組等工作，當然你也可以實現一個自定義 Collector。

並行的實質（Parallelism under the hood）

Java SE 7引入了 Fork/Join模型，以便高效實現平行計算。不過，通過Fork/Join編寫的並行程式碼和同功能的序列程式碼的差別非常巨大，這使改寫序列程式碼變的非常困難。通過提供序列流和並行流，使用者可以在序列操作和並行操作之間進行便捷的切換（無需重寫程式碼），從而使得編寫正確的並行程式碼變的更加容易。

為了實現平行計算，我們一般要把計算過程遞迴分解（recursive decompose）為若干步：

• 把問題分解為子問題；
• 序列解決子問題從而得到部分結果（partial result）；
• 合併部分結果合為最終結果。

這也是Fork/Join的實現原理。

為了能夠並行化任意流上的所有操作，我們把流抽象為 Spliterator， Spliterator是對傳統迭代器概念的一個泛化。分割迭代器（spliterator）既支援順序依次訪問資料，也支援分解資料：就像 Iterator允許你跳過一個元素然後保留剩下的元素， Spliterator允許你把輸入元素的一部分（一般來說是一半）轉移（carve off）到另一個新的 Spliterator中，而剩下的資料則會被儲存在原來的 Spliterator裡。（這兩個分割迭代器還可以被進一步分解）除此之外，分割迭代器還可以提供源的元資料（比如元素的數量，如果已知的話）和其它一系列布林值特徵（比如說“元素是否被排序”這樣的特徵），Streams框架可以利用這些資料來進行優化。

上面的分解方法也同樣適用於其它資料結構，資料結構的作者只需要提供分解邏輯，然後就可以直接享用並行流操作帶來的遍歷。

大多數使用者無需去實現 Spliterator介面，因為集合上的 stream()方法往往就足夠了。但如果你需要實現一個集合或一個流，那麼你可能需要手動實現 Spliterator介面。 Spliterator介面的API如下所示：

public interfaceSpliterator<T>{
  // Element access
  booleantryAdvance(Consumer<?superT>action);
  voidforEachRemaining(Consumer<?superT>action);
  // Decomposition
  Spliterator<T>trySplit();
  //Optional metadata
  longestimateSize();
  intcharacteristics();
  Comparator< ? super T> getComparator();
}

集合庫中的基礎介面 Collection和 Iterable都實現了正確但相對低效的 spliterator()實現，但派生介面（例如 Set）和具體實現類（例如 ArrayList）均提供了高效的分割迭代器實現。分割迭代器的實現質量會影響到流操作的執行效率；如果在 split()方法中進行良好（平衡）的劃分，CPU的利用率會得到改善；此外，提供正確的特性（characteristics）和大小（size）這些元資料有利於進一步優化。

出現順序（Encounter order）

多數資料結構（例如列表，陣列和I/O通道）都擁有 自然出現順序（natural encounter order），這意味著它們的元素出現順序是可預測的。其它的資料結構（例如 HashSet）則沒有一個明確定義的出現順序（這也是 HashSet的 Iterator實現中不保證元素出現順序的原因）。

是否具有明確定義的出現順序是 Spliterator檢查的特性之一（這個特性也被流使用）。除了少數例外（比如 Stream.forEach()和 Stream.findAny()），並行操作一般都會受到出現順序的限制。這意味著下面的流水線：

List<String> names = people.parallelStream()
                           .map(Person::getName)
                           .collect(toList()   
 
  
 

            
  
           

              
              
            
            
相關推薦
			   
            
            
            
 

    

    
    
深入理解Java 8 Lambda（類庫篇——Streams API，Collectors和並行）
     
 
作者：Lucida 
微博：@peng_gong 
本文謝絕轉載，如需轉載需徵得作者本人同意，謝謝。
本文是深入理解Java 8 Lambda系列的第二篇，主要介紹Java 8針對新增語言特性而新增的類庫（例如Streams API、Collectors和並行）。

關於 
Java SE 8增加了新的語言 

  
 

    

    
    
Java 8 Lambda（類庫篇——Streams API，Collector和並行）
     
 
                參考資料：1、背景自從lambda表示式成為Java語言的一部分之後，Java集合（Collections）API就面臨著大幅變化。為了不推到重來，所以對現有的API進行改進。為現有的介面（例如Collection，List和Stream）增加擴充套件方法；在類庫中增加新的流 

  
 

    

    
    
深入理解Java 8 Lambda（語言篇）
     
 
                


原文連結：http://lucida.me/blog/java-8-lambdas-insideout-language-features/


關於

本文介紹了 Java SE 8 中新引入的 lambda 語言特性以及這些特性背後的設計思想。這些特性包括：

la 

  
 

    

    
    
深入理解Java 8 Lambda 語言篇 類庫篇
     
  
 
 http://zh.lucida.me/blog/java-8-lambdas-insideout-language-features/ 
 http://zh.lucida.me/blog/java-8-lambdas-inside-out-library-features/  
   
   
 

  
 

    

    
    
深入理解Java虛擬機（類文件結構+類加載機制+字節碼執行引擎）
     
 本地變量   ber   關鍵字   作者   看書   講解   個數   寫入   class類   周誌明的《深入理解Java虛擬機》很好很強大，閱讀起來頗有點費勁，尤其是當你跟隨作者的思路一直探究下去，開始會讓你弄不清方向，難免有些你說的啥子的感覺。但知識不得不學，於是天天看，反復看，就慢慢的理解了。 

  
 

    

    
    
深入理解Java虛擬機器（類檔案結構+類載入機制+位元組碼執行引擎）
     
 周志明的《深入理解Java虛擬機器》很好很強大，閱讀起來頗有點費勁，尤其是當你跟隨作者的思路一直探究下去，開始會讓你弄不清方向，難免有些你說的啥子的感覺。但知識不得不學，於是天天看，反覆看，就慢慢的理解了。我其實不想說這種硬磨的方法有多好，我甚至不推薦，我建議大家閱讀這本書時，由淺入深，有舍有得，先從巨集觀去 

  
 

    

    
    
深入理解Java虛擬機器（類檔案結構）
     
 深入理解Java虛擬機器（類檔案結構）

歡迎關注微信公眾號：BaronTalk，獲取更多精彩好文！

之前在閱讀 ASM 文件時，對於已編譯類的結構、方法描述符、訪問標誌、ACC_PUBLIC、ACC_PRIVATE、各種位元組碼指令等等許多概念聽起來都是雲山霧罩、一知半解，原因就在於對類檔案結構和 

  
 

    

    
    
視訊：深入理解Java虛擬機器（jvm效能調優+記憶體模型+虛擬機器原理）共110集
     
 
            龍果學院深入理解Java虛擬機器（Jvm效能調優+記憶體模型+虛擬機器原視訊
Java虛擬機器視訊教程一套不錯的視訊，課程一共有110課，課程目錄較多隻展示部分出來，喜歡的朋友下載看下
課程目錄（課程較多，只展示部分目錄）
課程大綱
第1節說在前面的話 [免費觀看]          

  
 

    

    
    
深入理解Java虛擬機器（二）——類載入器深入解析
     
 
								
								            
						
                類載入過程

•類載入：類載入器將class檔案載入到虛擬機器的記憶體 

•載入：在硬碟上查詢並通過IO讀入位元組碼檔案

•連線：執行校驗、準備、解析（可選）步驟

•校驗：校驗位元組碼檔案的正確性 

  
 

    

    
    
深入理解java虛擬機器（三）（一個類載入器只初始化一次類物件,不同類載入器可以對同一類物件進行初始化）
     
 
                
package com.ygl;
class Final{public static final int x=6/3;//此處x在編譯時能計算出值，是編譯時的常量，則System.out.println(Final.x);直接輸出值，不再執行下面static（前提是fina 

  
 

    

    
    
深入理解JAVA虛擬機器（四）：虛擬機器類載入機制
     
 
                
虛擬機器把描述類的資料從Class檔案載入到記憶體，並對資料進行校驗、轉換解析和初始化，最終形成可以被虛擬機器直接使用的Java型別，這就是虛擬機器的類載入機制。在Java語言裡面，型別的載入、連線和初始化過程都是在程式執行期間完成的。
1、類載入的時機
類從被載入到虛擬機 

  
 

    

    
    
深入理解java虛擬機器（七）類載入的時機
     
 
                
Class 檔案中描述的各種資訊都必須載入到虛擬機器中才能執行和使用。而虛擬機器怎麼載入這些Class 檔案呢？Class 檔案進入到虛擬機器中會發生什麼變化呢？
虛擬機器類載入機制是指 虛擬機器把描述類的資料從 Class 檔案載入到記憶體中，並對資料進行校驗、轉換解析、 

  
 

    

    
    
深入理解Java：註解（Annotation）--註解處理器
     
 fault   this   urn   復制代碼   lena   ide   set   java   lec   

深入理解Java：註解（Annotation）--註解處理器

　　如果沒有用來讀取註解的方法和工作，那麽註解也就不會比註釋更有用處了。使用註解的過程中，很重要的一部分就是創建於 

  
 

    

    
    
深入理解Java的註解（Annotation）：註解處理器（3）
     
 isp   通過反射   out   peid   擴展   .cn   自定義註解   忽略   否則   如果沒有用來讀取註解的方法和工作，那麽註解也就不會比註釋更有用處了。使用註解的過程中，很重要的一部分就是創建於使用註解處理器。Java SE5擴展了反射機制的API，以幫助程序員快速的構造自定義註解處 

  
 

    

    
    
深入理解Java虛擬機（jvm性能調優+內存模型+虛擬機原理）視頻教程
     
 boot   operate   小型   spa   clas   padding   ali   restful   left   
14套java精品高級架構課，緩存架構，深入Jvm虛擬機，全文檢索Elasticsearch，Dubbo分布式Restful 服務，並發原理編程，SpringBoot，Sp 

  
 

    

    
    
深入理解java虛擬機（十二） Java 語法糖背後的真相
     
 它的   blog   需要   原來   ont   影響   else   階段   board   語法糖（Syntactic Sugar），也叫糖衣語法，是英國計算機科學家彼得·約翰·蘭達(Peter J. Landin)發明的一個術語。指的是，在計算機語言中添加某種語法，這些語法糖雖然不會對語言的功 

  
 

    

    
    
深入理解Java虛擬機（筆記）
     
 包括   指針   思想   創建   區域   算法；   很多   由於   線程安全   內存分配：
　　為對象分配內存有兩種方式，第一種是“指針碰撞”，也就是把內存分為兩邊，一邊是已使用區域，另一邊是未分配區域，分界線用指針記錄，當要分配內存時，只需把指針向未分配區域移動需要的空間即可，通常compa 

  
 

    

    
    
深入理解Java虛擬機（jvm性能調優+內存模型+虛擬機原理）
     
 Java 課程大綱:第1節說在前面的話   00:05:07分鐘第2節整個部分要講的內容說明   00:06:58分鐘第3節環境搭建以及jdk,jre,jvm的關系   00:20:48分鐘第4節jvm初體驗-內存溢出問題的分析與解決   00:17:59分鐘第5節jvm再體驗-jvm可視化監控工具   00 

  
 

    

    
    
深入理解java虛擬機器（六）位元組碼指令簡介
     
 Java虛擬機器指令是由（佔用一個位元組長度、代表某種特定操作含義的數字）操作碼Opcode，以及跟隨在其後的零至多個代表此操作所需引數的稱為運算元 Operands 構成的。由於Java虛擬機器是面向運算元棧而不是暫存器的架構，所以大多數指令都只有操作碼，而沒有運算元。 
位元組碼指令集是一種具有鮮明特點、 

  
 

    

    
    
深入理解java虛擬機器（一）java虛擬機器的記憶體區域
     
  
 
 
 一、 java虛擬機器記憶體區域主要有:方法區、堆、虛擬機器棧、本地方方法棧、程式計數器 
     按照執行緒私有和共有來分：執行緒私有的有--程式計數器，虛擬機器棧，本地方法棧。共有的有--本地方法區，堆 
     1、程式計數器：主要功能是控制程式