在实际应用程序中使用向下转换答案

【问题标题】：Using downcasting in real app life在实际应用程序中使用向下转换
【发布时间】：2013-07-16 20:44:05
【问题描述】：

我知道隐式转换是由编译器和虚拟机自动完成的，当 Java 不确定结果是否有效时，需要显式转换来转换数据类型。转换应该在基元之间或对象之间进行。

我的问题是：如果我的应用程序同时使用整数和长整数 - 我应该对这两种类型都使用 long 吗？或向下转换long？还是投给int？

对这两种类型使用 long 会导致一些问题吗？

【问题讨论】：

您应该确保您的变量可以容纳所有有效值。如果一个变量可以包含大于最大整数的值，它应该是一个长整数。
@Heuster：所以一切都需要很长时间？
@Thilo 我认为您在实践中几乎不会遇到“孤独”的 long ......要么很多值都很大（在这种情况下 long 是唯一合乎逻辑的选择），要么根本没有。所以不，不只是渴望一切，只有在有意义的时候才渴望:)
@Thilo long 常用来表示货币（考虑到float 的精度问题），它也常用来表示时间戳，也用于自动递增的 ID。要点是：有一些特定的用例需要 64 位整数，其中 9/10 是 - 如果考虑得当 - 您将能够在设计阶段识别出来。

【解决方案1】：

我可能会为正确的操作选择正确的数据类型，long 如果我需要 long，int 如果 int 足以满足我的要求。 一般来说，将long 用于int 可能会降低您的速度，但这又取决于具体的JVM 实现。您必须根据您要定位的范围来决定。

同样，如果您的程序中涉及大量转换，那么最好选择像 long 这样的数据类型，它可以容纳比 int 更大的范围，并且可以避免转换和数据丢失那个过程。话虽如此，long 可能比 int 慢，尽管在现代处理器和 JVM 中我怀疑这可能会影响很大。

也许，这里开明的人可以更好地回答这个问题。

您还可以阅读一些不错的 SO Q&A here 和 here。

【讨论】：

当然，在任何地方使用long 也会占用更多内存
我不认为 long 比 int 慢，尽管正如您所说，这取决于底层架构的 JVM 实现。很可能 64 位 JVM 在使用 long 时不会出现速度问题（甚至可能比使用 int 更快，因为它是本机字长）

【解决方案2】：

我认为您应该使用涵盖所有值的数据类型，因此我会为所有内容使用long，因为它可以简化代码并避免潜在的风险转换。

从long 转换为int 可能会使您丢失数据，因为long 大于int（因此数据在转换中被截断）。
从int 到long 的转换几乎（参见下面Colin Morelli 对此的评论）与从一开始就使用long 相同，您可以避免使用两种类型。此外，这种强制转换没有任何意义，因为您实际上是在毫无意义地占用内存（除非您使用 int 并且某个方法明确需要 long 作为参数，那么您显然别无选择，只能强制转换）。

我看到使用long 的缺点是：

【讨论】：

实际上，从int 转换为long 与从一开始就使用long 不同。由于原语是按值传递的，因此您可以将 int 传递 5 个深度，然后然后进行 long 转换，留下 5 个 ints 和 1 个 long，而不是 6 个longs。在这种特定情况下，差异很小，但可能会导致潜在的巨大内存差异
@ColinMorelli 绝对，我没有考虑到这一点。

【解决方案3】：

这取决于您的日期范围。看看The Java Tutorials: Primitive Data types，如果你知道你的数字将在Integer.MIN_VALUE 和Integer.MAX_VALUE 之间，不要甜，铸造将按预期工作。否则，请选择 long 或 BigInteger。

【讨论】：

【解决方案4】：

您确实需要更清楚自己处理的数字范围。那么对于给定的输入，最好的选择是使用long。但是如果你真的需要让它通用并且内存不是一个限制，那么你可以使用BigInteger。

【讨论】：