成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

金三銀四面試季節(jié)之Java 核心面試技術(shù)點 - JVM 小結(jié)

XGBCCC / 2459人閱讀

摘要：直接對棧的操作只有兩個，就是對棧幀的壓棧和出棧。中將永久代移除，同時增加元數(shù)據(jù)區(qū)。在中，本地方法棧和虛擬機棧是在同一塊兒區(qū)域，這完全取決于技術(shù)實現(xiàn)的決定，并未在規(guī)范中強制。

原文：https://github.com/linsheng97...

描述一下 JVM 的內(nèi)存區(qū)域

程序計數(shù)?（PC，Program Counter Register）。在 JVM 規(guī)范中，每個線程都有它自己的程序計數(shù)?，并且任何時間一個線程都只有一個方法在執(zhí)行，也就是所謂的當前方法。程序計數(shù)?會存儲當前線程正在執(zhí)行的 Java 方法的 JVM 指令地址；或者，如果是在執(zhí)行本地方法，則是未指定值（undefined）。

Java 虛擬機棧（Java Virtual Machine Stack），早期也叫 Java 棧。每個線程在創(chuàng)建時都會創(chuàng)建一個虛擬機棧，其內(nèi)部保存一個個的棧幀（Stack Frame），對應(yīng)著一次次的 Java 方法調(diào)用。前面談程序計數(shù)?時，提到了當前方法；同理，在一個時間點，對應(yīng)的只會有一個活動的棧幀，通常叫作當前幀，方法所在的類叫作當前類。如果在該方法中調(diào)用了其他方法，對應(yīng)的新的棧幀會被創(chuàng)建出來，成為新的當前幀，一直到它返回結(jié)果或者執(zhí)行結(jié)束。JVM 直接對 Java 棧的操作只有兩個，就是對棧幀的壓棧和出棧。棧幀中存儲著局部變量表、操作數(shù)（operand）棧、動態(tài)鏈接、方法正常退出或者異常退出的定義等。

堆（Heap），它是 Java 內(nèi)存管理的核心區(qū)域，用來放置 Java 對象實例，幾乎所有創(chuàng)建的Java 對象實例都是被直接分配在堆上。堆被所有的線程共享，在虛擬機啟動時，我們指定的“Xmx”之類參數(shù)就是用來指定最大堆空間等指標。理所當然，堆也是垃圾收集?重點照顧的區(qū)域，所以堆內(nèi)空間還會被不同的垃圾收集?進行進一步的細分，最有名的就是新生代、老年代的劃分。

方法區(qū)（Method Area）。這也是所有線程共享的一塊內(nèi)存區(qū)域，用于存儲所謂的元（Meta）數(shù)據(jù)，例如類結(jié)構(gòu)信息，以及對應(yīng)的運行時常量池、字段、方法代碼等。由于早期的 Hotspot JVM 實現(xiàn)，很多人習慣于將方法區(qū)稱為永久代（Permanent Generation）。Oracle JDK 8 中將永久代移除，同時增加了元數(shù)據(jù)區(qū)（Metaspace）。

運行時常量池（Run-Time Constant Pool），這是方法區(qū)的一部分。如果仔細分析過反編譯的類文件結(jié)構(gòu)，你能看到版本號、字段、方法、超類、接口等各種信息，還有一項信息就是常量池。Java 的常量池可以存放各種常量信息，不管是編譯期生成的各種字面量，還是需要在運行時決定的符號引用，所以它比一般語言的符號表存儲的信息更加寬泛。

本地方法棧（Native Method Stack）。它和 Java 虛擬機棧是非常相似的，支持對本地方法的調(diào)用，也是每個線程都會創(chuàng)建一個。在 Oracle Hotspot JVM 中，本地方法棧和 Java 虛擬機棧是在同一塊兒區(qū)域，這完全取決于技術(shù)實現(xiàn)的決定，并未在規(guī)范中強制。

造成OOM的原因有哪幾種？

堆內(nèi)存不足是最常見的 OOM 原因之一，拋出的錯誤信息是“java.lang.OutOfMemoryError:Java heap space”，原因可能千奇百怪，例如，可能存在內(nèi)存泄漏問題；也很有可能就是堆的大小不合理，比如我們要處理比較可觀的數(shù)據(jù)量，但是沒有顯式指定 JVM 堆大小或者指定數(shù)值偏?。换蛘叱霈F(xiàn) JVM 處理引用不及時，導致堆積起來，內(nèi)存無法釋放等。

