在 Java5 之前，只有synchronized一种锁，在 Java5 之后，增加了ReentrantLock。ReentrantLock位于 java.util.concurrent.locks 包，和 CountDownLatch、FutureTask、Semaphore 一样基于 AQS 实现，能够实现比synchronized更细粒度的控制，如控制公平性(fairness)。使用ReentrantLock需要注意的是在调用 lock() 方法之后，必须调用 unlock() 释放锁。在 Java6 后经过优化的synchronized性能未必比ReentrantLock低，并且synchronized也是可重入的。

先来说以下已经被抛弃的用于中断线程的方法： - 通过调用stop()方法停止线程 这种方法是不安全的。比如线程 A 调用线程 B 的stop()方法去停止 B 线程，但是 线程 A 是不知道线程 B 的执行情况的，这种突然的停止会导致线程 B 的一些清理工作还没完成就被强制停止了，而且线程 B 会立刻释放所占有的锁，这有可能会引发数据不同步的问题

Java 从诞生之初就提供了完善的异常处理机制，大大降低了编写和维护可靠程序的门槛。Java 的异常处理机制主要回答了 3 个问题：

• What：异常类型回答了什么被抛出
• Where：异常堆栈跟踪回答了在哪里被抛出
• Why：异常信息回答了为什么被抛出

• 直接调用线程的 run 方法，并不会启动一个新的线程，而是在原来的线程里面执行 run() 方法里面的语句，与普通的方法调用没有差别
• 调用线程的 start 方法，是启动一个新的线程去执行 run() 方法里面的代码 如下示例：

在 Java 中，一般都会利用 Executors 创建不同的线程池满足不同场景的需求。

1

Executors.newFixedThreadPool(int nThreads)

指定工作线程数量的线程池，每来一个任务，就创建一个工作线程，如果线程数打到了nThreads，就把任务存放进队列中排队，

1

Executors.newCachedThreadPool()

处理大量短时间工作任务的线程

Java 中的synchronized是一种悲观锁，悲观锁始终假设会发生并发冲突，因此会阻止一切可能违反数据完整性的操作。而 CAS 是一种乐观锁 CAS 全称是 Compare and Swap。乐观锁假设不会发生并发冲突，因此只在提交的时候检查是否违反数据完整性，如果提交失败则会进行重试。

CAS 支持原子更新操作，适用于计数器，序列发生器等场景。CAS 操作失败时由开发者决定是继续尝试，还是执行别的操作。

BIO、NIO、AIO 的区别

BIO

包括基于字节流的 InputStream 和 OutputStream，以及基于字符流的 Reader 和Writer。 ## NIO NonBlock-IO：构建多路复用的、同步非阻塞的 IO 操作 - Channels 其中 FileChannels 有 transferTo 和 transferFrom 两个方法，适合大文件的拷贝，避免了两次用户态和内核态的上下文切换，即"零拷贝"，效率高

synchronized 关键字是为了解决线程安全问题的。我们先来了解下解决线程安全问题的主要诱因。线程安全问题的主要诱因有两点： - 存在共享数据(也称为临界资源) - 存在多条线程共同操作这些共享数据

要解决线程安全问题，只有一个办法：保证同一时刻有且只有一个线程在操作共享数据，其他线程必须等待该线程处理完数据后再对共享数据进行操作。

• 强引用(Strong Reference)
  • 最普遍的引用：Object obj = new Object();
  • 内存不够时，即使抛出 OOM 也不会回收具有强引用的对象
  • 通过将对象设置为 null，使其被回收
• 软引用(Soft Reference)
  • 对象处理有用但非必须的状态
  • 只有当内存空间不足时，GC 会回收该引用的对象的内存

当调用 Thread 中的 yield() 函数时，会给线程调度器一个当前线程愿意让出 CPU 使用权的提示，但是线程调度器可能会忽略这个暗示。也就是线程调度器可能会继续执行该线程，也可能暂停这个线程。 如下例子：