问题：Java 提供了哪些 IO 方式？ NIO 如何实现多路复用？

• 分析：
  在实际面试中，从传统 IO 到 NIO、NIO 2，其中有很多地方可以扩展开来，考察点涉及方方面面，比如：
  基础 API 功能与设计， InputStream/OutputStream 和 Reader/Writer 的关系和区别。
  NIO、NIO 2 的基本组成。
  给定场景，分别用不同模型实现，分析 BIO、NIO 等模式的设计和实现原理。
  NIO 提供的高性能数据操作方式是基于什么原理，如何使用？
  或者，从开发者的角度来看，你觉得 NIO 自身实现存在哪些问题？有什么改进的想法吗？

• 基础回答：
  Java IO 方式有很多种，基于不同的 IO 抽象模型和交互方式，可以进行简单区分。

  • 首先，传统的 java.io 包，它基于流模型实现，提供了我们最熟知的一些 IO 功能，比如 File 抽象、输入输出流等。交互方式是同步、阻塞的方式，也就是说，在读取输入流或者写入输出流时，在读、写动作完成之前，线程会一直阻塞在那里，它们之间的调用是可靠的线性顺序。
    java.io 包的好处是代码比较简单、直观，缺点则是 IO 效率和扩展性存在局限性，容易成为应用性能的瓶颈。
    很多时候，人们也把 java.net 下面提供的部分网络 API，比如 Socket、ServerSocket、HttpURLConnection 也归类到同步阻塞 IO 类库，因为网络通信同样是 IO 行为。

  • 第二，在 Java 1.4 中引入了 NIO 框架（java.nio 包），提供了 Channel、Selector、Buffer 等新的抽象，可以构建多路复用的、同步非阻塞 IO 程序，同时提供了更接近操作系统底层的高性能数据操作方式。

  • 第三，在 Java 7 中，NIO 有了进一步的改进，也就是 NIO 2，引入了异步非阻塞 IO 方式，也有很多人叫它 AIO（Asynchronous IO）。异步 IO 操作基于事件和回调机制，可以简单理解为，应用操作直接返回，而不会阻塞在那里，当后台处理完成，操作系统会通知相应线程进行后续工作。

问题：如何保证容器是线程安全的？ConcurrentHashMap 如何实现高效地线程安全？

• 分析：
  不管大小厂面试，对线程及线程安全一定是避不开的话题。现在的套路一般就从基本的线程并发情况下会出什么问题--->线程并发问安全问题如何解决---->常用的concurrent包组件---->常用的线程安全集合---->线程安全集合的实现原理这一套问题。
  在面试准备过程中，concurrent包里面的常见组件，如线程池，Atomic，Concurrent这几套东西，是一定要好好准备。

  如果要深入思考并回答这个问题及其扩展方面，至少需要：

  • 理解基本的线程安全工具。
  • 理解传统集合框架并发编程中 Map 存在的问题，清楚简单同步方式的不足。
  • 梳理并发包内，尤其是 ConcurrentHashMap 采取了哪些方法来提高并发表现。
  • 最好能够掌握 ConcurrentHashMap 自身的演进，目前的很多分析资料还是基于其早期版本。

• 基本回答：
  Java 提供了不同层面的线程安全支持。在传统集合框架内部，除了 Hashtable 等同步容器，还提供了所谓的同步包装器（Synchronized Wrapper），我们可以调用 Collections 工具类提供的包装方法，来获取一个同步的包装容器（如 Collections.synchronizedMap），但是它们都是利用非常粗粒度的同步方式，在高并发情况下，性能比较低下。
  另外，更加普遍的选择是利用并发包提供的线程安全容器类，它提供了：

  • 各种并发容器，比如 ConcurrentHashMap、CopyOnWriteArrayList。

  • 各种线程安全队列（Queue/Deque），如 ArrayBlockingQueue、SynchronousQueue。

  • 各种有序容器的线程安全版本等。

  具体保证线程安全的方式，包括有从简单的 synchronize 方式，到基于更加精细化的，比如基于分离锁实现的 ConcurrentHashMap 等并发实现等。具体选择要看开发的场景需求，总体来说，并发包内提供的容器通用场景，远优于早期的简单同步实现。

  其次，ConcurrentHashMap 的设计实现其实一直在演化，比如在 Java 8 中就发生了非常大的变化（Java 7 其实也有不少更新）这里先简单说明，早期 ConcurrentHashMap，其实现是基于：

  • 分离锁，也就是将内部进行分段（Segment），里面则是 HashEntry 的数组，和 HashMap 类似，哈希相同的条目也是以链表形式存放。
  • HashEntry 内部使用 volatile 的 value 字段来保证可见性，也利用了不可变对象的机制以改进利用 Unsafe 提供的底层能力，比如 volatile access，去直接完成部分操作，以最优化性能，毕竟 Unsafe 中的很多操作都是 JVM intrinsic 优化过的。

问题：synchronized 和 ReentrantLock 有什么区别？有人说 synchronized 最慢，这话靠谱吗？

• 分析：题目是考察并发编程的常见基础题，下面给出的典型回答算是一个相对全面的总结。
  对于并发编程，不同公司或者面试官面试风格也不一样，有个别大厂喜欢一直追问你相关机制的扩展或者底层，有的喜欢从实用角度出发，所以你在准备并发编程方面需要一定的耐心。
  个人认为，锁作为并发的基础工具之一，你至少需要掌握：

  • 理解什么是线程安全。
  • synchronized、ReentrantLock 等机制的基本使用与案例。
    更进一步，你还需要：
  • 掌握 synchronized、ReentrantLock 底层实现；理解锁膨胀、降级；理解偏斜锁、自旋锁、轻量级锁、重量级锁等概念。
  • 掌握并发包中 java.util.concurrent.lock 各种不同实现和案例分析。

• 基本回答：
  synchronized 是 Java 内建的同步机制，所以也有人称其为 Intrinsic Locking，它提供了互斥的语义和可见性，当一个线程已经获取当前锁时，其他试图获取的线程只能等待或者阻塞在那里。

  在 Java 5 以前，synchronized 是仅有的同步手段，在代码中， synchronized 可以用来修饰方法，也可以使用在特定的代码块儿上，本质上 synchronized 方法等同于把方法全部语句用 synchronized 块包起来。

  ReentrantLock，通常翻译为再入锁，是 Java 5 提供的锁实现，它的语义和 synchronized 基本相同。再入锁通过代码直接调用 lock() 方法获取，代码书写也更加灵活。与此同时，ReentrantLock 提供了很多实用的方法，能够实现很多 synchronized 无法做到的细节控制，比如可以控制 fairness，也就是公平性，或者利用定义条件等。但是，编码中也需要注意，必须要明确调用 unlock() 方法释放，不然就会一直持有该锁。

  synchronized 和 ReentrantLock 的性能不能一概而论，早期版本 synchronized 在很多场景下性能相差较大，在后续版本进行了较多改进，在低竞争场景中表现可能优于 ReentrantLock。

推荐资源：
Java基础教学视频，https://ke.qq.com/course/272077和https://ke.qq.com/course/326275