虛擬機棧和本地方法棧，這里要稍微復雜一點。如果我們寫一段程序不斷的進行遞歸調(diào)用，而且沒有退出條件，就會導致不斷地進行壓棧。類似這種情況，JVM 實際會拋出StackOverFlowError；當然，如果 JVM 試圖去擴展?？臻g的的時候失敗，則會拋出OutOfMemoryError。

對于老版本的 Oracle JDK，因為永久代的大小是有限的，并且 JVM 對永久代垃圾回收（如，常量池回收、卸載不再需要的類型）非常不積極，所以當我們不斷添加新類型的時候，永久代出現(xiàn)OutOfMemoryError 也非常多見，尤其是在運行時存在大量動態(tài)類型生成的場合；類似 Intern 字符串緩存占用太多空間，也會導致 OOM 問題。對應(yīng)的異常信息，會標記出來和永久代相關(guān)：“java.lang.OutOfMemoryError: PermGenspace

GC 算法

復制（Copying）算法，我前面講到的新生代 GC，基本都是基于復制算法，將活著的對象復制到 to 區(qū)域，拷貝過程中將對象順序放置，就可以避免內(nèi)存碎片化。這么做的代價是，既然要進行復制，既要提前預(yù)留內(nèi)存空間，有一定的浪費；另外，對于 G1 這種分拆成為大量 region 的 GC，復制而不是移動，意味著 GC 需要維護 region 之間對象引用關(guān)系，這個開銷也不小，不管是內(nèi)存占用或者時間開銷。

標記 - 清除（Mark-Sweep）算法，首先進行標記工作，標識出所有要回收的對象，然后進行清除。這么做除了標記、清除過程效率有限，另外就是不可避免的出現(xiàn)碎片化問題，這就導致其不適合特別大的堆；否則，一旦出現(xiàn) Full GC，暫停時間可能根本無法接受。

標記 - 整理（Mark-Compact），類似于標記 - 清除，但為避免內(nèi)存碎片化，它會在清理過程中將對象移動，以確保移動后的對象占用連續(xù)的內(nèi)存空間。

G1 垃圾回收器采用的是什么垃圾回收算法？

從 GC 算法的角度，G1 選擇的是復合算法，可以簡化理解為：

在新生代，G1 采用的仍然是并行的復制算法，所以同樣會發(fā)生 Stop-The-World 的暫停。

在老年代，大部分情況下都是并發(fā)標記，而整理（Compact）則是和新生代 GC 時捎帶進行，并且不是整體性的整理，而是增量進行的。

GC 調(diào)優(yōu)思路

從性能的角度看，通常關(guān)注三個方面，內(nèi)存占用（footprint）、延時（latency）和吞吐量（throughput），大多數(shù)情況下調(diào)優(yōu)會側(cè)重于其中一個或者兩個方面的目標，很少有情況可以兼顧三個不同的角度。當然，除了上面通常的三個方面，也可能需要考慮其他 GC 相關(guān)的場景，例如，OOM 也可能與不合理的 GC 相關(guān)參數(shù)有關(guān)；或者，應(yīng)用啟動速度方面的需求，GC 也會是個考慮的方面。
基本的調(diào)優(yōu)思路可以總結(jié)為：

理解應(yīng)用需求和問題，確定調(diào)優(yōu)目標。假設(shè)，我們開發(fā)了一個應(yīng)用服務(wù)，但發(fā)現(xiàn)偶爾會出現(xiàn)性能抖動，出現(xiàn)較長的服務(wù)停頓。評估用戶可接受的響應(yīng)時間和業(yè)務(wù)量，將目標簡化為，希望 GC 暫停盡量控制在 200ms 以內(nèi)，并且保證一定標準的吞吐量。

掌握 JVM 和 GC 的狀態(tài)，定位具體的問題，確定真的有 GC 調(diào)優(yōu)的必要。具體有很多方法，比如，通過 jstat 等工具查看 GC 等相關(guān)狀態(tài)，可以開啟 GC 日志，或者是利用操作系統(tǒng)提供的診斷工具等。例如，通過追蹤 GC 日志，就可以查找是不是 GC 在特定時間發(fā)生了長時間的暫停，進而導致了應(yīng)用響應(yīng)不及時。

