徹底搞懂Java內存泄露

seasonley 發布于2019-08-16 10:53 / 783人閱讀

摘要：所以如果趕在之前切斷是可以避免內存泄露的。經過測試情況始終沒有內存泄露。如果當退出時候，還有消息未處理或正在處理，由于引用又引用，此時將引發內存泄露。總結如果某些單例需要使用到對象，推薦使用的，不要使用的，否則容易導致內存泄露。

之前一直在簡書寫作，第一次發布到SF上來，也是第一次使用SF，后面會盡量同步到SF，更多文章請關注：
簡書?編程之樂
轉載請注明出處：謝謝！

Java內存回收方式

Java判斷對象是否可以回收使用的而是可達性分析算法。

在主流的商用程序語言中(Java和C#)，都是使用可達性分析算法判斷對象是否存活的。這個算法的基本思路就是通過一系列名為"GC Roots"的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為引用鏈(Reference Chain)，當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的，下圖對象object5, object6, object7雖然有互相判斷，但它們到GC Roots是不可達的，所以它們將會判定為是可回收對象。

在Java語言里，可作為GC Roots對象的包括如下幾種：

    a.虛擬機棧(棧楨中的本地變量表)中的引用的對象
    b.方法區中的類靜態屬性引用的對象
    c.方法區中的常量引用的對象
    d.本地方法棧中JNI的引用的對象

摘自《深入理解Java虛擬機》

使用leakcanary檢測泄漏

關于LeakCanary使用參考以下文章：

LeakCanary: 讓內存泄露無所遁形?? ? ?

LeakCanary 中文使用說明

LeakCanary的內存泄露提示一般會包含三個部分:
第一部分(LeakSingle類的sInstance變量)
引用第二部分(LeakSingle類的mContext變量),
導致第三部分(MainActivity類的實例instance)泄露.

leakcanary使用注意

即使是空的Activity，如果檢測泄露時候遇到了如下這樣的泄露，注意，把refWatcher.watct()放在onDestroy里面即可解決，或者忽略這樣的提示。
由于文章已寫很多，下面的就不再修改，忽略這種錯誤即可。

* com.less.demo.TestActivity has leaked:
* GC ROOT static android.app.ActivityThread.sCurrentActivityThread
* references android.app.ActivityThread.mActivities
* references android.util.ArrayMap.mArray
* references array java.lang.Object[].[1]
* references android.app.ActivityThread$ActivityClientRecord.activity
* leaks com.less.demo.TestActivity instance

protected void onDestroy() {
    super.onDestroy();
    RefWatcher refWatcher = App.getRefWatcher(this);
    refWatcher.watch(this);
}

leakcanary和代碼示例說明內存泄露

案例一(靜態成員引起的內存泄露)

public class App extends Application {
    private RefWatcher refWatcher;

    @Override
    public void onCreate() {
        super.onCreate();
        refWatcher = LeakCanary.install(this);
    }

    public static RefWatcher getRefWatcher(Context context) {
        App application = (App) context.getApplicationContext();
        return application.refWatcher;
    }
}

測試內部類持有外部類引用，內部類是靜態的(GC-ROOT,將一直連著這個外部類實例)，靜態的會和Application一個生命周期，這會導致一直持有外部類引用(內部類隱含了一個成員變量$0), 即使外部類制空= null，也無法釋放。

OutterClass

public class OutterClass {
    private String name;

    class Inner{
        public void list(){
            System.out.println("outter name is " + name);
        }
    }
}

TestActivity

public class TestActivity extends Activity {
    // 靜態的內部類實例
    private static OutterClass.Inner innerClass;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        OutterClass outterClass = new OutterClass();
        innerClass = outterClass.new Inner();

        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(outterClass);// 監控的對象

        outterClass = null;
    }

案例二(單例模式引起的內存泄露)

DownloadManager

public class DownloadManager {
    private static DownloadManager instance;
    private Task task ;

    public static DownloadManager getInstance(){
        if (instance == null) {
            instance = new DownloadManager();
        }
        return instance;
    }
    public Task newTask(){
        this.task = new Task();
        return task;
    }
}

Task

public class Task {
    private Call call;
    public Call newCall(){
        this.call = new Call();
        return call;
    }
}

Call

public class Call {
    public void execute(){
        System.out.println("=========> execute call");
    }
}

TestActivity

public class TestActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        RefWatcher refWatcher = App.getRefWatcher(this);

        Task task = DownloadManager.getInstance().newTask();
        Call call = task.newCall();
        call.execute();
        refWatcher.watch(call);// 監控的對象
        call = null; // 無法回收，DownloadManager是靜態單例，引用task，task引用了call，即使call置為空，也無法回收，切斷GC_ROOT 聯系即可避免內存泄露，即置task為空。
    }
}

