所以Java NIO架构师没有创建ByteBuffer接口，而是ByteBuffer class，它不是最终类，但它没有包 - 公共构造函数，因此它可以不要在其包装之外进行子类化。阿福。 ：P
我有一个程序在一堆地方使用内存映射文件字节缓冲区（通过FileChannel.map（）获得），我正在尝试追踪一个令人讨厌的错误，因为有问题的文件是打开的，因为至少有一个ByteBuffer未发布到垃圾回收中。
我喜欢创建一个看起来像字节缓冲区的InstrumentedByteBuffer类，但是装饰一个普通的ByteBuffer（或它的子类，例如MappedByteBuffer）和跟踪它的存在（包括由duplicate()和slice()创建的新缓冲区） - 这样我可以保持我的代码完整使用ByteBuffer，我只需要修饰原始字节缓冲区。
有没有办法做到这一点（通过反射或代理或其他）绕过私有构造函数？我不需要将它发送到最终产品中，我只需要暂时使用它来解决这个错误。
答案 0 :(得分：2)
我正在尝试追踪有问题的文件中的一个令人讨厌的错误 保持打开状态，因为至少有一个未释放的ByteBuffer 垃圾收集
这没有意义。未收集的ByteBuffer不会停止文件被关闭。你在这里咆哮着错误的树。但是MappedByteBuffer存在一个众所周知的问题，即 it 永远不会被垃圾收集，从而使文件保持有效打开状态。这确实是一个设计问题：多年来人们都知道它，但没有真正的解决方案。道德是不要使用大量的MappedByteBuffers。
答案 1 :(得分：2)
JMockit提供了一种创建模拟类的便捷方法。在这种情况下，它可能会有所帮助。
模拟您感兴趣的方法，让他们进行簿记和then call the original class' method。
答案 2 :(得分：0)
我不明白为什么你需要在这里进行子类化。为什么不使用AOP？ AspectJ似乎非常适合这份工作。如果你真的有野心，请使用Java Instrumentation并进行一些字节码工程：P
答案 3 :(得分：0)
嗯 - 我刚碰到过：JavaSpecialists newsletter 168似乎可以产生一个通用的委托框架 - 如果由于反射有点慢。
Socket使用策略模式进行实际通信，我们可以指定自己的实现。因此，我们需要做的就是编写自己的策略来计算向后和向前流动的字节数。不幸的是，标准策略实现是java.net。*包中的包访问，因此我们无法直接使用它们。我们当然不能将它们子类化，但我们可以用反射来调用这些方法。但是，因为类本身是包访问，所以我们需要找到声明的构造函数，将其设置为可访问，然后实例化它。
答案 4 :(得分：0)
我认为你走错了路。 FileChannel.map（）被设计破坏，因为它限制为2GB块，并且您无法控制何时应该通过垃圾收集拾取映射。在Windows上，这是应用程序无法再次打开映射文件的常见原因。
因此，不应该使用字节码指令或类似的黑客使事情更糟，你应该重构你的代码以摆脱FileChannel.map（）。如果你做的话，下一个必须维护代码的程序员将非常感激。 ; - ）