選擇的 GC 類型是否符合我們的應(yīng)用特征，如果是，具體問題表現(xiàn)在哪里，是 Minor GC 過長，還是 Mixed GC 等出現(xiàn)異常停頓情況；如果不是，考慮切換到什么類型，如 CMS 和 G1 都是更側(cè)重于低延遲的 GC 選項。

通過分析確定具體調(diào)整的參數(shù)或者軟硬件配置。驗證是否達到調(diào)優(yōu)目標，如果達到目標，即可以考慮結(jié)束調(diào)優(yōu)；否則，重復完成分析、調(diào)整、驗證這
個過程。

如何提高JVM的性能？

新對象預(yù)留在年輕代

通過設(shè)置一個較大的年輕代預(yù)留新對象，設(shè)置合理的 Survivor 區(qū)并且提供 Survivor 區(qū)的使用率，可以將年輕對象保存在年輕代。

大對象進入年老代

使用參數(shù)-XX:PetenureSizeThreshold 設(shè)置大對象直接進入年老代的閾值

設(shè)置對象進入年老代的年齡

這個閾值的最大值可以通過參數(shù)-XX:MaxTenuringThreshold 來設(shè)置，默認值是 15

穩(wěn)定的 Java 堆

獲得一個穩(wěn)定的堆大小的方法是使-Xms 和-Xmx 的大小一致，即最大堆和最小堆 (初始堆) 一樣。

增大吞吐量提升系統(tǒng)性能

–Xmx380m –Xms3800m：設(shè)置 Java 堆的最大值和初始值。一般情況下，為了避免堆內(nèi)存的頻繁震蕩，導致系統(tǒng)性能下降，我們的做法是設(shè)置最大堆等于最小堆。假設(shè)這里把最小堆減少為最大堆的一半，即 1900m，那么 JVM 會盡可能在 1900MB 堆空間中運行，如果這樣，發(fā)生 GC 的可能性就會比較高；
-Xss128k：減少線程棧的大小，這樣可以使剩余的系統(tǒng)內(nèi)存支持更多的線程；
-Xmn2g：設(shè)置年輕代區(qū)域大小為 2GB；
–XX:+UseParallelGC：年輕代使用并行垃圾回收收集器。這是一個關(guān)注吞吐量的收集器，可以盡可能地減少 GC 時間。
–XX:ParallelGC-Threads：設(shè)置用于垃圾回收的線程數(shù)，通常情況下，可以設(shè)置和 CPU 數(shù)量相等。但在 CPU 數(shù)量比較多的情況下，設(shè)置相對較小的數(shù)值也是合理的；
–XX:+UseParallelOldGC：設(shè)置年老代使用并行回收收集器。

嘗試使用大的內(nèi)存分頁

–XX:+LargePageSizeInBytes：設(shè)置大頁的大小。
內(nèi)存分頁 (Paging) 是在使用 MMU 的基礎(chǔ)上，提出的一種內(nèi)存管理機制。它將虛擬地址和物理地址按固定大小（4K）分割成頁 (page) 和頁幀 (page frame)，并保證頁與頁幀的大小相同。這種機制，從數(shù)據(jù)結(jié)構(gòu)上，保證了訪問內(nèi)存的高效，并使 OS 能支持非連續(xù)性的內(nèi)存分配。

使用非占有的垃圾回收器

為降低應(yīng)用軟件的垃圾回收時的停頓，首先考慮的是使用關(guān)注系統(tǒng)停頓的 CMS 回收器，其次，為了減少 Full GC 次數(shù)，應(yīng)盡可能將對象預(yù)留在年輕代。

system.gc() 的作用是什么？

gc()函數(shù)的作用只是提醒虛擬機：程序員希望進行一次垃圾回收。但是它不能保證垃圾回收一定會進行，而且具體什么時候進行是取決于具體的虛擬機的，不同的虛擬機有不同的對策。

Parallel GC、CMS GC、ZGC、Azul Pauseless GC最主要的不同是？背后的原理也請簡單描述下？

