CODEWITHSUNDEEP
javamultithreading
ali haider
ali haider

Reputation: 20242

impact of threads in wait state on memory in java process

I am trying to ascertain the best possible approach of figuring out the impact of threads in wait state on a java process (more specifically memory and not cpu). Any suggestions that would help me figure out their impact (possibly via jvisualvm/jconsole etc) will be greatly appreciated.

Update: Current thread count is a few hundred in wait state - approx 500. I am trying to figure out the best way of checking whether it can/will have any potential impact on GC in old generation.

Upvotes: 2

Views: 2381

Answers (2)

Gray
Gray

Reputation: 116918

I am trying to ascertain the best possible approach of figuring out the impact of threads in wait state on a java process (more specifically memory and not cpu)

The affect of a single thread is going to be extremely minimal. Each thread gets allocated a certain amount of stack-space memory that is allocated outside of the heap. I believe typically this is 512k or 1M for 64-bit machines. This can be customized with the -XX:ThreadStackSize=YYY JVM argument where YYY is the size of the stack in kilobytes.

There also is the Thread object itself on the heap as well as the various accounting data kept by the JVM. Certainly any objects that the thread owns also need to be taken into account.

The only time you worry about this space is if you plan on having 1000s of threads or have very limited memory constraints.

Upvotes: 2

Durandal
Durandal

Reputation: 20069

The memory usage for a thread can be conceptually divided into:

  • The threads stack (defaults to 2MB I believe, but can be changed using the -Xss VM option and/or specified in the Thread constructor)

  • The java thread object and associated objects (located in the VM heap). Practically constant for a given implementation. Only be a few KB.

  • Native overhead - the kernel memory required to manage the thread. Should be neglible (a few KB).

  • User data managed by the thread (data reachable through its thread object or local variables). Can vary greatly.

The first three elements are easy to measure (they are practically constant with a VM instance, scaling linearly with number of threads), the last thing depends completely on the threads code/data.

Since the stack size usually grealy dominates the per thread cost (compared to the kernel overhead and thread object), the memory impact for a waiting thread can be simplified to its stack size.

For virtual mememory systems thats only the virtual impact (address space allocated), but not neccessarily the amount of physical memory assigned (unused stack space will never be assigned physical memory pages). 32-Bit systems can run out of address space very quickly when you create many threads (example: 1000 threads times 2MB stack size = 2GB).

Upvotes: 3

Related Questions