偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

JVM 君,你是不過分了

云計算 虛擬化
如果你還沒意識到學 JVM 的必要性,或者不知道怎么學 JVM,那么看完這篇文章,你就能知道答案了。曾經(jīng)的我很不屑于學 JVM,但是后來發(fā)現(xiàn)不學不行。這就像和媳婦吵架之后我不想道歉一樣,不道歉那是不可能的,道歉是早晚的事兒,逃不掉。

 [[410405]]

JVM 對 Java 有多重要,對程序員面試有多重要,這些不用多說。

如果你還沒意識到學 JVM 的必要性,或者不知道怎么學 JVM,那么看完這篇文章,你就能知道答案了。

曾經(jīng)的我很不屑于學 JVM,但是后來發(fā)現(xiàn)不學不行。這就像和媳婦吵架之后我不想道歉一樣,不道歉那是不可能的,道歉是早晚的事兒,逃不掉。

后來我明白了:

認慫越晚,結(jié)局越慘。

但是我學的時候才知道:JVM,你太過分了,太難學了!

我的學習過程可以說非??部?,不過經(jīng)歷坎坷之后,我倒是發(fā)現(xiàn)學 JVM 的門道很多。

以我的經(jīng)驗加上和同行們的交流,我認為學 JVM 最好的方法是:

在程序員不同的水平段,做精準的學習。

所謂的精準學習,就是學習對自己工作有巨大幫助的知識點。以工作內(nèi)容帶動學習,等到積累多了,再一舉攻克所有 JVM 知識點,最終熟練掌握 JVM 底層原理。

下面我來說說初級、高級、資深程序員,如何循序漸進、分步學習。

初級程序員怎么學

對剛?cè)胄械男率殖绦騿T,工作一般是修復簡單 bug、開發(fā)簡單功能。如何編碼少出 bug,是這個階段的核心問題。

對于這個核心問題,JVM 原理必須深入掌握兩個知識點。

1. 類的初始化

類的初始化,要了解的非常深入才可以。否則,一不留神就會往項目里引入一些有關初始化的 bug。