Parallel GC的Young區(qū)采用的是Mark-Copy算法，Old區(qū)采用的是Mark-Sweep-Compact來實現(xiàn)，Parallel執(zhí)行，所以決定了Parallel GC在執(zhí)行YGC、FGC時都會Stop-The-World，但完成GC的速度也會比較快。
CMS GC的Young區(qū)采用的也是Mark-Copy，Old區(qū)采用的是Concurrent Mark-Sweep，所以決定了CMS GC在對old區(qū)回收時造成的STW時間會更短，避免對應(yīng)用產(chǎn)生太大的時延影響。
G1 GC采用了Garbage First算法，比較復雜，實現(xiàn)的好呢，理論上是會比CMS GC可以更高效，同時對應(yīng)用的影響也很小。
ZGC、Azul Pauseless GC采用的算法很不一樣，尤其是Pauseless GC，其中的很重要的一個技巧是通過增加Read Barrier來更好的識別對GC而言最關(guān)鍵的references變化的情況。

什么時候執(zhí)行ygc，fullgc？

當young gen中的eden區(qū)分配滿的時候觸發(fā)young gc，當年老代內(nèi)存不足時，將執(zhí)行Major GC，也叫 Full GC。

gc()函數(shù)的作用只是提醒虛擬機：程序員希望進行一次垃圾回收。但是它不能保證垃圾回收一定會進行，而且具體什么時候進行是取決于具體的虛擬機的，不同的虛擬機有不同的對策。

強引用、軟引用、弱引用、幻象引用有什么區(qū)別？具體使用場景是什么？

不同的引用類型，主要體現(xiàn)的是對象不同的可達性（reachable）狀態(tài)和對垃圾收集的影響。

所謂強引用（"Strong" Reference），就是我們最常見的普通對象引用，只要還有強引用指向一個對象，就能表明對象還“活著”，垃圾收集器不會碰這種對象。對于一個普通的對象，如果沒有其他的引用關(guān)系，只要超過了引用的作用域或者顯式地將相應(yīng)（強）引用賦值為 null，就是可以被垃圾收集的了，當然具體回收時機還是要看垃圾收集策略。

軟引用（SoftReference），是一種相對強引用弱化一些的引用，可以讓對象豁免一些垃圾收集，只有當 JVM 認為內(nèi)存不足時，才會去試圖回收軟引用指向的對象。JVM 會確保在拋出OutOfMemoryError 之前，清理軟引用指向的對象。軟引用通常用來實現(xiàn)內(nèi)存敏感的緩存，如果還有空閑內(nèi)存，就可以暫時保留緩存，當內(nèi)存不足時清理掉，這樣就保證了使用緩存的同時，不會耗盡內(nèi)存。

SoftReference 在“弱引用WeakReference”中屬于最強的引用。SoftReference 所指向的對象，當沒有強引用指向它時，會在內(nèi)存中停留一段的時間，垃圾回收器會根據(jù) JVM 內(nèi)存的使用情況（內(nèi)存的緊缺程度）以及 SoftReference 的 get() 方法的調(diào)用情況來決定是否對其進行回收。

對于幻象引用（PhantomReference ），有時候也翻譯成虛引用，你不能通過它訪問對象?；孟笠脙H僅是提供了一種確保對象被 finalize 以后，做某些事情的機制，比如，通常用來做所謂的 Post-Mortem 清理機制，如 Java 平臺自身 Cleaner 機制等，也有人利用幻象引用監(jiān)控對象的創(chuàng)建和銷毀。

Object counter = new Object();
ReferenceQueue refQueue = new ReferenceQueue<>();
PhantomReference p = new PhantomReference<>(counter, refQueue);
counter = null;
System.gc();
try {
    // Remove 是一個阻塞方法，可以指定 timeout，或者選擇一直阻塞
    Reference ref = refQueue.remove(1000L);
    if (ref != null) {
        // do something
    }
} catch (InterruptedException e) {
    // Handle it
}
JVM類加載過程

