Increasing stack space of a single worker-thread i

问题:

In my java web application, I have a single background-worker thread, which requires a lot of stack space, because it runs a really complex workflow using the activiti workflow engine and groovy script tasks.

Currently I need to set the JVM Xss setting as high as 16MB on a 64bit Java and Tomcat, to circumvent any StackOverflowErrors. If the error occurs the stack trace is really huge (several hundred lines long) but it all happens inside the engine, so I can't really do anything about it.

Now my question is: is there a way to increase the stack size of a single thread at runtime?

I'd like to lower the JVMs default Xss settings for all threads in the application to 512k, which I know is enough and only run the worker with 16M.

The Java API provides some information on this topic for a constructor of the Thread class:

public Thread(ThreadGroup group,
              Runnable target,
              String name,
              long stackSize)

but it mentions, that the behaviour is not guaranteed ([1]) and I didn't find any information, if it would work on windows.

Also, if the stack space of one thread cannot be increased and I have to specify 16MB as default value, what would be the consequences of having such a high setting? Would that mean that every new thread would reserve 16MB of memory upon initialization (i.e. 200 threads * 16MB: 3,2 GB)?

As far as I can tell from jconsole and taskmgr, the memory footprint doesn't seem to have changed much since the increase of the Xss settings, but maybe I'm missing something.

Any help or clarification would be appreciated.

[1]: http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#Thread(java.lang.ThreadGroup, java.lang.Runnable, java.lang.String, long)

回答1:

Its worth nothing that -Xss on HotSpot specifies the maximum size, not the size it will use. The size used is based on usage so if you specify this unreasonably large it will waste virtual memory (which can be a problem on a 32-bit JVM) but it won't waste physical memory. If you have a 64-bit JVM, there is little disadvantage in making the largest you want any thread to be.

Also, if the stack space of one thread cannot be increased and I have to specify 16MB as default value, what would be the consequences of having such a high setting? Would that mean that every new thread would reserve 16MB of memory upon initialization (i.e. 200 threads * 16MB: 3,2 GB)?

Each thread will use this much virtual memory. On a 32-bit JVM, you will run out of address space even if you actually use very little memory. On a 64-bit JVM, your limits is in the TB and only the stack actually used will use main memory.

回答2:

If the concerned thread is very process intensive. Implement this Thread's logic as another application and pass information and process variables using queues. You can increase the memory parameters of this application according to need.

From the Docs Link:

The virtual machine is free to treat the stackSize parameter as a suggestion. If the specified value is unreasonably low for the platform, the virtual machine may instead use some platform-specific minimum value; if the specified value is unreasonably high, the virtual machine may instead use some platform-specific maximum. Likewise, the virtual machine is free to round the specified value up or down as it sees fit (or to ignore it completely).