亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: java中的transient(轉(zhuǎn)載) [打印本頁(yè)]

作者: sample0    時(shí)間: 2007-09-12 09:27
標(biāo)題: java中的transient(轉(zhuǎn)載)
Java中的transient
    改bug,發(fā)現(xiàn)一個(gè)保留字transient。很奇怪,從來(lái)沒(méi)見(jiàn)過(guò),也從來(lái)沒(méi)用過(guò)。
    用google查了一把,大概意思是:Java語(yǔ)言的關(guān)鍵字,用來(lái)表示一個(gè)域不是該對(duì)象串行化的一部分。當(dāng)一個(gè)對(duì)象被串行化的時(shí)候,transient型變量的值不包括在串行化的表示中,然而非transient型的變量是被包括進(jìn)去的。還是不大明白。
    后來(lái),終于搜到這篇文章,寫得很詳細(xì)。
Be Careful With Transient Data
    怕萬(wàn)一這篇文章鏈接失效,收藏起來(lái)。
Be Careful With Transient Data
   
    終于明白了。
    當(dāng)串行化某個(gè)對(duì)象時(shí),如果該對(duì)象的某個(gè)變量是transient,那么這個(gè)變量不會(huì)被串行化進(jìn)去。也就是說(shuō),假設(shè)某個(gè)類的成員變量是transient,那么當(dāng)通過(guò)ObjectOutputStream把這個(gè)類的某個(gè)實(shí)例保存到磁盤上時(shí),實(shí)際上transient變量的值是不會(huì)保存的。因?yàn)楫?dāng)從磁盤中讀出這個(gè)對(duì)象的時(shí)候,對(duì)象的該變量會(huì)沒(méi)有被賦值。
    另外這篇文章還提到,當(dāng)從磁盤中讀出某個(gè)類的實(shí)例時(shí),實(shí)際上并不會(huì)執(zhí)行這個(gè)類的構(gòu)造函數(shù),而是讀取這個(gè)類的實(shí)例的狀態(tài),并且把這個(gè)狀態(tài)付給這個(gè)類的對(duì)象。這點(diǎn)我以前似乎不知道。
Trackback:
http://tb.blog.csdn.net/TrackBack.aspx?PostId=1064847


Be Careful With Transient Data

(原文來(lái)自
http://www.devx.com/tips/Tip/13726
)
Expertise: Intermediate
Language: Java
January 28, 2000
Be Careful With Transient Data
Java's serialization provides an elegant, and easy to use mechanism for making an object's state persistent. While controlling object serialization, we might have a particular object data member that we do not want the serialization mechanism to save.
To turn off serialization on a certain field of an object, we tag that field of the class of our object with the Java's "transient" keyword. This, to low-level parts of the Java virtual machine, is an indication that the transient variable is not part of the persistent state of an object.
First, let's have some backgrounder code with Java's serialization.
Suppose we define a class as:

public class LoggingInfo implements java.io.Serializable
{
    private Date loggingDate = new Date();
    private String uid;
    private transient String pwd;
   
    LoggingInfo(String user, String password)
    {
        uid = user;
        pwd = password;
    }
    public String toString()
    {
        String password=null;
        if(pwd == null)
        {
        password = "NOT SET";
        }
        else
        {
            password = pwd;
        }
        return "logon info: \n   " + "user: " + uid +
            "\n   logging date : " + loggingDate.toString() +
            "\n   password: " + password;
    }
}
Now we can create an instance of this class and serialize it, and write the serialized object to disk as in:
LoggingInfo logInfo = new LoggingInfo("MIKE", "MECHANICS");
System.out.println(logInfo.toString());
try
{
   ObjectOutputStream o = new ObjectOutputStream(
                new FileOutputStream("logInfo.out"));
   o.writeObject(logInfo);
   o.close();
}
catch(Exception e) {//deal with exception}
To read the object back, we can write
try
{
   ObjectInputStream in =new ObjectInputStream(
                new FileInputStream("logInfo.out"));
   LoggingInfo logInfo = (LoggingInfo)in.readObject();
   System.out.println(logInfo.toString());
}
catch(Exception e) {//deal with exception}
If we run this code, we notice that the read-back object prints password as "NOT SET". This is exactly the effect we should have expected when we declared the pwd field as transient.
Now, let's see a potential problem that careless treatment of transient fields may cause. Suppose we modify our class definition and provide default values for the transient field, say we write:

public class GuestLoggingInfo implements java.io.Serializable
{
    private Date loggingDate = new Date();
    private String uid;
    private transient String pwd;
   
    GuestLoggingInfo()
    {
        uid = "guest";
        pwd = "guest";
    }
    public String toString()
    {
        //same as above
     }
}
Now, if we serialize an instance of GuestLoggingInfo, write it to disk, and read it back, we still see that the read-back object prints password as "NOT SET". In effect, the process of reading back (de-serializing) totally ignores the constructor of GuestLoggingInfo. So what happened?
The answer lies in the fact that the initialization code is not called because we are not initializing, in other words, we are not constructing a brand new object, but loading back the persistent state of an object of a class, and assigning that state to another object of the same class. Declaring the pwd field as transient, excludes the data for that field from the persistent state of our object. Then, upon de-serialization, since there is no data preserved for the pwd field, the field gets Java's default value for its type (null for String).
So, if you mark a field of an object as transient, and write that object to disk, expect to have the default value of the type of that field when you de-serialize the object, and not the actual value that the field had before its state was serialized. If a default value (or any meaningful value) is essential for a transient field of a de-serialized object, you have to assign it yourself either directly (if the field is public) or via a setter method.
Behrouz Fallahi
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1064817


本文來(lái)自ChinaUnix博客,如果查看原文請(qǐng)點(diǎn):http://blog.chinaunix.net/u/22516/showart_380029.html




歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2