超碰人人人人人,亚洲AV午夜福利精品一区二区,亚洲欧美综合区丁香五月1区,日韩欧美亚洲系列

問題

今天在網(wǎng)上看到一個有意思的問題，金額的數(shù)據(jù)類型用Long還是BigDecimal？

具體問題大概是這樣的：關(guān)于金額的數(shù)據(jù)類型，組長認(rèn)為使用BigDecimal比較穩(wěn)妥，總監(jiān)認(rèn)為使用Long才不會出問題，然后開發(fā)認(rèn)為Long用起來比較爽。

從這兩個數(shù)據(jù)類型來看，這家公司使用的開發(fā)語言應(yīng)該是Java，不過換成其它開發(fā)語言，也有類似的數(shù)據(jù)類型選擇問題，這是一個廣泛存在的問題，所以可以和大家好好聊聊。

網(wǎng)友方案

針對這個問題，熱情的網(wǎng)友們從各自的經(jīng)歷出發(fā)，提供了很多方案。我大概總結(jié)了下，居然有十種之多，雖然有的像調(diào)侃，但都有一定的道理。相信大家也很好奇，所以這里我先分享下網(wǎng)友們的方案。

Long

解讀：單位到分，沒有小數(shù)點，也就沒有小數(shù)精度的問題。而且Long取值范圍也足夠了。

BigDecimal

解讀：大家都這么用，BigDecimal就是為精確計算而生的。用long不專業(yè)，適應(yīng)性不好。

Long和BigDecimal

解讀：成年人不做選擇，成年人什么都要。金額、價格這些用Long，匯率、費率這些要求的小數(shù)點比較多，那就用BigDecimal。

String

解讀：萬物皆可string。只是處理規(guī)則需要全部自己寫，高手必備的技能。

Protobuf

解讀：脫離框架講方案都是耍流氓。Protobuf里邊根本就沒有BigDecimal，雖然可以用string或者自定義類型來代表Java中的BigDecimal，不過性能可能要差那么一點點。

自定義

解讀：架構(gòu)師的好苗子。程序不是能跑起來、不出錯就行了，要考慮設(shè)計能不能自然體現(xiàn)業(yè)務(wù)需求，好不好理解、擴(kuò)展和維護(hù)。

聽領(lǐng)導(dǎo)的

解讀：霍金來了中國也得站起來敬酒。這根本不是技術(shù)問題，一切聽領(lǐng)導(dǎo)指示，但是也要做好自我保護(hù)。

問AI

解讀：緊跟時代風(fēng)口。作為有追求的技術(shù)人，就應(yīng)該想著怎么偷懶怎么最快，先進(jìn)的生產(chǎn)力工具要用起來，大語言模型回答這個問題滴水不漏、手到擒來，不信你試試！

節(jié)省型

解讀：節(jié)儉是美德。就幾百塊錢的貨，又不是航母和火箭，根本用不著Long，用int、short，甚至byte就能滿足。

莫名其妙

解讀：這個特定芯片是說CPU的位寬不一樣嗎？比如16位、32位CPU加減乘除的結(jié)果可能不同。不懂，真不懂，完全不懂這條評論在說什么問題，請有經(jīng)驗的大神幫解答下。

根本問題

俗話說，結(jié)局問題先得明確問題。那么這到底是個什么問題呢？歸根到底還是小數(shù)的精度問題。

有時候是根本除不盡，比如10除以3；有時候是因為小數(shù)的表達(dá)問題，編程語言中帶小數(shù)的數(shù)據(jù)類型一般是float和double，它們內(nèi)部使用科學(xué)計數(shù)法，轉(zhuǎn)換二進(jìn)制的時候有可能出現(xiàn)無限小數(shù)位的問題，比如Javascript中的0.1+0.2算出來就不是0.3，因為浮點數(shù)無法精確的表達(dá)0.1。

所以為了避免此類問題，大家想出來了各種各樣的方法。

其實使用Long和BigDecimal的本質(zhì)都是一樣的，都是避免使用浮點數(shù)進(jìn)行表達(dá)，只是Long屬于隱式設(shè)定小數(shù)點，BigDecimal屬于顯示設(shè)定小數(shù)點。

比如，使用Long表示價格時，系統(tǒng)約定單位是分，那么9999就代表99.99元；而使用BigDecimal表示價格時，則需要明確小數(shù)位 new BigDecimal("99.99")。

另外不管是Long還是BigDecaimal在進(jìn)行除法運算時，只要發(fā)生除不盡，就存在精度問題。

解決方案

這里我做個總結(jié)。

在程序中處理金額時，最佳實踐通常是使用類似BigDecimal的數(shù)據(jù)類型，因為它提供了精確的小數(shù)運算能力，這對于財務(wù)計算來說非常重要。使用BigDecimal可以避免因浮點數(shù)的精度問題導(dǎo)致的計算誤差，這些誤差在金融應(yīng)用中可能會導(dǎo)致嚴(yán)重的問題。

BigDecimal可以精確地表示和計算小數(shù)，它允許你定義小數(shù)點后的精度，并且提供了一系列的舍入模式。這意味著當(dāng)你需要執(zhí)行加減乘除時，可以控制舍入行為以符合金融計算的要求。

另一方面，雖然使用Long類型來表示金額（通常以分為單位）也是一種選擇，因為它避免了小數(shù)的使用，從而也能保證精確性。但是，這種方法在表示和處理小數(shù)時就不那么直觀，而且在需要進(jìn)行貨幣轉(zhuǎn)換或者涉及到小數(shù)的計算時，你必須自己管理小數(shù)點的位置。

例如，如果使用Long表示金額，你需要記住金額是以分為單位還是以元為單位，而且在報告或用戶界面中顯示金額時，通常需要將金額轉(zhuǎn)換為以元為單位的格式，這就需要額外的計算步驟。

所以，雖然Long類型也可以用來精確地表示金額，但是為了代碼的可讀性、易用性和減少手動處理小數(shù)點的錯誤，推薦使用BigDecimal來處理金額。這是一種更安全、更靈活的方法，尤其是在需要精確計算小數(shù)時。

其它使用string或者自定義類的方案，當(dāng)然也可以，只是需要更多的工作來完善數(shù)據(jù)處理的各種規(guī)則，容易出錯，也不規(guī)范，為什么不使用現(xiàn)成的BigDecimal呢？

作者：螢火架構(gòu)
鏈接：https://juejin.cn/post/7314928953193578505
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。