部分日志打印如下:當前的GC_ROOT是DownloadManager的instance實例。

 In com.leakcanary.demo:1.0:1.
* com.less.demo.Call has leaked:
* GC ROOT static com.less.demo.DownloadManager.instance
* references com.less.demo.DownloadManager.task
* references com.less.demo.Task.call
* leaks com.less.demo.Call instance

關于上面兩種方式導致的內存泄露問題，這里再舉兩個案例說明以加強理解。

案例三(靜態變量導致的內存泄露)

public class TestActivity extends Activity {
    private static Context sContext;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        sContext = this;

        RefWatcher refWatcher = App.getRefWatcher(this);

        refWatcher.watch(this);// 監控的對象
    }

打印日志如下：

 In com.leakcanary.demo:1.0:1.
com.less.demo.TestActivity has leaked:
GC ROOT static com.less.demo.TestActivity.sContext
leaks com.less.demo.TestActivity instance

從這段日志可以分析出：聲明static后，sContext的生命周期將和Application一樣長，Activity即使退出到桌面，Application依然存在->sContext依然存在，GC此時想回收Activity卻發現Activity仍然被sContext(GC-ROOT連接著)，導致死活回收不了，內存泄露。

上面的代碼改造一下，如下。

public class TestActivity extends Activity {
    private static View sView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        sView = new View(this);

        RefWatcher refWatcher = App.getRefWatcher(this);

        refWatcher.watch(this);
    }
}

日志如下

In com.leakcanary.demo:1.0:1.
com.less.demo.TestActivity has leaked:
GC ROOT static com.less.demo.TestActivity.sView
references android.view.View.mContext
leaks com.less.demo.TestActivity instance

案例四(單例模式導致的內存泄露)
DownloadManager

public class DownloadManager {
    private static DownloadManager instance;
    private List mListeners = new ArrayList<>();

    public interface DownloadListener {
        void done();
    }

    public static DownloadManager getInstance(){
        if (instance == null) {
            instance = new DownloadManager();
        }
        return instance;
    }

    public void register(DownloadListener downloadListener){
        if (!mListeners.contains(downloadListener)) {
            mListeners.add(downloadListener);
        }
    }

    public void unregister(DownloadListener downloadListener){
        if (mListeners.contains(downloadListener)) {
            mListeners.remove(downloadListener);
        }
    }
}

TestActivity

public class TestActivity extends Activity implements DownloadManager.DownloadListener{

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        DownloadManager.getInstance().register(this);

        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        // 忘記 unregister
        // DownloadManager.getInstance().unregister(this);
    }

    @Override
    public void done() {
        System.out.println("done!");
    }
}

 In com.leakcanary.demo:1.0:1.
* com.less.demo.TestActivity has leaked:
* GC ROOT static com.less.demo.DownloadManager.instance
* references com.less.demo.DownloadManager.mListeners
* references java.util.ArrayList.array
* references array java.lang.Object[].[0]
* leaks com.less.demo.TestActivity instance

錯誤寫法一定導致內存泄露嗎？

答案是：否定的。
如下案例，有限時間內是可以挽救內存泄露發生的，所以控制好生命周期，其他情況：如單例對象(靜態變量)的生命周期比其持有的sContext
的生命周期更長時 ->內存泄露，更短時->躲過內存泄露。

public class TestActivity extends Activity {
    private static Context sContext;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        sContext = this;

        new Handler().postDelayed(new Runnable() {
            @Override
            public void run() {
                sContext = null; 
            }
        },1000);// 分別測試1s和12s,前者不會內存泄露，后者一定泄露。所以如果趕在GC之前切斷GC_ROOT是可以避免內存泄露的。
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}

Handler 引起的內存泄露詳細分析

handler導致的內存泄露可能我們大多數都犯過.
注意以下代碼中的注釋,非靜態內部類雖然持有外部類引用，但是持有并不代表一定泄露，而是看gc時誰的命長。經過測試 情況(1)始終沒有內存泄露。

