Tại sao sun.misc.Unsafe tồn tại và làm thế nào nó có thể được sử dụng trong thế giới thực? [đóng cửa]

Tôi đã đi qua gói sun.misc.Unsafe vào một ngày khác và ngạc nhiên về những gì nó có thể làm.

Tất nhiên, lớp học không có giấy tờ, nhưng tôi đã tự hỏi liệu có bao giờ một lý do tốt để sử dụng nó. Những kịch bản có thể phát sinh nơi bạn sẽ cần phải sử dụng nó? Làm thế nào nó có thể được sử dụng trong một kịch bản trong thế giới thực?

Hơn nữa, nếu bạn làm cần nó, làm thế không chỉ ra một cái gì đó mà có lẽ là sai với thiết kế của bạn?

Tại sao Java thậm chí bao gồm lớp này?

ví dụ

1. VM "nội tại." tức là CAS (So sánh và hoán đổi) được sử dụng trong Bảng băm không khóa, ví dụ: sun.misc.Unsafe.compareAndSwapInt, nó có thể thực hiện các cuộc gọi JNI thực sự thành mã gốc có chứa các hướng dẫn đặc biệt cho CAS

   đọc thêm về CAS tại đây http://en.wikipedia.org/wiki/Compare-and-swap

2. Chức năng sun.misc.Unsafe của máy chủ VM có thể được sử dụng để phân bổ các đối tượng chưa được khởi tạo và sau đó diễn giải lời gọi hàm tạo như bất kỳ lệnh gọi phương thức nào khác.

3. Người ta có thể theo dõi dữ liệu từ địa chỉ gốc. Có thể truy xuất địa chỉ bộ nhớ của đối tượng bằng lớp java.lang.Unsafe và hoạt động trực tiếp trên các trường của nó thông qua các phương thức get / put không an toàn!

4. Biên dịch tối ưu hóa thời gian cho JVM. VM hiệu suất cao bằng cách sử dụng "ma thuật", yêu cầu các hoạt động cấp thấp. ví dụ: http://en.wikipedia.org/wiki/Jike_RVM

5. Phân bổ bộ nhớ, sun.misc.Unsafe.allocateMemory, vd: - Trình xây dựng DirectByteBuffer gọi nội bộ khi ByteBuffer.allocateDirect được gọi

6. Theo dõi ngăn xếp cuộc gọi và phát lại với các giá trị được khởi tạo bởi sun.misc.Unsafe, hữu ích cho thiết bị

7. sun.misc.Unsafe.arrayBase Offerset và ArrayIndexScale có thể được sử dụng để phát triển mảng, một kỹ thuật phá vỡ các mảng lớn thành các đối tượng nhỏ hơn để hạn chế chi phí thời gian thực của việc quét, cập nhật hoặc di chuyển các hoạt động trên các đối tượng lớn

8. http://robaustin.wikidot.com/how-to-write-to-direct-memory-locations-in-java

thêm về các tài liệu tham khảo tại đây - http://bytescrolls.blogspot.com/2011/04/interesting-uses-of-sunmiscunsafe.html

Chỉ từ việc chạy tìm kiếm trong một số công cụ tìm kiếm mã, tôi có được các ví dụ sau:

• Ký hiệu đối tượng Java - sử dụng nó để xử lý mảng hiệu quả hơn, trích dẫn javadoc

Lớp đơn giản để có quyền truy cập vào đối tượng {@link Unsafe}. {@link Không an toàn} * là bắt buộc để cho phép các hoạt động CAS hiệu quả trên mảng. Lưu ý rằng các phiên bản trong {@link java.util.concản.atomic}, chẳng hạn như {@link java.util.concien.atomic.AtomicLongArray}, yêu cầu bảo đảm đặt hàng bộ nhớ bổ sung thường không cần thiết trong các thuật toán này và cũng đắt tiền trên hầu hết các bộ xử lý.

• SoyLatte - java 6 cho đoạn trích osx javadoc

/ ** Lớp cơ sở cho FieldAccessors dựa trên sun.misc.Unsafe cho các trường tĩnh. Quan sát là chỉ có chín loại trường theo quan điểm của mã phản chiếu: tám loại nguyên thủy và Đối tượng. Sử dụng lớp Không an toàn thay vì mã byte được tạo sẽ tiết kiệm bộ nhớ và thời gian tải cho FieldAccessors được tạo động. * /

