java – 为什么RandomAccessFile writeLong用多次写调用实现?

前端之家收集整理的这篇文章主要介绍了java – 为什么RandomAccessFile writeLong用多次写调用实现?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

在分析应用程序时,我注意到RandomAccessFile.writeLong花了很多时间.

我检查了这个方法代码,它涉及8次本机方法写入调用.
我使用byte []为writeLong编写了一个替代实现.像这样的东西:

RandomAccessFile randomAccessFile = new RandomAccessFile("out.dat","rwd");
...
byte[] aux = new byte[8];
aux[0] = (byte) ((l >>> 56) & 0xFF);
aux[1] = (byte) ((l >>> 48) & 0xFF);
aux[2] = (byte) ((l >>> 40) & 0xFF);
aux[3] = (byte) ((l >>> 32) & 0xFF);
aux[4] = (byte) ((l >>> 24) & 0xFF);
aux[5] = (byte) ((l >>> 16) & 0xFF);
aux[6] = (byte) ((l >>> 8) & 0xFF);
aux[7] = (byte) ((l >>> 0) & 0xFF);
randomAccessFile.write(aux);

我做了一个小基准测试并得到了这些结果:

Using writeLong():
Average time for invocation: 91 ms

Using write(byte[]):
Average time for invocation: 11 ms

在具有Intel(R)cpu T2300 @ 1.66GHz的Linux机器上进行测试

由于本机调用会有一些性能损失,为什么writeLong会以这种方式实现?
我知道应该向太阳队员提出这个问题,但我希望这里的人有一些提示.

谢谢.

最佳答案
我会投票反对懒惰,或者(更加慈善)不考虑后果.

writeLong()的本机实现可能需要每个体系结构的版本,以处理字节排序(JNI将转换为平台字节顺序).通过将转换保持在“跨平台”层,开发人员简化了移植工作.

至于为什么他们在Java端没有转换为数组,我怀疑这是因为害怕垃圾收集.我猜想RandomAccessFile自1.1以来已经发生了微小的变化,直到1.3,垃圾收集才开始使小对象分配“免费”.

但是,还有RandomAccessFile的替代方案:看看MappedByteBuffer

编辑:我有一台JDK 1.2.2的机器,从那时起这个方法没有改变.

猜你在找的Java相关文章