If you are using Enterprise Java Beans (EJBs), and have a Stateless Session Bean API, then each SSB instance runs in one thread on one Java Virtual Machine, and its clients run in different threads, and, in general, in different JVMs on different computers. Because you can't pass a reference to a Java object from one JVM to another, the object needs to be serialized into a string, sent over to the other JVM, and then deserialized back into an object. This serialization/deserialization happens to both the arguments coming in and the return value going out.
If you're using the Java Message Service, the objects you send in each message get serialized into a string, persisted into a database, and then get deserialized by the message receiver at some other time and place.
And, as Will Hartung points out, HTTP Session objects in general are shared across JVMs. If you have a cluster of Glassfish Java EE application servers running an ecommerce application, each customer's requests are load-balanced to any available server, and that server must be able to look up the customer's session state (customer name, shopping cart, etc.). It can only get this via serialization. Session state may also be written to disk (eg, a database) for safety.