一般來說，我們把 Java 的類加載過程分為三個主要步驟：加載、鏈接、初始化。
首先是加載階段（Loading），它是 Java 將字節(jié)碼數(shù)據(jù)從不同的數(shù)據(jù)源讀取到 JVM 中，并映射為 JVM 認可的數(shù)據(jù)結(jié)構(gòu)（Class 對象），這里的數(shù)據(jù)源可能是各種各樣的形態(tài)，如 jar 文件、class 文件，甚至是網(wǎng)絡(luò)數(shù)據(jù)源等；如果輸入數(shù)據(jù)不是 ClassFile 的結(jié)構(gòu)，則會拋出 ClassFormatError。加載階段是用戶參與的階段，我們可以自定義類加載?，去實現(xiàn)自己的類加載過程。


第二階段是鏈接（Linking），這是核心的步驟，簡單說是把原始的類定義信息平滑地轉(zhuǎn)化入 JVM 運行的過程中。這里可進一步細分為三個步驟：



驗證（Verification），這是虛擬機安全的重要保障，JVM 需要核驗字節(jié)信息是符合 Java 虛擬機規(guī)范的，否則就被認為是 VerifyError，這樣就防止了惡意信息或者不合規(guī)的信息危害 JVM 的運行，驗證階段有可能觸發(fā)更多 class 的加載。


準備（Preparation），創(chuàng)建類或接口中的靜態(tài)變量，并初始化靜態(tài)變量的初始值。但這里的“初始化”和下面的顯式初始化階段是有區(qū)別的，側(cè)重點在于分配所需要的內(nèi)存空間，不會去執(zhí)行更進一步的 JVM 指令。


解析（Resolution），在這一步會將常量池中的符號引用（symbolic reference）替換為直接引用。



最后是初始化階段（initialization），這一步真正去執(zhí)行類初始化的代碼邏輯，包括靜態(tài)字段賦值的動作，以及執(zhí)行類定義中的靜態(tài)初始化塊內(nèi)的邏輯，編譯?在編譯階段就會把這部分邏輯整理好，父類型的初始化邏輯優(yōu)先于當前類型的邏輯。

什么是雙親委派模型？

簡單說就是當類加載?（Class-Loader）試圖加載某個類型的時候，除非父加載?找不到相應(yīng)類型，否則盡量將這個任務(wù)代理給當前加載?的父加載?去做。使用委派模型的目的是避免重復加載 Java 類型。

類加載器的類型


啟動類加載?（Bootstrap Class-Loader），加載 jre/lib 下面的 jar 文件，如 rt.jar。它是個超級公民，即使是在開啟了 Security Manager 的時候，JDK 仍賦予了它加載的程序 AllPermission。


擴展類加載?（Extension or Ext Class-Loader），負責加載我們放到 jre/lib/ext/ 目錄下面的 jar 包，這就是所謂的 extension 機制。該目錄也可以通過設(shè)置 “java.ext.dirs”來覆蓋。


應(yīng)用類加載?（Application or App Class-Loader），就是加載我們最熟悉的 classpath


上下文類加載器

Java 提供了很多服務(wù)提供者接口（Service Provider Interface，SPI），允許第三方為這些接口提供實現(xiàn)。常見的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。這些 SPI 的接口由 Java 核心庫來提供，而這些 SPI 的實現(xiàn)代碼則是作為 Java 應(yīng)用所依賴的 jar 包被包含進類路徑（CLASSPATH）里。SPI接口中的代碼經(jīng)常需要加載具體的實現(xiàn)類。那么問題來了，SPI的接口是Java核心庫的一部分，是由啟動類加載器(Bootstrap Classloader)來加載的；SPI的實現(xiàn)類是由系統(tǒng)類加載器(System ClassLoader)來加載的。引導類加載器是無法找到 SPI 的實現(xiàn)類的，因為依照雙親委派模型，BootstrapClassloader無法委派AppClassLoader來加載類。而線程上下文類加載器破壞了“雙親委派模型”，可以在執(zhí)行線程中拋棄雙親委派加載鏈模式，使程序可以逆向使用類加載器。


ServiceLoader 的加載代碼：


public static  ServiceLoader load(Class service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}


ContextClassLoader默認存放了AppClassLoader的引用，由于它是在運行時被放在了線程中，所以不管當前程序處于何處（BootstrapClassLoader或是ExtClassLoader等），在任何需要的時候都可以用Thread.currentThread().getContextClassLoader()取出應(yīng)用程序類加載器來完成需要的操作。

自定義類加載器

