Back to Serialization & transient
Q9Question 9 of 11

If a variable is static, does it participate in serialization?

Key Concepts
  • No – static fields belong to the CLASS, not to any object, so they are not serialized
  • During deserialization, the static field has whatever value the class currently has, not the value at serialization time
  • This can cause confusion: a static field might appear to be "restored" if the class has not been reloaded
  • Understanding this concept is essential for Java interviews at senior level
  • This concept directly affects how banking applications manage resources

Definition

No. Static fields belong to the class, not the object. Serialization saves only instance state. On deserialization, static fields have the class's current value.

Static and serialization:

  • Not serialized. Static fields are not part of the object's state.
  • On deserialization: The static field has whatever value the class currently holds in the JVM, not the value at serialization time.
  • Seems to restore in the same JVM because the class was not reloaded. But across JVMs or after restart, the static value is the class default.

Serializing an account does not save the bank's interest rate (static). It saves only the account's balance and ID. When you restore the account in another branch, the interest rate is whatever that branch currently uses.

Understanding the Concepts

Demonstration

JAVA
public class Account implements Serializable {
    private static final long serialVersionUID = 1L;
    private String accountId;
    private static int instanceCount = 0;  // static: NOT serialized

    public Account(String id) {
        this.accountId = id;
        instanceCount++;
    }
}

// Before serialization: instanceCount = 5
// Serialize account
// After deserialization in a new JVM: instanceCount = 0 (class default)
// The static field was not saved with the object

What are common mistakes?

A common mistake is forgetting to declare serialVersionUID, which causes deserialization failures when the class changes.

Wrong approach:

JAVA
package com.bank.model;

import java.io.Serializable;

// WRONG: no serialVersionUID
public class Account implements Serializable {
    private String accountId;
    private java.math.BigDecimal balance;
}
// If you add a field later, old serialized data cannot be read

Correct approach:

JAVA
package com.bank.model;

import java.io.Serializable;
import java.math.BigDecimal;

// CORRECT: explicit serialVersionUID
public class Account implements Serializable {
    private static final long serialVersionUID = 1L;
    private String accountId;
    private BigDecimal balance;
}
// Adding new fields with defaults still allows reading old data

Another mistake is serializing sensitive fields like passwords or PINs. Always mark them transient to exclude them from the byte stream.

What should a senior engineer know?

A senior engineer should understand that Java serialization has well-known security vulnerabilities and should be avoided for external communication.

  • Deserialization attacks. Untrusted byte streams can execute arbitrary code. Use ObjectInputFilter (Java 9+) to whitelist allowed classes.
  • Alternative formats. Use JSON (Jackson/Gson) or Protocol Buffers for API communication in banking systems.
  • Serialization proxy pattern. Described in Effective Java, this pattern defends against invalid deserialized states.
  • Record serialization (Java 16+). Records use a canonical constructor for deserialization, which is inherently safer.
JAVA
package com.bank.model;

import java.io.*;

public class AccountSerializationFilter {
    public static void main(String[] args) {
        // Java 9+: restrict deserialization to safe classes
        ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
            "com.bank.model.*;!*"
        );
        // Apply to ObjectInputStream
    }
}

What are the edge cases?

Edge cases can cause unexpected behavior in banking applications. Here are some to watch for.

JAVA
package com.bank.edge;

public class EdgeCaseDemo {
    public static void main(String[] args) {
        // Edge case 1: null handling
        String accountId = null;
        try {
            System.out.println(accountId.length());
        } catch (NullPointerException e) {
            System.out.println("Null account ID");
        }

        // Edge case 2: empty vs null
        String emptyId = "";
        System.out.println(emptyId.isEmpty());  // true
        System.out.println(emptyId == null);     // false

        // Edge case 3: boundary values
        java.math.BigDecimal zero = java.math.BigDecimal.ZERO;
        java.math.BigDecimal negativeBalance = new java.math.BigDecimal("-0.01");
        System.out.println(zero.compareTo(negativeBalance) > 0);  // true
    }
}
TEXT
Null account ID
true
false
true

Always test with null values, empty strings, boundary values, and negative amounts in banking applications.

What are common interview follow-up questions?

Interviewers often follow up with these related questions:

  • How does this concept apply to a high-throughput banking transaction system?
  • What are the performance implications in a production environment?
  • How would you debug issues related to this concept?
  • What tools would you use to monitor this in production?
  • How does this behave differently in Java 8 vs Java 17+?

When answering follow-up questions, always relate your answer back to practical experience. For example, at National Bank of India, Rajesh debugged a production issue related to this concept by using JFR recordings and heap dumps. Providing concrete examples from banking systems shows the interviewer that you understand both the theory and the practice.

Visual Overview

DIAGRAM
  Serialized:     instanceCount (static) → NOT included
  Deserialized:   instanceCount → current class value (not the old value)
  Same JVM:       appears to be "restored" (class not reloaded)
  New JVM:        resets to default (class freshly loaded)

Key Takeaway

Static fields are not serialized because they belong to the class, not the object. On deserialization, static fields have the class's current value, not the value at serialization time.

One sentence to remember: static fields belong to the class, not the object – serialization saves only instance state.

---

Share
Use ← → arrow keys to navigate