When to choose several processes over threads in Java?

Question

For what reasons would one choose several processes over several threads to implement an application in Java?

I'm refactoring an older java application which is currently divided into several smaller applications (processes) running on the same multi-core machine, communicating which each other via sockets.

I personally think this should be done using threads rather than processes, but what arguments would defend the original design?

Answer 1

I (and others, see attributions below) can think of a couple of reasons:

Historical Reasons

• The design is from the days when only green threads were available and the original author/designer figured they wouldn't work for him.

Robustness and Fault Tolerance

• You use components which are not thread safe, so you cannot parallelize withough resorting to multiple processes.

• Some components are buggy and you don't want them to be able to affect more than one process. Say, if a component has a memory or resource leak which eventually could force a process restart, then only the process using the component is affected.

• Correct multithreading is still hard to do. Depending on your design harder than multiprocessing. The later, however, is arguably also not too easy.

• You can have a model where you have a watchdog process that can actively monitor (and eventually restart) crashed worker processes. This may also include suspend/resume of processes, which is not safe with threads (thanks to @Jayan for pointing out).

OS Resource Limits & Governance

• If the process, using a single thread, is already using all of the available address space (e.g. for 32bit apps on Windows 2GB), you might need to distribute work amongst processes.

• Limiting the use of resources (CPU, memory, etc.) is typically only possible on a per process basis (for example on Windows you could create "job" objects, which require a separate process).

Security Considerations

• You can run different processes using different accounts (i.e. "users"), thus providing better isolation between them.

Compatibility Issues

• Support multiple/different Java versions: Using differnt processes you can use different Java versions for your application parts (if required by 3rd party libraries).

Location Transparency

• You could (potentially) distribute your application over multiple physical machines, thus further increasing scalability and/or robustness of the application (see @Qwe's answer for more Details / the original idea).