為什么會這樣，很早閱讀Handler源碼時候記得這幾個貨都是互相引用來引用去的，Message有個target字段, message.target = handler;
handler.post(message);又把這個message推入了MessageQueue中，而MessageQueue是在一個Looper線程中不斷輪詢處理消息，而有時候message還是個老不死，能夠重復利用。如果當Activity退出時候，還有消息未處理或正在處理，由于message引用handler,handler又引用Activity，此時將引發內存泄露。

public class TestActivity extends Activity {
    private Handler handler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            System.out.println("===== handle message ====");
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        // (1) 不會導致內存泄露
        handler.sendEmptyMessageDelayed(0x123,0);

        // (2) 會導致內存泄露，非靜態內部類（包括匿名內部類，比如這個 Handler 匿名內部類）會引用外部類對象 this（比如 Activity）
        // 當它使用了 postDelayed 的時候，如果 Activity 已經 finish 了，而這個 handler 仍然引用著這個 Activity 就會致使內存泄漏
        // 因為這個 handler 會在一段時間內繼續被 main Looper 持有，導致引用仍然存在.
        handler.sendEmptyMessageDelayed(0x123, 12000);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}

com.less.demo.TestActivity has leaked:
* GC ROOT android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper.mH
* references com.android.internal.view.IInputConnectionWrapper$MyHandler.mQueue
* references android.os.MessageQueue.mMessages
* references android.os.Message.target , matching exclusion field android.os.Message#target
* references com.less.demo.TestActivity$1.this$0 (anonymous subclass of android.os.Handler)
* leaks com.less.demo.TestActivity instance

知道了原理后，即使寫出易于內存泄露的代碼也能夠避免內存泄露啦。
上述代碼只需在onDestroy()函數中調用mHandler.removeCallbacksAndMessages(null);
在Activity退出的時候的移除消息隊列中所有消息和所有的Runnable。

內部類引起的內存泄露

內部類種類大致如下：

非靜態內部類(成員內部類)

靜態內部類(嵌套內部類)

局部內部類(定義在方法內或者作用域內的類,好似局部變量,所以不能有訪問控制符和static等修飾)

匿名內部類(沒有名字,僅使用一次new個對象即扔掉類的定義)

為什么非靜態內部類持有外部類引用,靜態內部類不持有外部引用。

這個問題非常簡單，就像 static的方法只能調用static的東西，非static可以調用非static和static的一樣。static--> 針對class, 非static->針對對象，我是這么簡單理解的?？磮D：

匿名內部類
將局部內部類的使用再深入一步，假如只創建某個局部內部類的一個對象，就不必命名了。

匿名內部類的類型可以是如下幾種方式。

接口匿名內部類

抽象類匿名內部類

類匿名內部類

匿名內部類總結:

其實主要就是類定義一次就失效了，主要使用的是這個類(不知道名字)的實例。根據內部類的特性，能夠實現回調和閉包。

JavaScript和Python的回調傳遞的是fuction,Java傳遞的是object。

Java中常常用到回調，而回調的本質就是傳遞一個對象，JavaScript或其他語言則是傳遞一個函數(如Python，或者C,使用函數指針的方式),由于傳遞一個對象可以攜帶其他的一些信息，所以Java認為傳遞一個對象比傳遞一個函數要靈活的多(當然java也可以用Method反射對象傳遞函數)。參考《Java核心技術》

非靜態內部類導致內存泄露(前提dog的命長)
下面的案例將導致內存泄露
其中private static Dog dog ; 導致Dog的命比TestActivity長，這就糟糕了，但是注意，如果改為private Dog dog ; 即使Dog是非靜態內部類，也不會導致內存泄露，要死也是Dog先死,畢竟Dog是TestActivity的家庭成員，開掛也得看主人。

public class TestActivity extends Activity {
    private static Dog dog ;

    class Dog {
        public void say(){
            System.out.println("I am lovely dog!");
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        dog = new Dog();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}

In com.leakcanary.demo:1.0:1.
* com.less.demo.TestActivity has leaked:
* GC ROOT static com.less.demo.TestActivity.dog
* references com.less.demo.TestActivity$Dog.this$0
* leaks com.less.demo.TestActivity instance

哪些內部類或者回調函數是否持有外部類對象？
一個反射案例說明一切

/**
 * 作者: limitless
 * 描述: 一個案例測試所有類型內部類對外部類對象的持有情況
 * 網站: https://github.com/wangli0
 */
public class Main {

