简体   繁体   中英

reading/writing a set to a .ser file compared to a .txt file in java

So I have this Java program, and at the moment it serializes my set object and saves it to a .ser file

 FileOutputStream fileOut = new FileOutputStream("hash.ser");
          ObjectOutputStream out = new ObjectOutputStream(fileOut);
          out.writeObject(mySet);
          out.close();
          fileOut.close();
          System.out.printf("Serialized data is saved in hash.ser");

The program also reads from the .ser file at start of program each time. I was just curious if someone can explain the differences in both speed, and how it works in general between reading/loading from a txt file compared to a .ser file. As I am not 100% sure it is actually faster to read/write to the .ser file like I did. Looked into this a bit and really couldnt find to much on this. Any help would be great, thanks.

It's impossible to compare Java serialization to a "txt" file because the text file could be created and read in any number of different ways. For example, you could write XML, or JSON, or your own custom text format to a text file. These are all quite different and will potentially vary considerably in their performance and other characteristics.

Java serialization can be convenient under many circumstances, but there are also a lot of restrictions and other considerations that can make things complicated quite quickly.

  • To use serialization successfully, everything you serialize, and everything it points to, must be serializable. Primitives, strings, and core collections ( ArrayList , HashSet , etc.) are all serializable. If you include something that isn't serializable, you have to declare it transient and deal with its absence upon deserialization, or you have to create a custom serialization format. This adds complexity.
  • Serialization preserves the object graph. Suppose your set contains obj1 and obj2 , each of which has a reference to the same object obj3 . Serializing and deserializing this structure will preserve this relationship, so afterwards both obj1 and obj2 will point to the same obj3 instance. Other serialization mechanisms might not do this, and you'd end up with some object pointing to a copy of obj3 .
  • Serialization can be brittle. Unless deserialization is done on a system with the exact same classes that were used for serialization, you'll get serialization compatibility exceptions. The way to prevent this is to declare serialVersionUID in all of your classes, but then you might have to deal with evolution of this class, for example, if serialized fields are added or removed. Again, this adds complexity.

As for performance, I'd suggest that you try it out and see whether it performs acceptably. It might be faster or slower than alternatives, but you'd really have to implement those alternatives and benchmark them and compare the results to Java serialization.

I assume you are asking the difference between serialization and File IO to write the object state to the file.

The primary use of Serialization is to send the object state over network to the other VM as in RMI. Writing object state to file using serialization is used rarely in production code.

If you are using File IO to write the object state to file , you have to manually take care of writing all the fields to the file including the transient fields .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM