国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

金三銀四面試季節之Java 核心面試技術點 - JVM 小結

XGBCCC / 2445人閱讀

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

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

描述一下 JVM 的內存區域

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

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

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

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

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

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

造成OOM的原因有哪幾種？

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

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

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

GC 算法

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

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

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

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

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

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

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

GC 調優思路

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

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

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

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

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

如何提高JVM的性能？

新對象預留在年輕代

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

大對象進入年老代

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

設置對象進入年老代的年齡

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

穩定的 Java 堆

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

增大吞吐量提升系統性能

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

嘗試使用大的內存分頁

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

使用非占有的垃圾回收器

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

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

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

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

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

什么時候執行ygc，fullgc？

當young gen中的eden區分配滿的時候觸發young gc，當年老代內存不足時，將執行Major GC，也叫 Full GC。

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

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

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

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

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

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

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

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 將字節碼數據從不同的數據源讀取到 JVM 中，并映射為 JVM 認可的數據結構（Class 對象），這里的數據源可能是各種各樣的形態，如 jar 文件、class 文件，甚至是網絡數據源等；如果輸入數據不是 ClassFile 的結構，則會拋出 ClassFormatError。加載階段是用戶參與的階段，我們可以自定義類加載?，去實現自己的類加載過程。


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



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


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


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



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

什么是雙親委派模型？

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

類加載器的類型


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


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


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


上下文類加載器

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


ServiceLoader 的加載代碼：


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


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

自定義類加載器

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



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


應用需要從不同的數據源獲取類定義信息，例如網絡數據源，而不是本地文件系統。


需要自己操縱字節碼，動態修改或者生成類型



從本地路徑 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;
    }
}

動態代理的原理？

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

如何使用JDK動態代理？

public class MyDynamicProxy {
    public static  void main (String[] args) {
        HelloImpl hello = new HelloImpl();
        MyInvocationHandler handler = new MyInvocationHandler(hello);
        // 構造代碼實例
        Hello proxyHello = (Hello) Proxy.newProxyInstance(HelloImpl.class.getClassLoader(), HelloImpl.class.getInterfaces(), handler);
        // 調用代理方法
        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;
    }
}

動態代理：JDK動態代理和CGLIB代理的區別？

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


JDK Proxy 的優勢：



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


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


代碼實現簡單。



基于類似 cglib 框架的優勢：



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


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


高性能。


Spring在選擇用JDK還是CGLiB的依據是什么？

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

CGlib比JDK快？

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

Java 中操作字節碼的技術

ASM、Javassist、CGLib、Byte Budy。
           
               
                                           
                       
                 
            
                     
             
               

                   
 文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

                 
                   
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/73888.html

               

                      
               
              
              

                
相關文章

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

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

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

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

              

              
               

                  
                  
發表評論

                   
               

              

                

                  
0條評論
   
                
 
                      

              

           
           

              
 
                

                    
                    
XGBCCC

                    
男|高級講師

                    
                    

                          
TA的文章

                          閱讀更多
                    

                      
                


                   
              
  

                  
最新活動
 
           
                             
              





                                
              

           

        
       
    
    
     

      
    

    
    

    
       
       

         
閱讀需要支付1元查看
  
         
     
       

      
  
    
    








        

            

              
              
            

             
        

    







<