摘要:二調試過程經過后發現,在類型數值比較中使用的是,咋看之下沒啥問題,其實是有問題的在這里為包裝類,是一個對象。使用包裝類重寫過的方法就可以正確對包裝類型的數值正確進行判斷了。
一、問題描述
在一次對樹形結構的數據遍歷中,出現了樹形變亂的問題,在此遍歷的ID采用Long類型,在數值比較中達到某個界定值后,樹形結構變形。
二、調試過程經過debug后發現,在Long類型數值比較中使用的是 “==” ,咋看之下沒啥問題,其實是有問題的!在這里Long為包裝類,是一個對象。
在這里回顧一下基本的知識吧:
判斷兩個對象是否為同一對象,是通過內存中地址是否一致為判定的,使用 == 或.equals(obj)即可進行判定。
那么為什么一些數值比如1、2、3、4之類的Long對象使用==可以正確判斷呢?
在這里我們可以看到Long類型的數值從-128~127 在一開始已經放進去了靜態代碼塊里面的cache數組里面,
而基本包裝類型在自動裝箱成包裝類型的時候會從緩存里面取:
可以看到在數字大于-128 或 小于127的時候,是直接從cache里面取出來的,所以在這個數值范圍內的Long類型對象是可以直接進行比較的,但是超出了這個范圍,就會new 新的Long類型,這就導致使用 == 判斷不正確,也就是樹形結構在id超出127后就發生了變化。使用包裝類重寫過的equals方法就可以正確對包裝類型的數值正確進行判斷了。
四、后續結語后來在查看《阿里巴巴java開發規范》時候也看到了:
這些不止是適用于Integer或是Long,所有包裝類都適用。
有些問題雖然不大,但是卻是值得我們去深思的 。 加油。 :)
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/72813.html
摘要:多用戶博客系統該多用戶博客系統,是在之前一開始學習的使用的時候,大佬說讓去做一個系統性的項目,這樣前后端兼顧,從里面去系統性的總結東西,索性就做了一個這個,項目的架子是根據一個開源項目的指導進行入坑的,陸陸續續用了四個月時間,由于是剛步入大 多用戶博客系統 該多用戶博客系統,是在之前一開始學習node的使用的時候,大佬說讓去做一個系統性的項目,這樣前后端兼顧,從里面去系統性的總結東西...
摘要:這一點其實是非常不妥的,有潛在的安全問題。這次,在項目中終于采用了以它為基礎的集群方案。相反,使用一個周期,但針對每個生成一個一次性的,模擬隨機發送。同時,要記得用完之后立即釋放。 當初創建簡書賬號的時候曾立下宏愿,希望保持周更,無奈現實殘酷,整個5月都處于忙忙碌碌的狀態,居然令這個本來并不算太宏偉的目標難以為繼,最終導致5月份交了白卷!【好吧,我承認,是我意志不夠堅定,太懶了,;)】...
摘要:不相等的對象要具有不相等的哈希碼為了哈希表的操作效率,這一點很重要,但不是強制要求,最低要求是不相等的對象不能共用一個哈希碼。方法和方法協同工作,返回對象的哈希碼。這個哈希碼基于對象的身份生成,而不是對象的相等性。 本文面向 剛學完Java的新手們。這篇文章不講語法,而是一些除了語法必須了解的概念。 將要去面試的初級工程師們。查漏補缺,以免遭遇不測。 目前由于篇幅而被挪出本文的知識...
摘要:接收三個參數分別為回調和,其中與是可選參數。官網釋義排序一個列表組成一個組,并且返回各組中的對象的數量的計數。類似,但是不是返回列表的值,而是返回在該組中值的數目。 繼續前面的內容,前文我們提到了很多方法的講解,其實到這里就已經差不多了,因為大部分代碼其實都是套路,一些基礎函數再靈活變化就可以組成很多實用的功能。 _.sortBy = function(obj, iteratee,...
閱讀 830·2021-09-22 15:18
閱讀 1181·2021-09-09 09:33
閱讀 2758·2019-08-30 10:56
閱讀 1184·2019-08-29 16:30
閱讀 1488·2019-08-29 13:02
閱讀 1458·2019-08-26 13:55
閱讀 1643·2019-08-26 13:41
閱讀 1941·2019-08-26 11:56