• SpikeSource

/ * FinalField được gửi qua dây .. làm thế nào để unmarshall và tạo lại đối tượng ở phía bên nhận? Chúng tôi không muốn gọi hàm tạo vì nó sẽ thiết lập các giá trị cho các trường cuối cùng. Chúng ta phải tạo lại trường cuối cùng chính xác như ở bên người gửi. Sun.misc.Unsafe thực hiện điều này cho chúng tôi. * /

Có nhiều ví dụ khác, chỉ cần theo liên kết trên ...

Thật thú vị, tôi thậm chí chưa bao giờ nghe nói về lớp học này (có lẽ là một điều tốt, thực sự).

Một điều khiến người ta chú ý là sử dụng Unsafe # setMemory để loại bỏ bộ đệm có chứa thông tin nhạy cảm tại một điểm (mật khẩu, khóa, ...). Bạn thậm chí có thể làm điều này với các trường của các đối tượng "bất biến" (một lần nữa tôi cho rằng sự phản chiếu cũ đơn giản cũng có thể thực hiện thủ thuật ở đây). Tôi không phải là chuyên gia bảo mật mặc dù vậy hãy dùng nó với một hạt muối.

Dựa trên một phân tích rất ngắn gọn về thư viện Java 1.6.12 bằng cách sử dụng nhật thực để theo dõi tham chiếu, dường như mọi chức năng hữu ích của Unsafeđều được bộc lộ theo những cách hữu ích.

Các hoạt động CAS được thể hiện thông qua các lớp Nguyên tử *. Các chức năng thao tác bộ nhớ được phơi bày thông qua các hướng dẫn Đồng bộ hóa DirectByteBuffer (park, unpark) được hiển thị thông qua Trình đồng bộ hóa trừu tượng được sử dụng bởi các cài đặt Khóa.

Unsafe.throwException - cho phép ném ngoại lệ được kiểm tra mà không cần khai báo chúng.

Điều này rất hữu ích trong một số trường hợp bạn xử lý phản xạ hoặc AOP.

Giả sử bạn Xây dựng proxy chung cho Giao diện do người dùng xác định. Và người dùng có thể chỉ định ngoại lệ nào được đưa ra bởi sự cấy ghép trong trường hợp đặc biệt chỉ bằng cách khai báo ngoại lệ trong giao diện. Sau đó, đây là cách duy nhất tôi biết, để tăng một ngoại lệ được kiểm tra trong Triển khai động của Giao diện.

import org.junit.Test;
/** need to allow forbidden references! */ import sun.misc.Unsafe;

/**
 * Demonstrate how to throw an undeclared checked exception.
 * This is a hack, because it uses the forbidden Class {@link sun.misc.Unsafe}.
 */
public class ExceptionTest {

    /**
     * A checked exception.
     */
    public static class MyException extends Exception {
        private static final long serialVersionUID = 5960664994726581924L;
    }

    /**
     * Throw the Exception.
     */
    @SuppressWarnings("restriction")
    public static void throwUndeclared() {
        getUnsafe().throwException(new MyException());
    }

    /**
     * Return an instance of {@link sun.misc.Unsafe}.
     * @return THE instance
     */
    @SuppressWarnings("restriction")
    private static Unsafe getUnsafe() {
        try {

            Field singleoneInstanceField = Unsafe.class.getDeclaredField("theUnsafe");
            singleoneInstanceField.setAccessible(true);
            return (Unsafe) singleoneInstanceField.get(null);

        } catch (IllegalArgumentException e) {
            throw createExceptionForObtainingUnsafe(e);
        } catch (SecurityException e) {
            throw createExceptionForObtainingUnsafe(e);
        } catch (NoSuchFieldException e) {
            throw createExceptionForObtainingUnsafe(e);
        } catch (IllegalAccessException e) {
            throw createExceptionForObtainingUnsafe(e);
        }
    }

    private static RuntimeException createExceptionForObtainingUnsafe(final Throwable cause) {
        return new RuntimeException("error while obtaining sun.misc.Unsafe", cause);
    }


