Monitors Java Virtual Machine (JVM) statistics. This command is experimental and unsupported.

jstat [ generalOption | outputOptions vmid [ interval[s|ms] [ count ] ]
//vmid: protocol:lvmid[@hostname[:port]/servername]

refer: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/jstat.html

$_ jstat -help
$_ jstat -options

-class
-compiler
-gc
-gccapacity
-gccause
-gcnew
-gcnewcapacity
-gcold
-gcoldcapacity
-gcpermcapacity
-gcutil
-printcompilation

$_ ./jstat -printcompilation  -t 18128 1s
$_ ./jstat -printcompilation  -t 18128 1s 2
$_ ./jstat -gc -t 18128 1s 2

Timestamp S0C S1C S0U S1U EC EU OC
OU PC PU YGC YGCT FGC FGCT GCT

     3346.4 571392.0 607744.0 340114.4 384.0  1505280.0 1505280.0 5460992.0  1679695.0  66560.0 61799.4   2463  493.065  59    220.141  713.206
     3347.4 585216.0 607744.0  0.0   384.0  1505280.0 302819.9 5460992.0  1933919.0  66560.0 61799.4   2463  493.496  59    220.141  713.637

The jcmd utility is used to send diagnostic command requests to the JVM, where these requests are useful for controlling Java Flight Recordings, troubleshoot, and diagnose JVM and Java Applications. It must be used on the same machine where the JVM is running, and have the same effective user and group identifiers that were used to launch the JVM.
 Sample
 jcmd
 jcmd PerfCounter.print
 jcmd 2125 help //2125 is the pid
 jcmd 2125 GC.heap_dump filename=Myheapdump
 jcmd 2125 VM.uptime
 jcmd VM.system_properties
 jcmd VM.flags
 jcmd MyProgram help Thread.print
 jcmd Thread.print
 jcmd [options]
 jcmd 7060 JFR.start name=MyRecording settings=profile delay=20s duration=2m filename=C:\TEMP\myrecording.jfr
 jcmd 7060 JFR.check
 jcmd 7060 JFR.stop
More:

jcmd man page: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/jcmd.html
Useful Commands for jcmd Utility: https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html#BABEJDGE 
Troubleshoot with jcmd Utility: https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html#BABFFIFA

core dump：A core dump or a crash dump is a memory snapshot of a running process.

如何获得：

1. A core dump can be automatically created by the operating system
   when a fatal or unhandled error (for example, signal or system
   exception) occurs.
2. or can be forced by means of system-provided command-line utilities.

3. kill -6 on Linux or Solaris systems 将会强制产生一个core 文件，即使程序无响应。

   更多如何获得 参看 [这里][1]
   

IBM JVM(J9) 的javacore 文件和一般进程的core dump 不是一回事。
IBM JVM (J9) java core file: http://www-01.ibm.com/support/docview.wss?uid=swg21393547

linux 文件有一些特殊属性, 可以用lsattr 和 chattr 查看和设置
man 快速链接: lsattr chattr

chattr [ -RVf ] [ -v version ] [ mode ] files...
The format of a symbolic mode is +-=[acdeijstuADST].

The letters 'acdeijstuADST' select the new attributes for the files: append only (a), compressed (c), no dump (d), extent format (e), immutable (i), data journalling (j), secure deletion (s), no tail-merging (t), undeletable (u), no atime updates (A), synchronous directory updates (D), synchronous updates (S), and top of directory hierarchy (T).

The following attributes are read-only, and may be listed by lsattr(1) but not modified by chattr: huge file (h), compression error (E), indexed directory (I), compression raw access (X), and compressed dirty file (Z).

A（atime）：如果设置了A属性，则这个文件的最后访问时间atime不能被修改。
a（append only）：如果设置了a属性，则这个文件只能增加数据，不允许任何进程覆盖或截断这个文件。如果某个目录具有这个属性，那么只能在这个目录下建立和修改文件，而不能删除任何文件。
i（immutable）：如果设置了i属性，则不能对这个文件做任何修该。如果某个目录具有这个属性，那么只能修改该目录下的文件，而不能建立和删除文件。
s（secure deletion）：如果设置了s属性，则这个文件将从硬盘空间中完全删除。
u（undeletable）：与s完全相反。如果设置了u属性，则这个文件虽然被删除了，但是还在硬盘空间中存在，还可以用来还原恢复。

参考

PKI: public key infrastructure.
OSI: Open System Interconnection.

现实中的协议并非总能与OSI模型完全对应。比如SPDY和HTTP/2因为要对连接进行管理，所以被归入会话层协议，但它们却在数据加密以后生效。第五层及更高层的划分经常是模糊的。

协议历史
SSL协议由Netscape公司开发，历史可以追溯到Netscape Navigator浏览器统治互联网的时代①。协议的第一个版本从未发布过，第二版则于1994年11月发布。第一次部署是在NetscapeNavigator 1.1浏览器上，发行于1995年3月。

SSL 2的开发基本上没有与Netscape以外的安全专家进行过商讨，所以有严重的弱点，被认为是失败的协议，最终退出了历史的舞台。这次失败使Netscape专注于SSL 3，并于1995年年底发布。虽然名称与早先的协议版本相同，但SSL 3是完全重新设计的协议。该设计一直沿用到今天。1996年5月，TLS工作组②成立，开始将SSL从Netscape迁移至IETF。由于Microsoft和Netscape当时正在为Web的统治权争得不可开交，整个迁移过程进行得非常缓慢、艰难。最终，TLS 1.0于1999年1月问世，见RFC 2246。尽管与SSL 3相比，版本修改并不大，但是为了取悦Microsoft，协议还是进行了更名③。

直到2006年4月，下一个版本TLS 1.1才问世，仅仅修复了一些关键的安全问题。然而，协议的重要更改是作为TLS扩展于2003年6月发布的，并被集成到了协议中，这比大家的预期早了好几年。

2008年8月，TLS 1.2发布。该版本添加了对已验证加密的支持，并且基本上删除了协议说明中所有硬编码的安全基元，使协议完全弹性化。协议的下一个版本正在开发过程中。该版本预计会成为一个主要版本，其目标是简化设计，除去安全性较弱或者不太需要的功能，并且提升性能。各位读者可以关注TLS工作组邮件列表的讨论④。

部署正确的密码能解决安全的三个核心需求：保持秘密（机密性）、验证身份（真实性），以及保证传输安全（完整性）。