2016-12-28 174 views
-1

雖然我搜索了很多,但無法找到相同的合理答案。 爲什麼serialrialuid不能加倍?保持serialversionuid長的任何具體原因?爲什麼Serialrialuid在java中很長?

+3

爲什麼有一個類型爲double的id有用? – Hulk

+0

因爲'Serializable'的javadoc是這樣說的嗎? – assylias

+0

因爲'long'具有更多的精度。因爲「長」是確切的。因爲「double」的小數部分不是必需的。因爲沒有人會尊重「雙」的優勢。由於[Javadoc](http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html)和[對象序列化規範](https://docs.oracle.com) /javase/8/docs/platform/serialization/spec/class.html)這樣說。 – EJP

回答

3

一個唯一的ID通常是一個隨機選擇的整數。例如UUID是兩個很長的值。

使用double是非常困難的,因爲並非所有的64位值都在Java中使用,並且某些值不等於它們自己。 Double.NaN。

順便說一句,如果你真的想使用double你能做到這一點

private static final long serialVersionUID = Double.doubleToRawLongBits(1.28); 

但使用浮點值將有我不知道還有什麼價值。如果要編碼的版本號,你可以做到這一點

private static final long serialVersionUID = MAJOR * 1000 + MINOR; 
0

一個UID的東西,必須是在序列化給定的背景下獨特的,因爲它通常由集成開發環境或計算產生的Serializable實例時,程序員。對於應該是唯一的東西,long數據類型似乎是合理的。合理,因爲它是一個隱含的數據類型,並且是double旁邊最大的一個。數據類型越大,生成唯一ID時出現衝突的機率就越低。 (想象一下,使用byte作爲serialVersionUID的數據類型,您將只有256個可用值來生成「唯一」ID,這將導致很多衝突)。數據類型double與其他double值有其自身的問題。 long沒有這樣的問題。另一方面,使用String或其他參考類型可能不合適,因爲在空間和時間複雜性方面它可能是昂貴的。所有這些原因使得long成爲使用它作爲serialVersionUID的數據類型的合理選擇。

有關更多信息,請參閱this article。我也提取了一些相同的東西。

序列化運行時相關聯,每個序列化類版本號,稱爲的serialVersionUID,其被反序列化過程用於驗證序列化對象的發送者和接收者都加載的類該對象是相對於兼容序列化。如果接收者已經爲與對應的發送者類具有不同serialVersionUID的對象加載了類,則反序列化將導致InvalidClassException。可序列化類可以通過聲明名爲「serialVersionUID的」字段必須是靜態的,最終明確宣佈了自己的serialVersionUID,並鍵入長:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L; 

如果一個序列化類沒有顯式聲明的serialVersionUID ,那麼序列化運行時將基於該類的各個方面計算該類的默認serialVersionUID值,如Java(TM)對象序列化規範中所述。但是,強烈建議所有可序列化的類顯式聲明serialVersionUID值,因爲默認的serialVersionUID計算對類詳細信息高度敏感,這可能因編譯器實現而異,因此在反序列化期間可能會導致意外的InvalidClassException。因此,要確保跨不同的java編譯器實現保持一致的serialVersionUID值,可序列化的類必須聲明顯式的serialVersionUID值。還強烈建議顯式serialVersionUID聲明儘可能使用private修飾符,因爲這些聲明僅適用於立即聲明的類 - serialVersionUID字段作爲繼承成員是無用的。數組類無法聲明顯式的serialVersionUID,因此它們始終具有默認的計算值,但是對於數組類而言,不需要匹配serialVersionUID值。

希望這會有所幫助!

相關問題