這篇文章給大家分享的是有關(guān)JAVA序列號中serialVersionUID的示例分析的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。
成都創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括沙縣網(wǎng)站建設(shè)、沙縣網(wǎng)站制作、沙縣網(wǎng)頁制作以及沙縣網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，沙縣網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到沙縣省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
Java類通過實(shí)現(xiàn) java.io.Serializable 接口以啟用其序列化功能。未實(shí)現(xiàn)此接口的類將無法進(jìn)行序列化或反序列化。可序列化類的所有子類型本身都是可序列化的。
如果讀者看過Serializable的源碼，就會發(fā)現(xiàn)，他只是一個(gè)空的接口，里面什么東西都沒有。Serializable接口沒有方法或字段，僅用于標(biāo)識可序列化的語義。但是，如果一個(gè)類沒有實(shí)現(xiàn)這個(gè)接口，想要被序列化的話，就會拋出java.io.NotSerializableException異常。
序列號在寫成二進(jìn)制流的時(shí)候，會調(diào)用如下的方法：
Externalizable繼承自Serializable，該接口中定義了兩個(gè)抽象方法：writeExternal()與readExternal()。
當(dāng)使用Externalizable接口來進(jìn)行序列化與反序列化的時(shí)候需要開發(fā)人員重寫writeExternal()與readExternal()方法。否則所有變量的值都會變成默認(rèn)值。
transient 關(guān)鍵字的作用是控制變量的序列化，在變量聲明前加上該關(guān)鍵字，可以阻止該變量被序列化到文件中，在被反序列化后，transient 變量的值被設(shè)為初始值，如 int 型的是 0，對象型的是 null。
序列化是將對象的狀態(tài)信息轉(zhuǎn)換為可存儲或傳輸?shù)男问降倪^程。我們都知道，Java對象是保存在JVM的堆內(nèi)存中的，也就是說，如果JVM堆不存在了，那么對象也就跟著消失了。
而序列化提供了一種方案，可以讓你在即使JVM停機(jī)的情況下也能把對象保存下來的方案。就像我們平時(shí)用的U盤一樣。把Java對象序列化成可存儲或傳輸?shù)男问剑ㄈ缍M(jìn)制流），比如保存在文件中。這樣，當(dāng)再次需要這個(gè)對象的時(shí)候，從文件中讀取出二進(jìn)制流，再從二進(jìn)制流中反序列化出對象。
虛擬機(jī)是否允許反序列化，不僅取決于類路徑和功能代碼是否一致，一個(gè)非常重要的一點(diǎn)是兩個(gè)類的序列化 ID 是否一致，這個(gè)所謂的序列化ID，就是我們在代碼中定義的serialVersionUID。
這是因?yàn)?，在進(jìn)行反序列化時(shí)，JVM會把傳來的字節(jié)流中的serialVersionUID與本地相應(yīng)實(shí)體類的serialVersionUID進(jìn)行比較，如果相同就認(rèn)為是一致的，可以進(jìn)行反序列化，否則就會出現(xiàn)序列化版本不一致的異常，即是InvalidCastException。
如果我們沒有在類中明確的定義一個(gè)serialVersionUID的話，看看會發(fā)生什么。
嘗試修改上面的demo代碼，先使用以下類定義一個(gè)對象，該類中不定義serialVersionUID，將其寫入文件。
然后我們修改User1類，向其中增加一個(gè)屬性。在嘗試將其從文件中讀取出來，并進(jìn)行反序列化。
執(zhí)行結(jié)果：
java.io.InvalidClassException: com.hollis.User1; local class incompatible: stream classdesc serialVersionUID = -2986778152837257883, local class serialVersionUID = 7961728318907695402
同樣，拋出了InvalidClassException，并且指出兩個(gè)serialVersionUID不同，分別是-2986778152837257883和7961728318907695402。
從這里可以看出，系統(tǒng)自己添加了一個(gè)serialVersionUID。
所以，一旦類實(shí)現(xiàn)了Serializable，就建議明確的定義一個(gè)serialVersionUID。不然在修改類的時(shí)候，就會發(fā)生異常。
serialVersionUID有兩種顯示的生成方式：
一種是默認(rèn)的1L，比如：
private static final long serialVersionUID = 1L;
另外一種是根據(jù)類名、接口名、成員方法及屬性等來生成一個(gè)64位的哈希字段，比如：
private static final long serialVersionUID = xxxxL;
后面這種方式，可以借助IDE生成，后面會介紹。
為了簡化代碼量，反序列化的調(diào)用鏈如下：
在initNonProxy中 ，關(guān)鍵代碼如下：
在反序列化過程中，對serialVersionUID做了比較，如果發(fā)現(xiàn)不相等，則直接拋出異常。
深入看一下getSerialVersionUID方法：
在沒有定義serialVersionUID的時(shí)候，會調(diào)用computeDefaultSUID 方法，生成一個(gè)默認(rèn)的serialVersionUID。
這也就找到了以上兩個(gè)問題的根源，其實(shí)是代碼中做了嚴(yán)格的校驗(yàn)，并且在未定義的時(shí)候自動生成了一個(gè)serialVersionUID。
為了確保我們不會忘記定義serialVersionUID，可以調(diào)節(jié)一下Intellij IDEA的配置，在實(shí)現(xiàn)Serializable接口后，如果沒定義serialVersionUID的話，IDEA（eclipse一樣）會進(jìn)行提示：
并且可以一鍵生成一個(gè)：
當(dāng)然，這個(gè)配置并不是默認(rèn)生效的，需要手動到IDEA中設(shè)置一下： 
在圖中標(biāo)號3的地方（Serializable class without serialVersionUID的配置），打上勾，保存即可。
感謝各位的閱讀！關(guān)于“JAVA序列號中serialVersionUID的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！
重慶分公司
重慶分公司
