Fields are variables on the class level. They represent the state of an object. They are variables, with defined type and possible initial value. Fields can be static, final, transient, and volatile, and the access may be modified with the public, protected, and private keywords.
Static fields belong to the class. It means that there is one of them shared by all the instances of the class. Normal, non-static fields belong to the objects. If you have a field named f, then each instance of the class has its own f. If f is declared static, then the instances will share the very same f field.
The final fields cannot be modified after they are initialized. Initialization can be done on the line where they are declared, in an initializer block or in the constructor code. The strict requirement is that the initialization has to happen before the constructor returns. This way, the meaning of the final keyword is very different, in this case, from what it means in the case of a class or a method. A final class cannot be extended and a final method cannot be overridden in an extending class, as we will see in the next chapter. The final fields are either uninitialized or get a value during instance creation. The compiler also checks that the code does initialize all final fields during the object-instance creation or during the class loading, in case the final field is static, and that the code is not accessing/reading any final field that was not yet initialized.
The transient fields are not part of the serialized state of the object. Serialization is an act of converting the actual value of an object to physical bytes. Deserialization is the opposite when the object is created from the bytes. It is used to save the state in some frameworks. The code that does the serialization, java.lang.io.ObjectOutputStream, works only with classes that implement the Serializable interface, and uses only the fields from those objects that are not transient. Very obviously, transient fields are also not restored from the bytes that represent the serialized form of the object because their value is not there.
Serialization is usually used in distributed programs. A good example is the session object of a servlet. When the servlet container runs on a clustered node, some fields of objects stored into the session object may magically disappear between HTTP hits. That is because serialization saves and reloads the session to move the session between the nodes. Serialization, in such a situation, may also be a performance issue if a developer does not know the side effects of the stored large objects in the session.
The volatile keyword is a keyword that tells the compiler that the field may be used by different threads. When a volatile field is accessed by any code, the JIT compiler generates code which ensures that the value of the field accessed is up to date. When a field is not volatile, the compiler-generated code may store the value of the field in a processor cache or registry for faster access when it sees that the value will be needed soon by some subsequent code fragment. In the case of volatile fields, this optimization cannot be done. Additionally, note that saving the value to memory and loading from there all the time may be 50 or more times slower than accessing a value from a registry or cache.