我们的产品中有一组位置需要BigInteger，因为数字可能相当长。然而，在超过90％的情况下，它们实际上并不长，并且可以很容易地包含在内。
看看BigInteger的实现，使用BigInteger就足够了。
创建一个具有BigInteger（除法，乘法等）函数的接口是否有意义，它将由BigInteger的子类和包装Long的类实现？类似的东西：
Interface: EfficientBigInteger
Class 1: MyBigInteger extends BigInteger imlpements EfficientBigInteger
Class 2: MyLong implements EfficientBigInteger (this will contain a Long, as we cannot extend the Long class)
也许我们在这方面走错了方向？
谢谢， Yon的
UPDATE：这些对象（Long或BigInteger）存储在内存中已有一段时间了，因为它们可以帮助我们识别与之交互的系统的问题行为。因此，内存占用可能是个问题。这是我们试图避免的问题。 BigInteger类有几个字段（signum，mag数组，bitcount等等），它们大致是封装Long的类的两倍（考虑到首先拥有Object的内存成本）。这意味着我们使用了很多东西的占地面积加倍。
答案 0 :(得分：6)
你必须对这些值进行算术运算吗？因为如果你这样做，那么一个以long开头的可能会变成一个BigInteger，这听起来很痛苦：你必须在每个算术运算之前进行一次测试，它可能会超过MAX_LONG。好吧，我想你可以在你的包装类中包含所有这些。与BigInteger类循环遍历1或2个数组的数组的时间相比，测试溢出需要多长时间？
如果你不做算术，那么使用long的节省将是最小的。你在BigInteger上做什么，只是阅读并写出来？在那种情况下，几乎肯定不值得这么麻烦。
就个人而言，这是我自己想要做的事情，我理解你的想法。但后来我退后一步说：这里的表现真的是个问题吗？ JUst我们做了多少算术？我们会获得多少性能提升？是否值得增加程序的复杂性并可能引入错误？
除非你有理由相信表现确实是一个问题而且这样做会产生重大影响，否则我不会。
答案 1 :(得分：4)
我在1986年左右为Cobol编译器实现了这样的功能。它对性能没有任何影响：确定它是否适合长时间然后将其转换为long然后再返回的开销等于时间节省。