金额用Long还是BigDecimal?

发布时间:2024年01月11日

问题

今天在网上看到一个有意思的问题,金额的数据类型用Long还是BigDecimal?

具体问题大概是这样的:关于金额的数据类型,组长认为使用BigDecimal比较稳妥,总监认为使用Long才不会出问题,然后开发认为Long用起来比较爽。

从这两个数据类型来看,这家公司使用的开发语言应该是Java,不过换成其它开发语言,也有类似的数据类型选择问题,这是一个广泛存在的问题,所以可以和大家好好聊聊。

网友方案

针对这个问题,热情的网友们从各自的经历出发,提供了很多方案。我大概总结了下,居然有十种之多,虽然有的像调侃,但都有一定的道理。相信大家也很好奇,所以这里我先分享下网友们的方案。

Long

解读:单位到分,没有小数点,也就没有小数精度的问题。而且Long取值范围也足够了。

BigDecimal

解读:大家都这么用,BigDecimal就是为精确计算而生的。用long不专业,适应性不好。

Long和BigDecimal

解读:成年人不做选择,成年人什么都要。金额、价格这些用Long,汇率、费率这些要求的小数点比较多,那就用BigDecimal。

String

解读:万物皆可string。只是处理规则需要全部自己写,高手必备的技能。

Protobuf

解读:脱离框架讲方案都是耍流氓。Protobuf里边根本就没有BigDecimal,虽然可以用string或者自定义类型来代表Java中的BigDecimal,不过性能可能要差那么一点点。

自定义

解读:架构师的好苗子。程序不是能跑起来、不出错就行了,要考虑设计能不能自然体现业务需求,好不好理解、扩展和维护。

听领导的

解读:霍金来了中国也得站起来敬酒。这根本不是技术问题,一切听领导指示,但是也要做好自我保护。

问AI

解读:紧跟时代风口。作为有追求的技术人,就应该想着怎么偷懒怎么最快,先进的生产力工具要用起来,大语言模型回答这个问题滴水不漏、手到擒来,不信你试试!

节省型

解读:节俭是美德。就几百块钱的货,又不是航母和火箭,根本用不着Long,用int、short,甚至byte就能满足。

莫名其妙

解读:这个特定芯片是说CPU做不了浮点数运算吗?还是说不同的CPU浮点数运算的算法不同?那编程语言不能直接处理这个问题吗?还需要开发者关心。不懂,真不懂,完全不懂,请有经验的大神帮解答下。

根本问题

俗话说,结局问题先得明确问题。那么这到底是个什么问题呢?归根到底还是小数的精度问题。

有时候是根本除不尽,比如10除以3;有时候是因为小数的表达问题,编程语言中带小数的数据类型一般是float和double,它们内部使用科学计数法,转换二进制的时候有可能出现无限小数位的问题,比如Javascript中的0.1+0.2算出来就不是0.3。

所以为了避免此类问题,大家想出来了各种各样的方法。

其实使用Long和BigDecimal的本质都是一样的,他们内部都是通过整数记录值,只是Long属于隐式设定小数点,BigDecimal属于显示设定小数点。

比如,使用Long表示价格时,系统约定单位是分,那么9999就代表99.99元;而使用BigDecimal表示价格时,则需要明确小数位 new BigDecimal("99.99")。

另外不管是Long还是BigDecaimal只要发生除不尽,就存在精度问题。

解决方案

这里我做个总结。

在程序中处理金额时,最佳实践通常是使用类似BigDecimal的数据类型,因为它提供了精确的小数运算能力,这对于财务计算来说非常重要。使用BigDecimal可以避免因浮点数的精度问题导致的计算误差,这些误差在金融应用中可能会导致严重的问题。

BigDecimal可以精确地表示和计算小数,它允许你定义小数点后的精度,并且提供了一系列的舍入模式。这意味着当你需要执行加减乘除时,可以控制舍入行为以符合金融计算的要求。

另一方面,虽然使用Long类型来表示金额(通常以分为单位)也是一种选择,因为它避免了小数的使用,从而也能保证精确性。但是,这种方法在表示和处理小数时就不那么直观,而且在需要进行货币转换或者涉及到小数的计算时,你必须自己管理小数点的位置。

例如,如果使用Long表示金额,你需要记住金额是以分为单位还是以元为单位,而且在报告或用户界面中显示金额时,通常需要将金额转换为以元为单位的格式,这就需要额外的计算步骤。

所以,虽然Long类型也可以用来精确地表示金额,但是为了代码的可读性、易用性和减少手动处理小数点的错误,推荐使用BigDecimal来处理金额。这是一种更安全、更灵活的方法,尤其是在需要精确计算小数时。

其它使用string或者自定义类的方案,当然也可以,只是需要更多的工作来完善数据处理的各种规则,容易出错,也不规范,为什么不使用现成的BigDecimal呢?


以上就是本文的主要内容。

关注萤火架构,提升技术不迷路!

文章来源:https://blog.csdn.net/bossma/article/details/135536945
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。