java.nio为何未提供支持ByteBuffer入参的BigInteger构造方法？

你提到的性能浪费问题是客观存在的：

• 对于堆上的ByteBuffer，直接调用array()拿到底层字节数组，再用new BigInteger(byte[], int, int)构造确实是性能最优的方案，没有额外拷贝开销。
• 但面对直接缓冲区、内存映射缓冲区时，这套方案走不通，必须先申请一段临时字节数组，把缓冲区里的对应内容读进数组，再传给构造方法；构造方法内部会把字节数组转成自身存储用的int[]数组，之后临时字节数组就直接变成垃圾等待回收，这部分拷贝和临时对象的开销完全是无意义的。
• 从实现难度来说，加一个new BigInteger(ByteBuffer, int, int)的构造方法确实没什么工作量：现有构造方法里把字节转成内部int[]表示的核心逻辑完全不用改，只要把原来从字节数组按偏移取字节的操作，换成从ByteBuffer按位置读字节就行，核心代码改动量非常小。

这么多年官方没加这个API，核心原因有三个：

1. 需求优先级不足
   JDK核心类的API新增要走严格的评审流程，优先级永远向高频通用需求倾斜。BigInteger的绝大多数使用场景是密码学、大数计算，高频从NIO缓冲区反序列化BigInteger属于非常细分的场景，大部分开发者根本碰不到这个性能瓶颈，自然很难排进高优先级的开发列表。
2. API设计的隐形成本高
   写实现代码只需要几十行，但敲定API的行为规则要花多得多的成本：比如构造方法要不要修改传入ByteBuffer的当前position？要不要自动处理小端字节序？遇到只读缓冲区、直接缓冲区、堆缓冲区的行为要不要完全一致？这些边界规则一旦定错，后续就会背上永久的兼容包袱，远不是写几行代码那么简单。
3. 自定义实现门槛极低
   对性能敏感的开发者完全可以自己绕开临时数组拷贝：直接从ByteBuffer按字节读取内容，自己拼出BigInteger内部需要的int[]存储结构，再通过反射或者Unsafe直接实例化BigInteger对象，性能和官方原生实现没有区别，也不需要等JDK更新API，这也进一步降低了官方加这个接口的动力。

如果你现在就需要解决这个性能问题，完全可以自己实现对应的解析逻辑，只要注意处理符号位、前导零、字节序三个边界点即可，代码量不大。

内容的提问来源于stack exchange，提问作者andbi