4 如何通过JDK命令，分析排查死锁、死循环？
top 命令：显示当前的活动进程，默认它是按消耗 CPU 的厉害程度进行排序，每5秒钟刷新一次列表，你也可以选择不同的排序方式，例如 m 是按内存占用方式进行排序的快捷键。
命令：top -Hp pid
可以实时的跟踪并获取指定进程中最耗cpu的线程。再用 jstack方法提取到对应的线程堆栈信息。
jps 命令：
jps用来查看JVM里面所有进程的具体状态, 包括进程ID，进程启动的路径等等。
jstack 命令：
- 查看java程序崩溃生成core文件，获得core文件的java stack和native stack的信息；
- 查看正在运行的java程序的java stack和native stack的信息：a) 查看运行的java程序呈现hung的状态；b) 跟踪Java的调用栈，剖析程序。
线程的状态分析：
Runnable：该状态
表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。Wait on condition：该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stacktrace来分析。
最常见的情况是线程在等待网络的读写；另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。Waiting for monitor entry 和 in Object.wait()：在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。
Monitor是Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。
jinfo 命令：
jinfo可观察运行中的java程序的运行环境参数：
参数包括Java System属性和JVM命令行参数；也可从core文件里面知道崩溃的Java应用程序的配置信息。
jstat 命令：
jstat利用了JVM内建的指令
对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控等等。
jmap 命令：
观察运行中的jvm物理内存的占用情况，包括Heap size, Perm size等等。
4.1 Java死循环分析
查看进程ID：
top 或者 jps-
按CPU使用率展示当前JAVA程序的所有线程：
top -Hp 3230
top -Hp 3230
其实这个地方按CPU的使用率来判定还不太好理解，以运行时间来判定可能更能说明问题些。
将运行时间最长的
本地线程ID（3244）转成16进制为0xcac。生成线程堆栈日志文件
jstack -l 3230 > jstack.log；-
打开堆栈日志
搜索“0xcac”：
堆栈日志搜索“0xcac” 很容易的就找到了无限循环的调用线程堆栈。
4.2 Java死锁分析
在多线程程序的编写中，如果不适当的运用同步机制，则有可能造成程序的死锁，经常表现为程序的停顿，或者不再响应用户的请求。 比如在下面这个示例中，是个较为典型的死锁情况：
5 Java中j.u.c包原理实现及CAS算法？
5.1 Java的多线程同步机制
在现代的多处理器系统中，提高程序的并行执行能力是 有效利用 CPU 资源的关键。为了有效协调多线程间的并发访问，必须采用适当的同步机制来协调竞争。当前常用的多线程同步机制可以分为下面三种类型：
volatile 变量：轻量级多线程同步机制，不会引起上下文切换和线程调度。仅提供内存可见性保证，不提供原子性。
CAS 原子指令：轻量级多线程同步机制，不会引起上下文切换和线程调度。它同时提供内存可见性和原子化更新保证。
内部锁和显式锁：重量级多线程同步机制，可能会引起上下文切换和线程调度，它同时提供内存可见性和原子性。
在这里，CAS 指的是现代 CPU 广泛支持的一种对内存中的共享数据进行操作的一种特殊指令。这个指令会对内存中的共享数据做原子的读写操作。简单介绍一下这个指令的操作过程：首先，CPU 会将内存中将要被更改的数据与期望的值做比较。然后，当这两个值相等时，CPU 才会将内存中的数值替换为新的值。否则便不做操作。最后，CPU 会将旧的数值返回。这一系列的操作是原子的。它们虽然看似复杂，但却是 Java 5 并发机制优于原有锁机制的根本。简单来说，CAS 的含义是“我认为原有的值应该是什么，如果是，则将原有的值更新为新值，否则不做修改，并告诉我原来的值是多少”。
在轻度到中度的争用情况下，非阻塞算法的性能会超越阻塞算法，因为 CAS 的多数时间都在第一次尝试时就成功，而发生争用时的开销也不涉及线程挂起和上下文切换，只多了几个循环迭代。没有争用的 CAS 要比没有争用的锁便宜得多（这句话肯定是真的，因为没有争用的锁涉及 CAS 加上额外的处理），而争用的 CAS 比争用的锁获取涉及更短的延迟。
5.2 Java中j.u.c包原理实现
Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此 任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。同时，volatile变量的读/写和CAS可以实现线程之间的通信。把这些特性整合在一起，就形成了整个concurrent包得以实现的基石。如果我们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：
- 首先，声明共享变量为volatile；
- 然后，使用CAS的原子条件更新来实现线程之间的同步；
- 同时，配合以volatile的读/写和CAS所具有的volatile读和写的内存语义来实现线程之间的通信。
AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent包的实现示意图如下：
6 有锁与无锁的本质区别？
有锁、无锁的本质都是在解决并发情况下竞态资源的线程安全问题。无锁只是把“排他性”进一步的弱化，以提高并发量，最大限度的使用CPU。
无锁只会在CPU控制权切换的等待，而有锁会在“锁释放”、“CPU控制权切换”两种情况下的等待。
最终无锁情况下，CPU使用率上不去，吞吐量下降，就受系统资源限制了。即使线程量增加，无非增加的是线程CPU控制权的切换成本，统一受CPU的控制调度，出现的也只能是等待了。
7 volatile关键字是否是线程安全的？
volatile关键字仅保证两点：
- volatile变量线程之间可见性；
- 禁止针对volatile变量操作指令重排序；
但最重要一点没有保证，关系到线程安全，就是Volatile变量操作指令的不保证原子性问题。
什么是原子操作：
多个线程执行一个操作时，其中任何一个线程要么完全执行完此操作的步骤，要么就没有执行此操作的任何步骤，那么认为这个操作才是原子的。
关于指令重排序的问题，在单线程中，重排序的前后只要不影响JVM执行结果，JVM可以运行指令重排序。
指令重排序的意义在于：
JVM能够根据处理器特性（CPU多级缓存系统、多核处理器等）适当的重新排序机器指令，使机器指令更符合CPU的执行特点，最大限度的发挥机器性能。
但是 在指令重排序在多线程的情况下，重排序的前后结果，可能不会一致了。这里导致结果不一致主要是线程安全的问题，即使指令不重排序，也会存在线程安全问题。这也就是原子性问题、或者没有加锁的问题；
