How to capture thread dump

Option 1:
Since JDK 5, jstack tool is shipped in JDK_HOME/bin folder.

jstack -l  <pid> > <file-path>

sudo -u tomcat jstack -l 12345 > /var/tmp/thedump.log
sudo -u tomcat /usr/java/jdk1.8.0_181/bin/jstack -J-d64 -l 12308 >>/var/tmp/thedump.log

Option 2:
Since JDK 7, The jcmd tool was introduced for troubleshooting issues with JVM applications. It has various capabilities such as identifying java process Ids, capturing heap dumps, capturing thread dumps, acquiring garbage collection statistics, etc.

jcmd <pid> Thread.print > <file-path>

jcmd 12345 Thread.print > /var/tmp/thedump.log

Option 3:
If only JREs are installed on production machines, you can use "kill -3" option to capture thread dump.

kill -3 <pid>

The thread dump is sent to the standard error stream. If you are running your application in tomcat, thread dump will be sent into <TOMCAT_HOME>/logs/catalina.out file.

Redirect thread dump to another file?

On Tomcat application server, we usually use kill -3 PID to get thread dump to default STDOUT which is catalina.out under $Tomcat_Home/logs folder. It might be nature to use command kill -3 PID > some.file 2>&1 to try to redirect the thread dump info to some.file than default one. However, it will not work. The reason is kill is just a command to send a signal to a process. You are redirecting the output of the kill command itself rather than the process (what the process does upon receipt of a signal is separate), so the redirect (supposed to kill command itself) has no effect on which file the process (PID) will write to. Given that, if we need redirect thread dump for that process to some other file, we need add redirects to that process when it starts.

Another popular way is to use jstack -F PID to get the whole thread dump forcefully."jstack": A JVM troubleshooting tool that prints stack traces of all running threads of a given JVM process, a Java core file, or remote debug server. It comes with JDK so it is free too. :-)

Here are some explanations about frequently used  linux cmd > /dev/null 2>&1

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR. Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. The default is STDOUT if you don't name or number.

That means file descriptor 0 or fd0 denotes STDIN or standard input and file descriptor 1 or fd1 denotes STDOUT or standard output and file descriptor 2 or fd2 denotes STDERR or standard error.

You can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!

Note: I somehow lost the original link to the post which includes above explanation. I copied here as it is very clear and easy to understand. Thanks the original poster for contribution.