Cách dễ nhất để gây rò rỉ bộ nhớ trong Java?

Question

thể trùng lặp:
Creating a memory leak with Java

cách dễ nhất để gây rò rỉ bộ nhớ java là gì?

Answer 1

Bạn có thể không thực sự "rò rỉ bộ nhớ" trong Java, trừ khi bạn:

• tập chuỗi
• tạo ra các lớp bộ nhớ
• rò rỉ trong mã nguồn gốc gọi bằng JNI
• giữ tham chiếu đến điều mà bạn không muốn ở một số nơi bị lãng quên hoặc tối tăm.

Tôi lấy nó mà bạn quan tâm đến trường hợp cuối cùng. Các kịch bản phổ biến là:

• người nghe, đặc biệt là thực hiện với các lớp bên trong
• cache.

Một ví dụ tốt đẹp sẽ đến:

• xây dựng một gui Swing mà ra mắt một số có khả năng không giới hạn của các cửa sổ phương thức;
• có cửa sổ modal làm điều gì đó như thế này trong quá trình khởi của nó:

   
  StaticGuiHelper.getMainApplicationFrame().getOneOfTheButtons().addActionListener(new ActionListener(){ 
      public void actionPerformed(ActionEvent e){ 
      // do nothing... 
      } 
  }) 
  

Hành động đăng ký không có gì, nhưng nó sẽ gây ra cửa sổ modal để nán lại trong ký ức mãi mãi, ngay cả sau khi đóng cửa, gây rò rỉ - vì các trình lắng nghe không bao giờ được hủy đăng ký, và mỗi đối tượng lớp bên trong vô danh giữ một tham chiếu (vô hình) với đối tượng bên ngoài của nó. Hơn nữa - bất kỳ đối tượng nào được tham chiếu từ các cửa sổ phương thức đều có khả năng bị rò rỉ.

Đây là lý do tại sao các thư viện như EventBus sử dụng tham chiếu yếu theo mặc định.

Ngoài thính giả, các ví dụ điển hình khác là cache, nhưng tôi không thể nghĩ ra một ví dụ hay.

Answer 2

1. Tạo một bộ sưu tập của các đối tượng ở phạm vi lớp
2. kỳ thêm các đối tượng mới vào bộ sưu tập
3. Đừng thả các tham chiếu đến thể hiện của lớp chứa bộ sưu tập

Bởi vì có luôn luôn là một tham chiếu đến bộ sưu tập và thể hiện của đối tượng sở hữu bộ sưu tập mà Garbage Collector sẽ không bao giờ dọn sạch bộ nhớ đó do đó gây ra "rò rỉ" theo thời gian.

Answer 3

public static List<byte[]> list = new ArrayList<byte[]>(); 

Và sau đó thêm (lớn) mảng mà không xóa chúng. Tại một số điểm bạn sẽ hết bộ nhớ mà không nghi ngờ. (Bạn có thể làm điều này với bất kỳ đối tượng nào, nhưng với các mảng lớn, đầy đủ, bạn có thể hết bộ nhớ nhanh hơn)

Trong Java, nếu bạn coi trọng một đối tượng (nó nằm ngoài phạm vi), nó sẽ được thu thập rác. Vì vậy, bạn phải giữ một tham chiếu đến nó để có một vấn đề bộ nhớ.

Answer 4

Dưới đây là một ví dụ đơn giản

public class finalizer { 
    @Override 
     protected void finalize() throws Throwable { 
     while (true) { 
      Thread.yield(); 
     } 
    } 

    public static void main(String[] args) { 
     while (true) { 
      for (int i = 0; i < 100000; i++) { 
       finalizer f = new finalizer(); 
      } 

      System.out.println("" + Runtime.getRuntime().freeMemory() + " bytes free!"); 
     } 
    } 
} 

Answer 5

Từ những gì tôi đã đọc trong câu trả lời đã bỏ phiếu nhất, bạn có lẽ hầu hết các yêu cầu cho một rò rỉ bộ nhớ C-như thế nào. Vâng, kể từ khi có bộ sưu tập garbagge, bạn không thể phân bổ một đối tượng, mất tất cả các tham chiếu của nó và làm cho nó vẫn chiếm bộ nhớ - đó sẽ là lỗi JVM nghiêm trọng. Mặt khác, bạn có thể xảy ra các luồng rò rỉ - tất nhiên, sẽ gây ra trạng thái này, bởi vì bạn sẽ có một số luồng chạy với tham chiếu đến các đối tượng và bạn có thể mất tham chiếu của chuỗi. Bạn vẫn có thể nhận được các tài liệu tham khảo chủ đề thông qua các API - http://www.exampledepot.com/egs/java.lang/ListThreads.html

Answer 6

Hãy thử lớp này đơn giản:

public class Memory { 
private Map<String, List<Object>> dontGarbageMe = new HashMap<String, List<Object>>(); 

public Memory() { 
    dontGarbageMe.put("map", new ArrayList<Object>()); 
} 

public void useMemInMB(long size) { 
    System.out.println("Before=" + getFreeMemInMB() + " MB"); 

    long before = getFreeMemInMB(); 
    while ((before - getFreeMemInMB()) < size) { 
     dontGarbageMe.get("map").add("aaaaaaaaaaaaaaaaaaaaaa"); 
    } 

    dontGarbageMe.put("map", null); 

    System.out.println("After=" + getFreeMemInMB() + " MB"); 
} 

private long getFreeMemInMB() { 
    return Runtime.getRuntime().freeMemory()/(1024 * 1024); 
} 

public static void main(String[] args) { 
    Memory m = new Memory(); 
    m.useMemInMB(15); // put here apropriate huge value 
} 
} 