    /* 持有外部類引用 */
    private IAppListener mAppListener = new IAppListener() {
        private String name;
        @Override
        public void done() {
            System.out.println("匿名內部類對象作為成員變量");
        }
    };
    /* 未持有 */
    private static IAppListener sAppListener = new IAppListener() {
        private String name;
        @Override
        public void done() {
            System.out.println("匿名內部類對象作為static成員變量");
        }
    };

    public static void main(String args[]) {
        Main main = new Main();
        main.test1();
        main.test2();
        main.test3();// test3 《=》test4
        main.test4();
        main.test5();
        main.test6();
    }

    class Dog {
        private String name;
    }

    /* 持有外部類引用 */
    public void test1(){
        Dog dog = new Dog();
        getAllFieldName(dog.getClass());
    }

    static class Cat {
        private String name;
    }
    /* 未持有 */
    private void test2() {
        Cat cat = new Cat();
        getAllFieldName(cat.getClass());
    }

    /* 持有外部類引用 */
    private void test3() {
        class Monkey{
            String name;
        }
        Monkey monkey = new Monkey();
        getAllFieldName(monkey.getClass());
    }

    /* 持有外部類引用 */
    private void test4() {
        // 常用作事件回調的地方(有可能引起內存泄露)
        IAppListener iAppListener = new IAppListener() {
            private String name;
            @Override
            public void done() {
                System.out.println("匿名內部類");
            }
        };
        getAllFieldName(iAppListener.getClass());
    }

    /* 持有外部類引用 */
    private void test5() {
        getAllFieldName(mAppListener.getClass());
    }

    /* 未持有 */
    private void test6() {
        getAllFieldName(sAppListener.getClass());
    }

    private void getAllFieldName(Class clazz) {
        System.out.println("className: ======> " + clazz.getSimpleName());
        Field[] fields = clazz.getDeclaredFields();
        for (Field field : fields) {
            System.out.println(field.getName());
        }
    }
}

上述結果足夠說明，即使是方法內的回調對象也是持有外部類引用的，那么雖然作用域是局部的，也有存在內存泄露的可能。我多次強調 持有某對象 不代表一定泄露，看的是誰命長?；卣{在Android開發過程中幾乎處處可見，如果持有就會內存泄露的話，那幾乎就沒法玩了。
一般情況下，我們常常設置某個方法內的xx.execute(new Listener(){xx});是不會導致內存泄露的，這個方法執行完，局部作用域就失效了。但是如果在execute(listener);過程中，某個單例模式的對象突然引用了這個listener對象，那么就會導致內存泄露。

下面用實例證明我的想法
TestActivity

public class TestActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);

        Task task = new Task();
        task.execute(new ICallback() {
            @Override
            public void done() {
                System.out.println("下載完成！");
            }
        });
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}

Task

public class Task {
    public void execute(ICallback iCallback) {
        DownloadManager.getInstance().execute(iCallback);
    }
}

DownloadManager

public class DownloadManager {
    public static DownloadManager instance;
    private ICallback mICallback;
    public static DownloadManager getInstance(){
        if (instance == null) {
            instance = new DownloadManager();
        }
        return instance;
    }

    public void execute(ICallback iCallback) {
        this.mICallback = iCallback;// 反例，千萬不要這么做，將導致內存泄露,如果注釋掉這行，內存泄露不會發生
        iCallback.done();
    }

這足以證明我的想法是正確的，Callback的不巧當使用同樣會導致內存泄露 的發送。

總結

如果某些單例需要使用到Context對象，推薦使用Application的context，不要使用Activity的context，否則容易導致內存泄露。單例對象的生命周期和Application一致，這樣Application和單例對象就一起銷毀。

優先使用靜態內部類而不是非靜態的,因為非靜態內部類持有外部類引用可能導致垃圾回收失敗。如果你的靜態內部類需要宿主Activity的引用來執行某些東西，你要將這個引用封裝在一個WeakReference中，避免意外導致Activity泄露,被弱引用關聯的對象只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前內存是否足夠，都會回收 只被弱引用關聯 的對象，只被說明這個對象本身已經沒有用處了。

public class TestActivity extends Activity {
    private MyHandler myHandler = new MyHandler(this);
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        
    }

    static class MyHandler extends Handler {
        private WeakReference mWeakReference;

