למה להשתמש ב-SerialVersionUID בתוך מחלקה Serializable ב-Java

Serializationותמיד SerialVersionUIDנשאר בגדר תעלומה למפתחי Java רבים. לעתים קרובות אני רואה שאלות לגבי מה זה SerialVersionUID, או מה קורה אם אני לא מצהיר בכיתה SerialVersionUIDשלי Serializable? מלבד היותו מבלבל ושימוש נדיר, סיבה נוספת לשאלה זו היא האזהרה החסרה של Eclipse IDE , SerialVersionUIDלמשל: " The Serializable class Customer לא מכריז על שדה סטטי סופי SerialVersionUIDSerializable מסוג long " במאמר זה תלמדו לא רק את היסודות של ג'אווה אלא גם את השפעתה על תהליך ההמשכה והדה-סריאליזציה. כאשר אתה מכריז על מחלקה, כמו על ידי הטמעת ממשק אסימון , זמן הריצה של Java מאחסן מופע של אותה מחלקה בדיסק באמצעות מנגנון ברירת המחדל של הסידרה אלא אם כן תגדיר את התהליך לשימוש בממשק להחצנה . במהלך הסידרה, זמן הריצה של Java יוצר מספר גרסה עבור המחלקה, כך שהיא תוכל לבטל אותה בהמשך. ב-Java, מספר גרסה זה ידוע בשם . אם, במהלך הדה-סריאליזציה, אין התאמה, התהליך ייצא עם חריגה בזרם " " , וגם ידפיס את שם המחלקה ואת השם המתאים . פתרון מהיר לתיקון בעיה זו הוא להעתיק ולהגדיר אותה כקבוע סוג בכיתה שלך. במאמר זה, נלמד מדוע עלינו להשתמש ב-Java וכיצד להשתמש בכלי JDK של Serialver כדי ליצור מזהה זה. אם אתה חדש בתחום הסדרות, אתה יכול גם לצפות ב-10 שאלות הראיון המובילות ב-Java Serialization כדי להעריך את הידע שלך ולמצוא פערים בהבנתך לקריאה נוספת. כמו (במקביל) ו (ריבוי פתילים), (סידרה) הוא נושא נוסף שראוי לקרוא אותו מספר פעמים. CustomerSerialVersionUIDSerialVersionUIDSerializablejava.io.SerializableSerialVersionUIDSerialVersionUIDInvalidClassExceptionmainjava.io.InvalidClassExceptionSerialVersionUIDSerialVersionUIDprivate static final longSerialVersionUIDConcurrencyMulti-threadingSerialization

למה להשתמש ב-SerialVersionUID ב-Java

כפי שאמרתי, כאשר לא הגדרנו ערך SerialVersionUIDכמו static final longבכיתה שלנו, מנגנון ההמשכה יעשה זאת עבורנו. מנגנון זה רגיש לפרטים רבים, כולל השדות של המחלקה שלך, משנות הגישה שלהם, הממשקים שהוא מיישם, ואפילו יישומי מהדר שונים; כל שינוי במחלקה או שימוש במהדר אחר עשויים להניב תוצאה שונה, SerialVersionUIDשבסופו של דבר תביא לתוצאה שונה. לעצור את הטעינה מחדש של הנתונים בסידרה. זה מסוכן להסתמך על מנגנון ההמשכה של Java כדי ליצור את המזהה הזה, וזו הסיבה שמומלץ להגדיר אותו במפורש במחלקה ה-SerializableSerialVersionUID שלך . אני ממליץ בחום לקרוא את ה-Java Classic - Joshua Bloch "Effective Java" כדי להבין את הסדרת Java ואת הבעיות של טיפול לא נכון. אגב, ה-JDK מספק גם כלי , הממוקם בספריית bin של ספריית JAVA_HOME , במחשב שלי, C:\Program Files\Java\jdk1.6.0_26\bin\serialver.exe , שניתן להשתמש בו כדי ליצור לכיתות ישנות. זה מאוד שימושי למקרה שביצעת שינויים בכיתה שלך שמפרת את ההסדרה והאפליקציה שלך לא מסוגלת לטעון מחדש מופעים בסידרה. אתה יכול בקלות להשתמש בכלי השירות הזה כדי ליצור מופעים ישנים, ולאחר מכן להשתמש בו באופן מפורש על ידי הכרזה על השדה כ- private static final long . אגב, מומלץ מאוד מטעמי ביצועים ואבטחה להשתמש בפורמט הבינארי הרגיל לצורך סידרה; שוב, ל-"Java יעיל" יש כמה פסקאות המדגימות את היתרונות של הפורמט הרגיל בפירוט רב. serialverSerialVersionUIDSerialVersionUID SerialVersionUID