    /**
     * scenario: test that an CheckedException {@link MyException} can be thrown
     * from an method that not declare it.
     */
    @Test(expected = MyException.class)
    public void testUnsingUnsaveToThrowCheckedException() {
        throwUndeclared();
    }
}

Lớp học không an toàn

Một tập hợp các phương pháp để thực hiện các hoạt động cấp thấp, không an toàn. Mặc dù lớp và tất cả các phương thức là công khai, việc sử dụng lớp này bị hạn chế vì chỉ có mã đáng tin cậy mới có thể có được các thể hiện của nó.

Một công dụng của nó là trong java.util.concurrent.atomiccác lớp:

• Nguyên tử
• Nguyên tửLongArray

Để sao chép bộ nhớ hiệu quả (sao chép nhanh hơn System.arraycopy () cho các khối ngắn ít nhất); như được sử dụng bởi Java LZF và Snappy codec. Họ sử dụng 'getLong' và 'putLong', nhanh hơn so với việc sao chép từng byte một; đặc biệt hiệu quả khi sao chép những thứ như khối 16/32/64 byte.

Gần đây tôi đã làm việc để thực hiện lại JVM và thấy rằng một số lượng đáng ngạc nhiên các lớp được triển khai theo các khía cạnh Unsafe. Lớp này hầu hết được thiết kế cho những người triển khai thư viện Java và chứa các tính năng về cơ bản không an toàn nhưng cần thiết để xây dựng các nguyên thủy nhanh. Ví dụ, có các phương thức để nhận và ghi các offset trường thô, sử dụng đồng bộ hóa ở mức phần cứng, cấp phát và giải phóng bộ nhớ, v.v. Nó không dành cho các lập trình viên Java thông thường; nó không có giấy tờ, cụ thể về triển khai và vốn không an toàn (do đó có tên!). Hơn nữa, tôi nghĩ rằngSecurityManager sẽ không cho phép truy cập vào nó trong hầu hết các trường hợp.

Nói tóm lại, nó chủ yếu tồn tại để cho phép những người triển khai thư viện truy cập vào máy bên dưới mà không phải khai báo mọi phương thức trong các lớp nhất định như AtomicIntegerbản địa. Bạn không cần phải sử dụng hoặc lo lắng về nó trong lập trình Java thông thường, vì toàn bộ vấn đề là làm cho phần còn lại của các thư viện đủ nhanh để bạn không cần loại truy cập đó.

Sử dụng nó để truy cập và phân bổ số lượng lớn bộ nhớ một cách hiệu quả, chẳng hạn như trong công cụ voxel của riêng bạn! (tức là trò chơi theo phong cách Minecraft.)

Theo kinh nghiệm của tôi, JVM thường không thể loại bỏ giới hạn - kiểm tra tại chỗ bạn thực sự cần nó. Ví dụ: nếu bạn đang lặp qua một mảng lớn, nhưng quyền truy cập bộ nhớ thực tế được giấu bên dưới một lệnh gọi phương thức * không ảo trong vòng lặp, JVM vẫn có thể thực hiện kiểm tra giới hạn với mỗi lần truy cập mảng, thay vì chỉ một lần trước đó vòng lặp. Do đó, để tăng hiệu năng tiềm năng lớn, bạn có thể loại bỏ giới hạn JVM - kiểm tra bên trong vòng lặp thông qua phương thức sử dụng sun.misc.Unsafe để truy cập trực tiếp vào bộ nhớ, đảm bảo thực hiện bất kỳ giới hạn nào - tự kiểm tra tại đúng vị trí. (Bạn là sẽ giới hạn kiểm tra ở mức độ nào, phải không?)
_{* bởi không ảo, ý tôi là JVM không cần phải tự động giải quyết bất kỳ phương thức cụ thể nào của bạn, bởi vì bạn đã đảm bảo chính xác rằng lớp / phương thức / thể hiện là một sự kết hợp giữa tĩnh / cuối cùng / những gì bạn có.}

Đối với công cụ voxel tự trồng tại nhà của tôi, điều này dẫn đến tăng hiệu suất đáng kể trong quá trình tạo và xê-ri hóa chunk (iow nơi tôi đang đọc / ghi vào toàn bộ mảng cùng một lúc). Kết quả có thể khác nhau, nhưng nếu thiếu giới hạn loại bỏ là vấn đề của bạn, thì điều này sẽ khắc phục nó.

