java byte decompiler不生效 java directbytebuffer

转载

mob6454cc61df1e 2024-01-19 16:16:37

byte buffer一般在网络交互过程中java使用得比较多，尤其是以NIO的框架中；

看名字就知道是以字节码作为缓冲的，先buffer一段，然后flush到终端。

而本文要说的一个重点就是HeapByteBuffer与DirectByteBuffer，以及如何合理使用DirectByteBuffer。

1、HeapByteBuffer与DirectByteBuffer，在原理上，前者可以看出分配的buffer是在heap区域的，其实真正flush到远程的时候会先拷贝得到直接内存，再做下一步操作（考虑细节还会到OS级别的内核区直接内存），其实发送静态文件最快速的方法是通过OS级别的send_file，只会经过OS一个内核拷贝，而不会来回拷贝；在NIO的框架下，很多框架会采用DirectByteBuffer来操作，这样分配的内存不再是在java heap上，而是在C heap上，经过性能测试，可以得到非常快速的网络交互，在大量的网络交互下，一般速度会比HeapByteBuffer要快速好几倍。

分配HeapByteBuffer的方法是：

1. ByteBuffer.allocate(int capacity);参数大小为字节的数量

分配DirectByteBuffer的方法是：

ByteBuffer.allocateDirect(int capacity);//可以看到分配内存是通过unsafe.allocateMemory()来实现的，这个unsafe默认情况下java代码是没有能力可以调用到的，不过你可以通过反射的手段得到实例进而做操作，当然你需要保证的是程序的稳定性，既然叫unsafe的，就是告诉你这不是安全的，其实并不是不安全，而是交给程序员来操作，它可能会因为程序员的能力而导致不安全，而并非它本身不安全。

由于HeapByteBuffer和DirectByteBuffer类都是default类型的，所以你无法字节访问到，你只能通过ByteBuffer间接访问到它，因为JVM不想让你访问到它，对了，JVM不想让你访问到它肯定就有它不可告人的秘密；后面我们来跟踪下他的秘密吧。

为什么要提供两种方式呢？这与Java的内存使用机制有关。第一种分配方式产生的内存开销是在JVM中的，而另外一种的分配方式产生的开销在JVM之外，以就是系统级的内存分配。当Java程序接收到外部传来的数据时，首先是被系统内存所获取，然后在由系统内存复制复制到JVM内存中供Java程序使用。所以在另外一种分配方式中，能够省去复制这一步操作，效率上会有所提高。可是系统级内存的分配比起JVM内存的分配要耗时得多，所以并非不论什么时候allocateDirect的操作效率都是最高的。以下是一个不同容量情况下两种分配方式的操作时间对照：

由图能够看出，当操作数据量非常小时，两种分配方式操作使用时间基本是同样的，第一种方式有时可能会更快，可是当数据量非常大时，另外一种方式会远远大于第一种的分配方式。

2、前面说到了，这块区域不是在java heap上，那么这块内存的大小是多少呢？默认是一般是64M，可以通过参数：-XX:MaxDirectMemorySize来控制，你够牛的话，还可以用代码控制，呵呵，这里就不多说了。

3、直接内存好，我们为啥不都用直接内存？请注意，这个直接内存的释放并不是由你控制的，而是由full gc来控制的，直接内存会自己检测情况而调用system.gc()，但是如果参数中使用了DisableExplicitGC 那么这是个坑了，所以啊，这玩意，设置不设置都是一个坑坑，所以java的优化有没有绝对的，只有针对实际情况的，针对实际情况需要对系统做一些拆分做不同的优化。

4、那么full gc不触发，我想自己释放这部分内存有方法吗？可以的，在这里没有什么是不可以的，呵呵！私有属性我们都任意玩他，还有什么不可以玩的；我们看看它的源码中DirectByteBuffer发现有一个：Cleaner，貌似是用来搞资源回收的，经过查证，的确是，而且又看到这个对象是sun.misc开头的了，此时既惊喜又郁闷，呵呵，只要我能拿到它，我就能有希望消灭掉了；下面第五步我们来做个试验。

5、因为我们的代码全是私有的，所以我要访问它不能直接访问，我需要通过反射来实现，OK，我知道要调用cleaner()方法来获取它Cleaner对象，进而通过该对象，执行clean方法；（付：以下代码大部分也取自网络上的一篇copy无数次的代码，但是那个代码是有问题的，有问题的部分，我将用红色标识出来，如果没有哪条代码是无法运行的）

1. import java.nio.ByteBuffer;  
2. import sun.nio.ch.DirectBuffer;  
3.   
4. public class DirectByteBufferCleaner {  
5.   
6. public static void clean(final ByteBuffer byteBuffer) {  
7. if (byteBuffer.isDirect()) {  
8.                  ((DirectBuffer)byteBuffer).cleaner().clean();  
9.               }  
10.         }  
11. }

上述类你可以在任何位置建立都可以，这里多谢一楼的回复，以前我的写法是见到DirectByteBuffer类是Default类型的，因此这个类无法直接引用到，是通过反射去找到cleaner的实例，进而调用内部的clean方法，那样做麻烦了，其实并不需要那么麻烦，因为DirectByteBuffer implements了DirectBuffer，而DirectBuffer本身是public的，所以通过接口去调用内部的Clear对象来做clean方法。

我们下面来做测试来证明这个程序是有效地回收的：

在任意一个地方写一段main方法来调用，我这里就直接写在这个类里面了：

1. public static void sleep(long i) {  
2. try {  
3.           Thread.sleep(i);  
4. catch(Exception e) {  
5. /*skip*/  
6.      }  
7. }  
8. public static void main(String []args) throws Exception {  
9. 1024 * 1024 * 100);  
10. "start");  
11. 10000);  
12.        clean(buffer);  
13. "end");  
14. 10000);  
15. }

这里分配了100M内存，为了将结果看清楚，在执行前，执行后分别看看延迟10s，当然你可以根据你的要求自己改改。请提前将OS的资源管理器打开，看看当前使用的内存是多少，如果你是linux当然是看看free或者用top等命令来看；本地程序我是用windows完成，在运行前机器的内存如下图所示：

java byte decompiler不生效 java directbytebuffer_Java