כיצד להשתמש בכלי השירות Serialver JDK כדי ליצור SerialVersionUID

אתה יכול להשתמש serialverכדי ליצור SerialVersionUIDעבור שיעורים. זה שימושי במיוחד לפיתוח מחלקות; כלי השירות חוזר SerialVersionUIDבפורמט קל להעתקה. אתה יכול להשתמש serialverבכלי השירות JDK כפי שמוצג בדוגמה:

$ serialver
use: serialver [-classpath classpath] [-show] [classname...]
$ serialver -classpath . Hello
Class Hello is not Serializable.
$ serialver -classpath . Hello
Hello: static final long SerialVersionUID = -4862926644813433707L;

אתה יכול גם להשתמש בכלי השירות serialverכפקודה , זה יפתח מפקח שלוקח את שם GUIהכיתה המלא ומציג אותו . $ serialver –showserial versionSerial version

סיכום

עכשיו אנחנו יודעים מה זה SerialVersionUIDולמה חשוב להכריז על זה ב-- Serializableclass, הגיע הזמן לסקור כמה עובדות חשובות הקשורות ל-Java SerialVersionUID.

1. SerialVersionUIDמשמש לציון הגרסה של הנתונים בסידרה.


2. כאשר אנחנו לא מצהירים SerialVersionUIDבמחלקה שלנו, זמן הריצה של Java עושה את זה עבורנו, אבל תהליך זה רגיש למטא נתונים רבים של המחלקה כולל מספר השדות, סוג השדות, מתקני גישה לשדה, ממשקים שמיושמים במחלקה , וכו' אתה יכול למצוא את המידע המדויק בתיעוד הסדרת מאורקל.


3. מומלץ להכריז על SerialVersionUID כמשתנה סופי ארוך סטטי פרטי כדי להימנע ממנגנון ברירת המחדל. חלק מה-IDEs, כגון Eclipse , מוציאים גם אזהרות אם שוכחים זאת, לדוגמה: "המחלקה ה-Serializable Customer לא מצהירה על שדה סטטי סופי SerialVersionUID מסוג ארוך." . למרות שאתה יכול לבטל אזהרה זו על ידי מעבר אל חלון > העדפות > Java > מהדר > שגיאות/אזהרות > בעיות תכנות אפשריות, אני מציע לא לעשות זאת. רק כאשר לא נדרש שחזור נתונים, אני יכול להיות לא זהיר לגבי זה. כך נראית השגיאה הזו ב-Eclipse IDE, כל מה שאתה צריך לעשות הוא לקבל את ההחלטה המהירה הראשונה.


4. אתה יכול גם להשתמש בכלי השירות serialver מה-JDK כדי ליצור גרסה סדרתית עבור מחלקות ב-Java. לכלי השירות יש גם GUI, המופעל בעת העברת הפרמטר - show.


5. השיטה הטובה ביותר בסריאליזציה היא להצהיר במפורש SerialVersionUID, כדי למנוע בעיות כלשהן עם דה-סריאליזציה, במיוחד אם אתה עובד עם יישום שרת-לקוח המסתמך על נתונים מסודרים, כגון RMI.

הכל קשור SerialVersionUIDבג'אווה. עכשיו אנחנו יודעים למה חשוב להצהיר נכון SerialVersionUIDבכיתה. אתה יכול להודות ל-IDE שלך על התזכורת הזו, שעלולה לשבור את הדה-סיריאליזציה של הכיתה שלך. אם אתה רוצה לקרוא עוד על סדרה ומושגים קשורים, אתה יכול גם לבדוק את המאמרים המדהימים האלה.

• ההבדל בין משתנה חולף למשתנה נדיף ב-Java
• ההבדל בין ממשק שניתן להבדיל ולהחצנה ב-Java
• מתי להשתמש במשתנה חולף ב-Java

מקורי כאן