自定義類加載?，常見的場景有：



實現(xiàn)類似進程內(nèi)隔離，類加載?實際上用作不同的命名空間，以提供類似容?、模塊化的效果。例如，兩個模塊依賴于某個類庫的不同版本，如果分別被不同的容?加載，就可以互不干擾。這個方面的集大成者是Java EE和OSGI、JPMS等框架。


應(yīng)用需要從不同的數(shù)據(jù)源獲取類定義信息，例如網(wǎng)絡(luò)數(shù)據(jù)源，而不是本地文件系統(tǒng)。


需要自己操縱字節(jié)碼，動態(tài)修改或者生成類型



從本地路徑 load class 的例子:


public class CustomClassLoader extends ClassLoader {
 
    @Override
    public Class findClass(String name) throws ClassNotFoundException {
        byte[] b = loadClassFromFile(name);
        return defineClass(name, b, 0, b.length);
    }
 
    private byte[] loadClassFromFile(String fileName)  {
        InputStream inputStream = getClass().getClassLoader().getResourceAsStream(
                fileName.replace(".", File.separatorChar) + ".class");
        byte[] buffer;
        ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
        int nextValue = 0;
        try {
            while ( (nextValue = inputStream.read()) != -1 ) {
                byteStream.write(nextValue);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        buffer = byteStream.toByteArray();
        return buffer;
    }
}

動態(tài)代理的原理？

反射機制是 Java 語言提供的一種基礎(chǔ)功能，賦予程序在運行時自?。╥ntrospect，官方用語）的能力。通過反射我們可以直接操作類或者對象，比如獲取某個對象的類定義，獲取類聲明的屬性和方法，調(diào)用方法或者構(gòu)造對象，甚至可以運行時修改類定義。 動態(tài)代理是一種方便運行時動態(tài)構(gòu)建代理、動態(tài)處理代理方法調(diào)用的機制，很多場景都是利用類似機制做到的，比如用來包裝 RPC 調(diào)用、面向切面的編程（AOP）。 實現(xiàn)動態(tài)代理的方式很多，比如 JDK 自身提供的動態(tài)代理，就是主要利用了上面提到的反射機制。還有其他的實現(xiàn)方式，比如利用傳說中更高性能的字節(jié)碼操作機制，類似 ASM、cglib（基于 ASM）、Javassist 等。

如何使用JDK動態(tài)代理？

public class MyDynamicProxy {
    public static  void main (String[] args) {
        HelloImpl hello = new HelloImpl();
        MyInvocationHandler handler = new MyInvocationHandler(hello);
        // 構(gòu)造代碼實例
        Hello proxyHello = (Hello) Proxy.newProxyInstance(HelloImpl.class.getClassLoader(), HelloImpl.class.getInterfaces(), handler);
        // 調(diào)用代理方法
        proxyHello.sayHello();
    }
}
interface Hello {
    void sayHello();
}
class HelloImpl implements  Hello {
    @Override
    public void sayHello() {
        System.out.println("Hello World");
    }
}
class MyInvocationHandler implements InvocationHandler {
    private Object target;
    public MyInvocationHandler(Object target) {
        this.target = target;
    }
    @Override
    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        System.out.println("Invoking sayHello");
        Object result = method.invoke(target, args);
        return result;
    }
}

動態(tài)代理：JDK動態(tài)代理和CGLIB代理的區(qū)別？

JDK動態(tài)代理只能對實現(xiàn)了接口的類生成代理，而不能針對類，CGLIB是針對類實現(xiàn)代理，主要是對指定的類生成一個子類，覆蓋其中的方法（繼承）。


JDK Proxy 的優(yōu)勢：



最小化依賴關(guān)系，減少依賴意味著簡化開發(fā)和維護，JDK 本身的支持，可能比 cglib 更加可靠。


平滑進行 JDK 版本升級，而字節(jié)碼類庫通常需要進行更新以保證在新版 Java 上能夠使用。


代碼實現(xiàn)簡單。



基于類似 cglib 框架的優(yōu)勢：



有的時候調(diào)用目標可能不便實現(xiàn)額外接口，從某種角度看，限定調(diào)用者實現(xiàn)接口是有些侵入性的實踐，類似 cglib 動態(tài)代理就沒有這種限制。


只操作我們關(guān)心的類，而不必為其他相關(guān)類增加工作量。


高性能。


Spring在選擇用JDK還是CGLiB的依據(jù)是什么？

(1)當Bean實現(xiàn)接口時，Spring就會用JDK的動態(tài)代理
(2)當Bean沒有實現(xiàn)接口時，Spring使用CGlib是實現(xiàn)
(3)可以強制使用CGlib（在spring配置中加入）

CGlib比JDK快？

(1)使用CGLib實現(xiàn)動態(tài)代理，CGLib底層采用ASM字節(jié)碼生成框架，使用字節(jié)碼技術(shù)生成代理類，比使用Java反射效率要高。唯一需要注意的是，CGLib不能對聲明為final的方法進行代理，因為CGLib原理是動態(tài)生成被代理類的子類。但是JDK也在升級，開始引入很多字節(jié)碼技術(shù)來實現(xiàn)部分動態(tài)代理的功能，所以在某些測試下不一定是CGLib更快。

Java 中操作字節(jié)碼的技術(shù)

ASM、Javassist、CGLib、Byte Budy。
           
               
                                           
                       
                 
            
                     
             
               

                   
 文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

                 
                   
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/73888.html

               

                      
               
              
              

                
相關(guān)文章

                
    
                             
                                                                                                    
