什么时候应该使用原语而不是包装对象？
实际上这里是类似的话题，实用价值不大。 据我了解，原语性能更好，应该在任何地方使用，除了需要对象相关功能（例如 null 检查）的情况。 正确的？
Actually here is a similar topic with little practical value.
As far as I understand, primitives perform better and should be used everywhere except for the cases where Object-related features (e.g. null check) are needed. Right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
不要忘记，因为为每个装箱事件创建一个新的包装器非常昂贵，特别是考虑到它通常在方法的单个范围内使用，自动装箱 使用一组通用包装器。
这实际上是 享元设计模式。 当众所周知的值发生装箱时，不是创建新的包装器实例，而是从池中获取并返回预先创建的实例。
后果之一是：仍然不建议使用自动装箱进行科学计算。 例如，代码 d = a * b + c 对 a、b、c 和 d 使用 Integer 类，生成的代码为 d.valueOf(a.intValue() * b.intValue() + c.intValue( ））。 所有这些方法调用都有自己的开销，因此通常建议在需要在集合中存储基元时使用自动装箱。
即便如此，如果您有一个巨大的集合整数包装int，开销可能意味着更长的执行时间，最多20倍长，如本文报道。
Jb 添加了这条重要评论：
Do not forget that, since creating a new wrapper for every boxing occurrence is quite expensive, especially considering it usually being used at a single scope of a method, Autoboxing uses a pool of common wrappers.
This is in fact an implementation of the flyweight design pattern. When a boxing occurs for a well-known value, instead of creating a new wrapper instance, a pre-created instance is fetched from a pool and returned.
One consequence is: it’s still not recommended to use autoboxing for scientific calculations. For example, the code d = a * b + c is using Integer classes for a, b, c and d, and the generated code is d.valueOf(a.intValue() * b.intValue() + c.intValue()). All these method invocations have their own overhead, so it’s usually recommended to use autoboxing when needed to store primitives in collections.
And even then, if you have a huge collection of Integer wrapping int, the overhead can implies longer execution times, up to 20 times longer, as reported in this article.
Jb adds this important comment:
基元在使用时速度更快，因为对象需要在使用前拆箱； 因此虚拟机需要执行一个额外的步骤。 例如，为了对 Integer 执行算术运算，必须先将其转换为 int，然后才能执行算术运算。
在许多业务应用程序中，这可能并不重要。 但是，如果您正在编写一些需要大量数字运算的东西，例如图形转换处理器，您就更有可能关心。
Primitives are faster when they are used, as objects need to be unboxed before use; thus there is an extra step for the VM to perform. For example, In order perform arithmetic on an Integer, it must first be converted to an int before the arithmetic can be performed.
In many business applications this probably rarely matters. But if you were writing something very numnber-crunching heavy like, say, a graphics transformation processor you are a lot more likely to care.
是的，基元比对象更快。
从 java 5 开始，您甚至可以混合基元和对象，而无需手动将其转换为另一种。
自动装箱机制就可以解决这个问题。
这意味着如果您将一个基元放入集合中，编译器不会抱怨，并将该基元隐式转换为对象。
yes, primitives are faster than objects.
Since java 5 you can even mix primitives and objects without manually converting one to another.
The autoboxing mechanism takes care of just that.
this means that if you put a primitive in a collection, the compiler will not complain, and convert the primitive to an object implicitly.
如果您需要在集合中存储基元，您可以使用 commons-primitives。
我更喜欢使用基元而不是包装器，只有绝对需要包装器的地方才是实体类。 数据库支持空值，因此实体也应该支持空值。
我曾经参与过一个在数据库访问中使用原语（和自制 ORM）的项目：
然后你就会发现：
上帝啊，这太邪恶了。
If you need store primitives in collections you might use commons-primitives.
I prefer using primitives to wrappers, only place that absolutely needs to have wrappers are entity classes. Databases support nulls, so entities should too.
I once worked on project that used primitives (and homebrew ORM) in database access:
And then you had:
God it was evil.
我想说，只有当您分析应用程序并发现自动装箱是性能或内存问题时，您才应该担心在包装器上使用原语。 根据我的经验，当谈论基元与包装对象时，内存在 CPU 周期之前就成为一个问题。
I would say you should be worried about using primitives over wrappers only when you profile your application and see that the autoboxing is a performance or memory issue. In my experience memory becomes an issue before CPU cycles when talking about primitives vs wrapping objects.