        public MyHandler(Activity activity){
            mWeakReference = new WeakReference(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            Toast.makeText(mWeakReference.get(), "xxxx", Toast.LENGTH_LONG).show();
            Log.d("xx", mWeakReference.get().getPackageName());
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = App.getRefWatcher(this);
        refWatcher.watch(this);
    }
}

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

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

Segmentfault JAVA文章收藏量TOP20

摘要：前言從號開始在寫下第一篇文章說是筆記還差不多，驚奇地收到有人收藏我的文章的消息，覺得有點開心。突然腦子抽到想爬下里標簽下的文章有多少，哪篇被收藏最多，哪篇被點贊最多。。。現在和大家分享下，收藏量前的文章，被那么多人收藏應該是篇值得看的文章。前言從18號開始在sf寫下第一篇文章（說是筆記還差不多），驚奇地收到有人收藏我的文章的消息，覺得有點開心。突然腦子抽到想爬下sf里JAVA標簽下...

zhaofeihao 2019-08-19 11:03 評論0 收藏0
線程安全(上)--徹底搞懂volatile關鍵字

摘要：此時，就出現了線程不安全問題了。因為的初始值會是因此，重排序是有可能導致線程安全問題的。真的能完全保證一個變量的線程安全嗎我們通過上面的講解，發現關鍵字還是挺有用的，不但能夠保證變量的可見性，還能保證代碼的有序性。對于volatile這個關鍵字，相信很多朋友都聽說過，甚至使用過，這個關鍵字雖然字面上理解起來比較簡單，但是要用好起來卻不是一件容易的事。這篇文章將從多個方面來講解vol...

teren 2019-08-19 11:03 評論0 收藏0
一篇文章徹底搞懂JS深淺拷貝和const

摘要：圖數據類型圖引用類型深淺拷貝問題不知道什么是深拷貝和淺拷貝的請先去并在調試臺自己操作一下，這篇文章只會說明為何中會有這種問題。所以有的時候我們為了避免淺拷貝，會用一些方式實現深拷貝。首先要了解的js基礎基本數據類型：Object、undefined、null、Boolean、Number、String、Symbol (ES6新加) Object包括： Array 、Date 、R...

MyFaith 2019-08-23 16:06 評論0 收藏0

發表評論

登陸后可評論

0條評論

seasonley

男|高級講師

我要關注我要私信

TA的文章

記一次性能優化的心酸歷程【Flask+Gunicorn+pytorch+多進程+線程池，一頓操作猛如

閱讀 4722·2021-11-15 11:39
EDG奪冠，Python分析一波B站評論，總結：EDG，nb

閱讀 2691·2021-11-11 16:55
DMIT：$6.9/月/768MB內存/10GB SSD空間/2TB流量/1Gbps-2Gbps端口

閱讀 2200·2021-10-25 09:44
虛擬主機怎么賣-如何購買虛擬主機？需要注意什么？

閱讀 3504·2021-09-22 16:02
精讀《國際化布局 - Logical Properties》

閱讀 2433·2019-08-30 15:55
使用 Flexbox 實現一個網格系統

閱讀 3122·2019-08-30 13:46
實用js庫－使用JS庫Leaflet.js生成世界地圖并獲取標注地址經緯度。

閱讀 2656·2019-08-30 13:15
使用Node.js爬取任意網頁資源并輸出高質量PDF文件到本地~

閱讀 1944·2019-08-30 11:12

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

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

徹底搞懂Java內存泄露

相關文章

**Segmentfault JAVA文章收藏量TOP20**

線程安全(上)--徹底搞懂volatile關鍵字

一篇文章徹底搞懂JS深淺拷貝和const

發表評論

0條評論

seasonley

男|高級講師

TA的文章

記一次性能優化的心酸歷程【Flask+Gunicorn+pytorch+多進程+線程池，一頓操作猛如

EDG奪冠，Python分析一波B站評論，總結：EDG，nb

DMIT：$6.9/月/768MB內存/10GB SSD空間/2TB流量/1Gbps-2Gbps端口

虛擬主機怎么賣-如何購買虛擬主機？需要注意什么？

精讀《國際化布局 - Logical Properties》

使用 Flexbox 實現一個網格系統

實用js庫－使用JS庫Leaflet.js生成世界地圖并獲取標注地址經緯度。

使用Node.js爬取任意網頁資源并輸出高質量PDF文件到本地~

最新活動

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

徹底搞懂Java內存泄露

相關文章

發表評論

0條評論

男|高級講師

TA的文章

最新活動

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！