争论不休:金额用Long还是BigDecimal?
问题
今天在网上看到一个有意思的问题,金额的数据类型用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呢?
以上就是本文的主要内容。
关注萤火架构,提升技术不迷路!
来源:juejin.cn/post/7314928953193578505