  • 
                                                
    
                          
    金三銀四，2019大廠Android高級工程師面試題整理
    
                                                     
    摘要：原文地址游客前言金三銀四，很多同學心里大概都準備著年后找工作或者跳槽。最近有很多同學都在交流群里求大廠面試題。

最近整理了一波面試題，包括安卓JAVA方面的，目前大廠還是以安卓源碼，算法，以及數(shù)據(jù)結(jié)構(gòu)為主，有一些中小型公司也會問到混合開發(fā)的知識，至于我為什么傾向于混合開發(fā)，我的一句話就是走上編程之路，將來你要學不僅僅是這些，豐富自己方能與世接軌，做好全棧的裝備。
原文地址：游客kutd...
    
                                                   
                          
    
                                
    
                                    tracymac7
                                    
                                    評論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                                       
  • 
                                                
    
                          
    金三銀四背后，一個 Android 程序員的面試心得
    
                                                     
    摘要：到十二月份，公司開始第二波裁員，我決定主動拿賠償走人。加一個小插曲上面的題是餓了嗎面試問到的。想去的公司沒有面試好，不要氣餒，繼續(xù)加油準備。避免打擊自信心。

回顧一下自己這段時間的經(jīng)歷，九月份的時候，公司通知了裁員，我匆匆忙忙地出去面了幾家，但最終都沒有拿到offer，我感覺今年的寒冬有點冷。到十二月份，公司開始第二波裁員，我決定主動拿賠償走人。后續(xù)的面試過程我做了一些準備，基本都能走...
    
                                                   
                          
    
                                
    
                                    Achilles
                                    
                                    評論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                                       
  • 
                                                
    
                          
    為Java程序員金三銀四精心挑選的300余道Java面試題與答案
    
                                                     
    摘要：為程序員金三銀四精心挑選的余道面試題與答案，歡迎大家向我推薦你在面試過程中遇到的問題我會把大家推薦的問題添加到下面的常用面試題清單中供大家參考。

為Java程序員金三銀四精心挑選的300余道Java面試題與答案，歡迎大家向我推薦你在面試過程中遇到的問題,我會把大家推薦的問題添加到下面的常用面試題清單中供大家參考。
前兩天寫的以下博客，大家比較認可，熱度不錯，希望可以幫到準備或者正在參加...
    
                                                   
                          
    
                                
    
                                    tomorrowwu
                                    
                                    評論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                           
                

              

              
               

                  
                  
發(fā)表評論

                   
               

              

                

                  
0條評論
   
                
 
                      

              

           
           

              
 
                

                    
                    
XGBCCC

                    
男|高級講師

                    
                    

                          
TA的文章

                          閱讀更多
                    

                      
                


                   
              
  

                  
最新活動
 
           
                             
              





                                
              

           

        
       
    
    
     

      
    

    
    

    
       
       

         
閱讀需要支付1元查看
  
         
     
       

      
  
    
    








        

            

              
              
            

             
        

    








<