比如看看下面這段代碼:

  1. public class ParentClass { 
  2.     private int parentX; 
  3.     public ParentClass() { 
  4.         setX(100); 
  5.     } 
  6.     public void setX(int x) { 
  7.         parentX = x; 
  8.     } 
  9.  
  10. public class ChildClass extends ParentClass{ 
  11.     private int childX = 1; 
  12.     public ChildClass() {} 
  13.     @Override 
  14.     public void setX(int x) { 
  15.         super.setX(x); 
  16.         childX = x; 
  17.         System.out.println("ChildX 被賦值為 " + x); 
  18.     } 
  19.     public void printX() { 
  20.         System.out.println("ChildX = " + childX); 
  21.     } 
  22.  
  23.  
  24. public class TryInitMain { 
  25.     public static void main(String[] args) { 
  26.         ChildClass cc = new ChildClass(); 
  27.         cc.printX(); 
  28.     } 

有興趣可以運行看看結(jié)果,一旦把這種代碼放到了生產(chǎn)環(huán)境里,排查非常困難。

2. Java 內(nèi)存結(jié)構和對象分配

第二個知識點,就是 Java 內(nèi)存結(jié)構和對象分配的基礎知識,尤其是 JVM 內(nèi)存中堆的布局和對象分配的關系。

比如,堆內(nèi)存的布局

當然,Java7 后,新布局變了

知道布局了,就得知道java對象分配的基本原則:

  • 對象優(yōu)先在Eden區(qū)分配
  • 對象太大直接會分配到老年代

只有知道這些知識,才不會經(jīng)常寫下底下這種 bug:

  1. // 將全部行數(shù)讀取的內(nèi)存中  
  2. List<String> lines = FileUtils.readLines(new File("temp/test.txt"), Charset.defaultCharset());  
  3. for (String line : lines) {  
  4.     // pass  
  5. }  

上面這段代碼,一旦讀取到了大文件,很可能把生產(chǎn)環(huán)境搞崩。

所以,把上述兩個知識點深入理解了,對新手提升自己的代碼質(zhì)量非常非常有用。只有代碼質(zhì)量上去了,你才能得到更好的發(fā)展。

對于這兩個知識點,我認為通過網(wǎng)絡的文章去學習最好。如果直接看書,有兩個最大的缺點:

  • 知識積累不足導致學不懂
  • 書中冗余知識點太多,互相交雜,精力耗費過大,性價比不高

故這里學習推薦根據(jù)知識點去搜文章讀,而不是找原理性的書籍看。

高級程序員怎么學

對處于這個階段的朋友,他們已經(jīng)可以熟練編寫健壯的代碼了,經(jīng)常會獨立開發(fā)出一個大的功能模塊,有的可能還能獨立開發(fā)出一個完整的小型項目。

這時候,他們可能會面臨兩種情況:

1. 需要寫一些工具類給全團隊使用

在這種情況下,你很可能就需要 Java 中的語法糖,因為語法糖能讓你寫出非常靈活簡單的代碼。這包括泛型,自動拆裝箱,可變參數(shù)還有遍歷循環(huán)。

但是,使用這些語法糖的時候,如果你不熟悉他們在 JVM 中的實現(xiàn)原理,就非常容易栽個大跟頭,

比如:

  1. public class GenericPitfall { 
  2.     public static void main(String[] args) { 
  3.       List list = new ArrayList(); 
  4.       list.add("123"); 
  5.       List<Integer>  list2 = list; 
  6.       System.out.println(list2.get(0).intValue()); 
  7.   } 

2. 編寫性能優(yōu)越的代碼

什么時候需要性能優(yōu)越的代碼?最常見的就是把以前性能不好的同步實現(xiàn),轉(zhuǎn)化成異步實現(xiàn)。

而這種要求,就需要開發(fā)對 Java 的多線程開發(fā)非常熟悉,并且一定要深入理解多線程在 JVM 中的原理實現(xiàn)。

不然,可以看看下面這段代碼:

  1. class IncompletedSynchronization { 
  2.   int x; 
  3.  
  4.   public int getX() { 
  5.       return x; 
  6.   } 
  7.  
  8.   public synchronized void setX(int x) { 
  9.       this.x = x; 
  10.   } 

再看看這段:

  1. Object lock = new Object(); 
  2. synchronized (lock) { 
  3.   lock = new Object(); 

如果把上面這些代碼上了生產(chǎn)環(huán)境,熬通宵排查問題的命運就注定了……

這里的知識點,我推薦通過網(wǎng)上的文章看,又因為涉及到了并發(fā)知識,我建議就著《Java Performance》第二版的“Chapter 9. Threading and Synchronization Performance”這章一起看。

還有余力,建議再繼續(xù)看周志明的那本《深入理解 JAVA 虛擬機》第三版中的 12-13 章。周志明這本書講的十分深入,也帶來個缺點:門檻高。此時,如果沒看懂可以放一放。

注意,我這里說的是并發(fā)的原理,不是并發(fā)實踐,讀者想學并發(fā)編程,《JAVA 并發(fā)編程實踐》我認為是前提條件,故不會贅述。

資深程序員怎么學

這時候的你,已經(jīng)開始承擔項目開發(fā)中很重要的職責了,有些出色的朋友都開始帶團隊了。那這時候,你可能會做下面的事:

1. 合理規(guī)劃項目使用資源

合理規(guī)劃項目使用資源,前提是對垃圾回收有非常深入的了解。

如果說在新手期,已經(jīng)對 Java 對象的內(nèi)存分配和內(nèi)存使用有了大致的概念,那么,這個垃圾回收,則是這類知識的進一步拓展。

只有理解了各種垃圾回收的原理,再配合著 Java 內(nèi)存布局的基礎知識,才能更好地規(guī)劃出項目用什么回收算法,才能在合適的資源利用度上得到最佳性能。

比如,新生代和老年代之間的合適比例。比如,新生代中 Eden 和 Survivor 區(qū)域間的比例。

2. 排查各種線上問題

要排查各種問題,就需要對 JVM 提供的各種故障排查工具非常了解。

這些工具又分為兩類:

  • 基礎的命令行形式的故障處理工具,比如 jps、jstack 等等
  • 第二類是可視化的故障處理工具,比如 VisualVM

但是,掌握工具的使用還不夠。因為有關垃圾回收的問題,還必須得通過解析 GC 日志后,再通過工具的使用,才可能能定位到問題的根源。

所以,最好對使用故障排查工具和 GC 日志都非常熟練。

比如:

  1. 2021-05-26T14:45:37.987-0200: 151.126: 
  2. [GC (Allocation Failure) 151.126: [DefNew: 629119K->69888K(629120K), 0.0584157 secs] 1619346K->1273247K(2027264K), 0.0585007 secs] 
  3. [Times: user=0.06 sys=0.00, real=0.06 secs] 
  4.  
  5. 2021-05-26T14:45:59.690-0200: 172.829: 
  6. [GC (Allocation Failure) 172.829: [DefNew: 629120K->629120K(629120K), 0.0000372 secs]172.829: [Tenured: 1203359K->755802K(1398144K), 0.1855567 secs] 1832479K->755802K(2027264K), [Metaspace: 6741K->6741K(1056768K)], 0.1856954 secs] 
  7. [Times: user=0.18 sys=0.00, real=0.18 secs] 

上面這條,應該一眼看出來,垃圾算法用的是 Serial 收集器,并且年輕代分配出現(xiàn)了問題,大小可能需要調(diào)整。

這里的知識點,強烈反對看網(wǎng)上的文章,網(wǎng)上說的很多細節(jié)有問題,疏漏很多。所以,推薦看書。

《Java Performance》第二版里,“Chapter 5. An Introduction to Garbage Collection”,“Chapter 6. Garbage Collection Algorithms”的知識已經(jīng)足夠。

有人去看《深入理解 JAVA 虛擬機》第三版中的第 3 章,講垃圾收集器與內(nèi)存分配策略的。這里還是老問題,講的太細,我建議繞過 3.4 節(jié),講 HotSpot 算法細節(jié)的那塊兒。

這里安全點這個知識點挺重要,但是現(xiàn)在這個階段想理解挺難的。我覺得將來做一些底層框架,接觸到崩潰恢復的 checkpoint 相關思想了,再回頭來學習,那才能真正理解和掌握。

技術專家怎么學

達到這個級別了,那就需要對整套 JVM 要有非常深入的了解了,因為你是解決技術問題的最后保障了。有些時候,甚至還需要因為某些問題開發(fā)出各種各樣的工具。

曾經(jīng),有個項目時不時總是會報錯:

  1. java.lang.OutOfMemoryError: GC overhead limit exceeded 

這個問題幾個同事都沒搞定,就來找我。我看了看,突然想起來,以前在官方調(diào)優(yōu)指南《HotSpot Virtual Machine Garbage Collection Tuning Guide》看到過相關介紹。

JVM 本身內(nèi)存不足就會運行 GC,但是如果每次 GC 回收的內(nèi)存不夠,那么很快就會開始下一次 GC。

JVM 有個默認的保護機制,如果發(fā)現(xiàn)在一個統(tǒng)計周期內(nèi),98% 的時間都是在運行 GC,內(nèi)存回收卻少于 2% 的時候,就會報這個錯。

怎么引起的呢?這個問題如果去排查代碼,那真的是難如登天,首先,沒有任何堆棧錯誤去幫助定位問題。其次,項目代碼量大了去了,而且是年頭久遠。

這時,就需要通過對 JVM 總體的深入理解,去反推問題了。我當時是這樣推理的:

內(nèi)存溢出,GC 無法回收問題,說明了兩個問題:

  • 堆內(nèi)的內(nèi)存不夠用了
  • 占用內(nèi)存的對象要么就是該關閉的資源沒有關閉,要么被大量的暫時放在一起了

那如果我 dump 出內(nèi)存文件出來,再分析下就知道是哪些對象在占用內(nèi)存了。

一查發(fā)現(xiàn)是大量的字符串在占用內(nèi)存。

綜合我前面的推測,字符串不是數(shù)據(jù)庫連接,肯定沒有該關閉未關閉的問題。那就剩一個可能了,就是被大量的暫時放起來了,導致 GC 回收不了。

那么新問題來了,能大量放字符串的,會是什么?

首先就去猜緩存。根據(jù)這條線索,直接去源碼搜 Cache 關鍵詞,把所有關于 Cache 的代碼都看了下。一下子就找到問題了。

原來,我們有個功能是解析一個非常大的文件。文件的格式如下:

需要把這個文件的每一行內(nèi)容按照列去一起存到數(shù)據(jù)庫里。

由于寫代碼的人偷懶,想一次解析完畢后一股腦全塞到數(shù)據(jù)庫里。所以,他弄了個 Map,Map 的 Key 是相同的列名,Value是每一行解析過的內(nèi)容。

而這樣寫代碼的結(jié)果就是,一行對應了一個有三個條目的 HashMap。如果文件有十幾萬行,就有十幾萬的 HashMap。然后,這些 HashMap 再存到一個列表里,再把這個列表放到一個叫做 xxxCache 的 HashMap 中。

示意代碼如下:

  1. public class ParseFile4OOM { 
  2.     public static void main(String[] args) { 
  3.         List<Map<String, String>> lst = new ArrayList<>(); 
  4.         for (int i = 0; i < 100000; i++) { 
  5.             Map<String, String> map = new HashMap<>(); 
  6.             map.put("Column1""Content1"); 
  7.             map.put("Column2""Content2"); 
  8.             map.put("Column3""Content3"); 
  9.             lst.add(map); 
  10.         } 
  11.  
  12.         Map<String, List<Map<String, String>>> contentCache = new HashMap<>(); 
  13.         contentCache.put("contents", lst); 
  14.     } 

那對這種情況怎么辦呢?代碼還不能大動,只能優(yōu)化。

那時,我們已經(jīng)用了 JDK8 了,引入了 String 常量池。同時,Hashmap 在這個業(yè)務場景下,容積是固定的,所以,就不應該給它多分配空間,就固定死為 3。

優(yōu)化后,代碼如下:

  1. public class ParseFile4OOM { 
  2.     public static void main(String[] args) { 
  3.         List<Map<String, String>> lst = new ArrayList<>(); 
  4.         for (int i = 0; i < 100000; i++) { 
  5.             Map<String, String> map = new HashMap<>(3); 
  6.             map.put("Column1".intern(), "Content1".intern()); 
  7.             map.put("Column2".intern(), "Content2".intern()); 
  8.             map.put("Column3".intern(), "Content3".intern()); 
  9.             lst.add(map); 
  10.         } 
  11.  
  12.         Map<String, List<Map<String, String>>> contentCache = new HashMap<>(); 
  13.         contentCache.put("contents".intern(), lst); 
  14.     } 

把優(yōu)化后的代碼上線,錯誤搞定了!

所以,在這個階段就非得把 JVM 吃透不可了。吃透原理就必須靠看書了。

周志明的《深入理解 JAVA 虛擬機》是必須的了,但是還不夠。

《Oracle JRockit: The Definitive Guide》這本書我也建議讀一讀,雖然老了,但是里面的很多內(nèi)容,尤其前四章,對 JVM 原理真的快講透了。對 JVM 是如何彈性伸縮去平衡資源和性能關系的,娓娓道來,讓我醍醐灌頂,編程視野一下子打開了很多。

至此,不同階段的學習方法講完了。

總的來說,JVM 知識廣博復雜,如果想要掌握,不能一蹴而就。而且咱們程序員不容易,需要學的知識太多,然而咱們的精力卻是有限的。

所以,對于 JVM 原理來說,假設有些知識點眼前看不懂,用不上,可以先暫時放一放,做到精準學習,把省下來的精力用在別的知識甚至自己的生活上,更有意義。

看完如果覺得有收獲,希望能幫忙轉(zhuǎn)發(fā)、隨手點個在看,你的支持對我很重要。

你好,我是四猿外。

一家上市公司的技術總監(jiān),管理的技術團隊一百余人。

我從一名非計算機專業(yè)的畢業(yè)生,轉(zhuǎn)行到程序員,一路打拼,一路成長。

本文轉(zhuǎn)載自微信公眾號「四猿外」,可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系四猿外公眾號。

 

責任編輯:武曉燕 來源: 四猿外
相關推薦

2009-11-01 16:38:35

2018-04-10 11:15:43

蘋果Apple PayiOS 11

2020-04-22 12:06:08

百度網(wǎng)盤資源

2023-01-18 08:26:29

工具Mybatis代碼

2010-11-04 10:39:22

2022-11-04 13:06:47

JVMJava程序

2020-03-16 16:42:52

競爭黑暗法則自媒體

2012-06-20 11:10:17

微軟谷歌蘋果

2023-10-07 08:41:42

JavaJVM

2021-06-03 08:32:18

JVM調(diào)優(yōu)虛擬機

2011-03-23 13:44:29

分散數(shù)據(jù)數(shù)據(jù)庫性能

2012-04-25 09:20:54

IT消費化托管

2010-09-17 13:15:55

JVMJava虛擬機

2010-09-17 13:10:29

JVMJava虛擬機

2023-11-06 08:11:29

注冊中心微服務

2022-08-08 20:33:12

VolatileJVM

2022-07-05 08:34:22

虛擬機JavaJVM

2019-07-16 14:59:00

JVM內(nèi)存區(qū)域

2019-01-30 13:44:34

JVM內(nèi)存服務器

2023-03-09 15:07:02

問界汽車華為
點贊
收藏

51CTO技術棧公眾號