Có một số vấn đề tiềm ẩn lớn với vấn đề này: cụ thể, khi bạn cung cấp khả năng truy cập bộ nhớ mà không giới hạn kiểm tra cho khách hàng của giao diện của bạn, họ có thể sẽ lạm dụng nó. (Đừng quên rằng tin tặc cũng có thể là khách hàng của giao diện của bạn ... đặc biệt là trong trường hợp công cụ voxel được viết bằng Java.) Vì vậy, bạn nên thiết kế giao diện của mình theo cách mà việc truy cập bộ nhớ không thể bị lạm dụng hoặc bạn nên cực kỳ cẩn thận để xác nhận sử dụng dữ liệu trước khi nó có thể bao giờ hết, bao giờ trộn lẫn với giao diện nguy hiểm của bạn. Xem xét những điều thảm khốc mà một hacker có thể làm với quyền truy cập bộ nhớ không được kiểm soát, có lẽ tốt nhất là thực hiện cả hai cách tiếp cận.

Các bộ sưu tập heap có thể hữu ích cho việc phân bổ số lượng lớn bộ nhớ và giải phóng nó ngay lập tức sau khi sử dụng mà không bị nhiễu bởi GC. Tôi đã viết một thư viện để làm việc với các mảng / danh sách heap dựa trên sun.misc.Unsafe.

Chúng tôi đã triển khai các bộ sưu tập lớn như Mảng, HashMaps, TreeMaps bằng cách sử dụng Không an toàn.
Và để tránh / giảm thiểu sự phân mảnh, chúng tôi đã triển khai cấp phát bộ nhớ bằng cách sử dụng các khái niệm về dlmalloc không an toàn.
Điều này giúp chúng tôi đạt được hiệu suất đồng thời.

Unsafe.park()và Unsafe.unpark()để xây dựng các cấu trúc kiểm soát đồng thời tùy chỉnh và các cơ chế lập lịch hợp tác.

Không tự mình sử dụng nó, nhưng tôi cho rằng nếu bạn có một biến chỉ thỉnh thoảng được đọc bởi nhiều hơn một luồng (vì vậy bạn không thực sự muốn làm cho nó biến động), bạn có thể sử dụng putObjectVolatilekhi viết nó trong luồng chính và readObjectVolatilekhi làm các bài đọc hiếm từ các chủ đề khác.

Bạn cần nó nếu bạn cần thay thế chức năng được cung cấp bởi một trong các lớp hiện đang sử dụng nó.

Đây có thể là tuần tự hóa / giải tuần tự tùy chỉnh / nhanh hơn / gọn hơn, một bộ đệm nhanh hơn / lớn hơn / phiên bản thay đổi kích thước của ByteBuffer hoặc thêm một biến nguyên tử, ví dụ như không được hỗ trợ.

Tôi đã sử dụng nó cho tất cả những điều này tại một số thời điểm.

Một ví dụ về việc sử dụng nó là phương pháp ngẫu nhiên, gọi phương thức không an toàn để thay đổi hạt giống .

Trang web này cũng có một số công dụng của nó .

Đối tượng dường như có sẵn để hoạt động ở mức thấp hơn mức mà mã Java thường cho phép. Nếu bạn đang mã hóa một ứng dụng mức cao thì JVM trừu tượng hóa việc xử lý bộ nhớ và các hoạt động khác ngoài mức mã để dễ lập trình hơn. Bằng cách sử dụng thư viện Không an toàn, bạn hoàn thành hiệu quả các hoạt động cấp thấp thường được thực hiện cho bạn.

Như woliveirajr đã nói "Random ()" sử dụng Unsafe để tạo giống như nhiều hoạt động khác sẽ sử dụng hàm allocateMemory () có trong Unsafe.

Là một lập trình viên, có lẽ bạn có thể thoát khỏi việc không bao giờ cần thư viện này nhưng việc kiểm soát chặt chẽ các yếu tố cấp thấp sẽ có ích (đó là lý do tại sao vẫn có hội và mã ở mức độ thấp hơn) trong các sản phẩm chính)