Answer 7

"Một rò rỉ bộ nhớ, khoa học máy tính (hoặc rò rỉ, trong bối cảnh này), xảy ra khi một chương trình máy tính tiêu thụ bộ nhớ nhưng không thể phát hành nó trở lại hệ điều hành. " (Wikipedia)

Câu trả lời dễ dàng là: Bạn không thể. Java thực hiện quản lý bộ nhớ tự động và sẽ giải phóng các tài nguyên không cần thiết cho bạn. Bạn không thể ngăn điều này xảy ra. Nó sẽ luôn luôn có thể phát hành các nguồn lực. Trong các chương trình với quản lý bộ nhớ thủ công, điều này là khác nhau. Bạn không thể nhận được một số bộ nhớ trong C bằng cách sử dụng malloc(). Để giải phóng bộ nhớ, bạn cần con trỏ mà malloc trả về và gọi miễn phí() trên đó. Nhưng nếu bạn không có con trỏ nữa (ghi đè hoặc vượt quá tuổi thọ), thì bạn không may không có khả năng giải phóng bộ nhớ này và do đó bạn bị rò rỉ bộ nhớ.

Tất cả các câu trả lời khác cho đến nay là trong định nghĩa của tôi không thực sự rò rỉ bộ nhớ. Tất cả đều nhằm mục đích lấp đầy bộ nhớ bằng những thứ vô nghĩa thật nhanh. Nhưng bất cứ lúc nào bạn vẫn có thể dereference các đối tượng bạn tạo ra và do đó giải phóng bộ nhớ -> NO LEAK.câu trả lời của acconrad đến khá gần mặc dù tôi phải thừa nhận kể từ khi giải pháp của ông là có hiệu quả để chỉ "sụp đổ" các nhà sưu tập rác bằng cách buộc nó trong một vòng lặp vô tận).

Câu trả lời dài là: Bạn có thể bị rò rỉ bộ nhớ bằng cách viết thư viện cho Java bằng JNI, có thể có quản lý bộ nhớ thủ công và do đó có rò rỉ bộ nhớ. Nếu bạn gọi thư viện này, quá trình java của bạn sẽ bị rò rỉ bộ nhớ. Hoặc, bạn có thể có lỗi trong JVM, để JVM mất bộ nhớ. Có lẽ có lỗi trong JVM, thậm chí có thể có một số lỗi đã biết vì bộ sưu tập rác không phải là tầm thường, nhưng sau đó nó vẫn là một lỗi. Bằng cách thiết kế này là không thể. Bạn có thể yêu cầu một số mã java được thực hiện bởi một lỗi như vậy. Xin lỗi tôi không biết một và nó cũng có thể không phải là một lỗi nữa trong phiên bản Java tiếp theo anyway.

Answer 8

Dường như hầu hết các câu trả lời đều không phải là rò rỉ bộ nhớ kiểu C.

Tôi nghĩ rằng tôi muốn thêm một ví dụ về một lớp thư viện với một lỗi mà sẽ cung cấp cho bạn một ngoại lệ bộ nhớ. Một lần nữa, nó không phải là một rò rỉ bộ nhớ thực sự nhưng là một ví dụ về một cái gì đó chạy ra khỏi bộ nhớ mà bạn sẽ không mong đợi.

public class Scratch { 
    public static void main(String[] args) throws Exception { 
     long lastOut = System.currentTimeMillis(); 
     File file = new File("deleteme.txt"); 

     ObjectOutputStream out; 
     try { 
      out = new ObjectOutputStream(
        new FileOutputStream("deleteme.txt")); 

      while (true) { 
       out.writeUnshared(new LittleObject()); 
       if ((System.currentTimeMillis() - lastOut) > 2000) { 
        lastOut = System.currentTimeMillis(); 
        System.out.println("Size " + file.length()); 
        // out.reset(); 
       } 
      } 
     } catch (Exception e) { 
      e.printStackTrace(); 
     } 
    } 
} 

class LittleObject implements Serializable { 
    int x = 0; 
} 

Bạn sẽ tìm thấy mã gốc và mô tả lỗi tại

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4363937

Answer 9

Sau đây cực kỳ giả tạo Box lớp sẽ bị rò rỉ bộ nhớ nếu được sử dụng. Các đối tượng là put vào lớp này là cuối cùng (sau khi một cuộc gọi đến put để được chính xác ... miễn là cùng một đối tượng không phải là lại put vào nó.) Không thể tiếp cận với thế giới bên ngoài. Họ không thể được dereferenced thông qua lớp này, nhưng lớp học này đảm bảo họ không thể được thu thập. Đây là một rò rỉ REAL. Tôi biết điều này là thực sự contrived, nhưng các trường hợp tương tự có thể làm do tai nạn.

import java.util.ArrayList; 
import java.util.Collection; 
import java.util.Stack; 

public class Box <E> { 
    private final Collection<Box<?>> createdBoxes = new ArrayList<Box<?>>(); 
    private final Stack<E> stack = new Stack<E>(); 

    public Box() { 
     createdBoxes.add(this); 
    } 

    public void put (E e) { 
     stack.push(e); 
    } 

    public E get() { 
     if (stack.isEmpty()) { 
      return null; 
     } 
     return stack.peek(); 
    } 
}