Day19

1. ConcurrentHashMap为什么是线程安全的？

JDK1.7中，ConcurrentHashMap 将整个表分为若干段（默认16段），每段维护一部分数据，只有访问同一段的数据才需要竞争锁，从而提高了并发性。
JDK1.8中，移除了Segment，结构变成：Node[] + 链表 / 红黑树。改用了 CAS 和 synchronized 组合方式，先用 CAS 尝试插入，如果失败再用 synchronized 锁住某个桶（Node链表或红黑树）进行插入，这样锁的粒度更小，性能更高。
总结：因为它在不同版本中采用了不同的并发控制机制。在 JDK1.7中，它使用分段锁（Segment + ReentrantLock），将整个 Map 拆分成多个段，每段独立加锁，提高并发性能。而在 JDK1.8中，移除了 Segment，改为使用数组 + 链表/红黑树结构，并结合 CAS（无锁操作）和 synchronized 对桶级节点加锁，实现更细粒度的并发控制。这些机制确保了在多线程读写时的数据一致性和线程安全，同时相比 Hashtable 的全表锁，性能更高、扩展性更强。

2. 讲一下银行家算法

银行家算法是一种操作系统中用于避免死锁的资源分配算法。它通过模拟资源分配，并在每次分配前进行安全性检查，确保系统始终处于安全状态，从而避免因资源分配不足导致死锁。它的核心思想类似银行发放贷款，在确保不会破产的前提下，才允许借出资源。
比如，每个进程声明一个最大的资源需求，系统记录当前分配和可用资源。当某个进程发起请求时，银行家算法会先判断请求是否合法（没有超过声明的最大值），然后模拟“如果我把资源给了它，系统是否仍然安全”，也就是：是否存在一个顺序，系统能让所有进程最终完成并释放资源。如果存在这个顺序，则系统是安全的，允许分配；否则拒绝请求。整个过程确保系统不会进入死锁状态。

3. 讲一下页表

页表是操作系统用于实现虚拟地址到物理地址映射的关键数据结构。在分页机制中，每个进程有独立的页表，记录每个虚拟页映射到哪个物理页框。页表使得进程可以使用连续的虚拟地址空间，而操作系统负责将其分布映射到物理内存中。为提高效率，系统通常会采用多级页表和TLB（快表）等优化手段来减少访问延迟和内存开销。

虚拟地址 = 页号 + 页内偏移

页表是存储在内存里的，内存管理单元（MMU）就做将虚拟内存地址转换成物理地址的工作。

4. 讲下为什么进程之下还要设计线程，线程之间是怎么通信的？

进程之下设计线程，主要是为了提升程序的并发性能和资源利用率。进程是操作系统分配资源的基本单位，拥有独立的地址空间，但进程切换成本高。而线程是程序执行的最小单位，同一进程内的多个线程可以共享内存、文件等资源，上下文切换开销更小，创建和销毁也更快。这样可以在保持资源共享的同时，实现真正的并发执行，更高效地利用多核 CPU，也更适合处理复杂、耗时的任务。比如在服务器中，主线程接收请求，子线程并发处理逻辑，大大提升了系统的吞吐量。
线程之间的通信主要通过共享内存来实现。因为同一进程内的线程共享堆内存、方法区等资源，所以它们可以直接通过共享变量来交换数据，这是线程通信最常见的方式。但由于同时访问共享变量容易产生线程安全问题，所以通常需要使用同步机制来保证数据一致性。
条件变量、CAS、mutex、信号量和读写锁都是多线程并发编程中的重要工具，其中条件变量和信号量主要用于线程之间的通信和协作，比如一个线程等待、另一个线程通知；而 mutex、CAS 和读写锁主要用于线程间的同步，防止同时访问共享资源导致数据不一致。它们共同构成了线程通信和同步的基础机制。

5. 讲一下MySQL里的锁？

MySQL的锁机制主要是为了提升并发性能、保证数据一致性。它分为多个层次，包括 全局锁、表级锁、行级锁，以及元数据锁（MDL）。

1. 全局锁：比如执行FLUSH TABLES WITH READ LOCK，整个数据库进入只读状态。这个场景主要用于全库备份，确保备份过程中数据不被修改。
2. 表级锁：像LOCK TABLES加的锁是显式的，会锁整个表，对并发不友好。还有元数据锁（MDL）是系统自动加的：当对表做查询、更新时，MySQL会加一个读锁，防止其他线程修改表结构；当执行ALTER TABLE这类DDL时，就需要写锁，这时候其他线程的DML也会被阻塞。这在我们多个线程并发操作时很关键。
3. 行级锁：是InnoDB的优势所在，它的粒度最小、并发性最高。比如在更新或查询某一条记录时，会加一个行锁（Record Lock）。MySQL 为了防止幻读，还会在某些隔离级别下使用间隙锁（Gap Lock）或 Next-Key Lock（记录锁 + 间隙锁）来锁定一个范围，防止别人插入新行，保证可重复读。例如我做范围查询时加了 Next-Key Lock，即使记录本身不存在，只要在锁定范围内，其他事务也不能插入，避免了幻读问题。
4. 意向锁：这是 InnoDB 自动加的，它本身不阻塞，但能让系统快速判断是否可以对某行加锁。比如我更新一条记录时，先在表级加意向排他锁，然后再对记录加排他锁。如果表上已经有冲突的意向锁，就不用浪费资源去遍历整张表了。

6. MySQL主从复制了解吗？

MySQL的主从复制（Master-Slave Replication）是一种用于实现数据同步的机制，主要用于提升数据库的读写性能、实现读写分离、数据备份和故障恢复等。它的基本原理是：主库在执行写操作时，会将这些操作以事件的形式记录到二进制日志（binlog）中；从库通过 I/O 线程连接主库并拉取 binlog 内容，保存到本地的中继日志（relay log）；然后从库的 SQL 线程会读取 relay log，并在从库上执行相同的 SQL 操作，从而保证主从数据一致。
主从复制默认是异步的，即主库提交事务后不等待从库确认，虽然性能高，但存在延迟和数据丢失风险；MySQL 也支持半同步复制和全同步复制，用于在数据安全性和性能之间做权衡。为了简化主从切换和容灾管理，MySQL 还提供了基于 GTID（全局事务 ID）的复制方式，通过唯一事务 ID 跟踪和定位事务，提升管理效率。