问题
I'm writing a simple memory reporting utility (in this particular situation using an existing tool is not an option). I've got it to print the max, commit and usage for all the memory pools returned by iterating ManagementFactory.getMemoryPoolMXBeans(). That gets me the three heap generations of heap memory (eden, survivor and old), the permgen, and the "code cache".
None of these appear to be the method stack memory. The closest thing seems be the "code cache", but I've read that that's actually where the hotspotter puts compiled classes.
I ask because I'm trying to track down the cause of a crash in a JBoss webapp that's failing to create a new thread. http://www.mastertheboss.com/jboss-server/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native-thread suggests that this could be due to running out of stack memory, which stands to reason. The question is: how do I get the stack memory, so I can check?
回答1:
On Linux you can parse /proc/self/maps (or /proc/self/smaps for more details).
Look for the lines ending with [stack:NNN] and calculate the stack size as top - bottom:
7f8a5c0e1000-7f8a5c1df000 rw-p 00000000 00:00 0 [stack:2669]
^ bottom ^ top ^ tid
On Windows this would be harder, but you can estimate the memory used by stacks as
number_of_threads * default_stack_size
来源：https://stackoverflow.com/questions/26835087/how-do-i-get-stack-memory-stats-programatically