【面试】Java 记录一次面试过程 三年工作经验

2025

个人工作经验与基础概念

• 工作挑战及解决方式：这需要根据个人实际工作经历来回答，例如在项目中遇到性能瓶颈，通过代码优化、数据库索引调整或引入缓存机制等方式解决。
• 单例模式：
  • 常见的实现方式有饿汉式、懒汉式（线程安全与不安全版本）、双重检查锁定、静态内部类等。
  • 例如饿汉式：

public class Singleton {private static Singleton instance = new Singleton();private Singleton() {}public static Singleton getInstance() {return instance;}
}

破坏单例的方式：

反射：通过反射获取单例类的构造函数并创建新实例，如：

Class clazz = Singleton.class;
Constructor constructor = clazz.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton newInstance = (Singleton) constructor.newInstance();

反序列化：如果单例类实现了 Serializable 接口，在反序列化时会创建新对象。

可通过重写 readResolve 方法来防止，如：

private Object readResolve() {return instance;
}

对象克隆：若单例类未重写 clone 方法或重写不当，可能被克隆出多个实例。

应重写 clone 方法并抛出 CloneNotSupportedException。

• JDK 相关知识：
  • JDK（Java Development Kit）是 Java 开发工具包，包含 JRE（Java Runtime Environment）和一系列开发工具。JRE 则是运行 Java 程序的最小环境，包括 Java 虚拟机（JVM）、Java 核心类库等。
  • JIT（即时编译器）原理：Java 程序最初由 JVM 中的解释器执行，随着程序运行，JIT 编译器会将热点代码（频繁执行的代码段）编译成机器码，存储在代码缓存中，后续执行时直接执行编译后的机器码，提高执行效率。它会进行诸如方法内联、逃逸分析等优化操作，减少方法调用开销和对象创建开销等。
• Java 线程基础：
  线程定义：线程是进程内的一个执行单元，一个进程可以包含多个线程，它们共享进程的资源（如内存空间），但有自己的程序计数器、栈等。

实现方式：
继承 Thread 类：

public class MyThread extends Thread {@Overridepublic void run() {// 线程执行的逻辑}
}
// 使用：MyThread thread = new MyThread(); thread.start();

实现 Runnable 接口：

public class MyRunnable implements Runnable {@Overridepublic void run() {// 线程执行的逻辑}
}
// 使用：Thread thread = new Thread(new MyRunnable()); thread.start();

线程池参数含义：
- 核心线程数（corePoolSize）：线程池长期维持的最小线程数量，即使线程处于空闲状态也不会被回收。
- 最大线程数（maximumPoolSize）：线程池允许创建的最大线程数量。
- 队列容量（workQueue）：用于存放等待执行任务的阻塞队列，如 ArrayBlockingQueue、LinkedBlockingQueue 等。
- 线程存活时间（keepAliveTime）：当线程池中的线程数量超过核心线程数时，空闲线程的存活时间。

拒绝策略：
- AbortPolicy：直接抛出 RejectedExecutionException 异常，阻止任务提交。
- CallerRunsPolicy：由调用者线程（提交任务的线程）执行被拒绝的任务。
- DiscardPolicy：直接丢弃被拒绝的任务，不做任何处理。
- DiscardOldestPolicy：丢弃阻塞队列中最老的任务（即最早进入队列的任务），然后重新尝试提交当前任务。

线程状态及切换：
- 新建（New）：创建线程对象后但尚未调用 start 方法的状态。
- 就绪（Runnable）：线程对象调用 start 方法后，等待 CPU 资源分配的状态。
- 运行（Running）：线程获得 CPU 资源，正在执行 run 方法的状态。
- 阻塞（Blocked）：线程因等待锁、等待 I/O 操作完成等原因暂停执行，进入阻塞状态，例如 synchronized 块获取锁失败时。
- 死亡（Terminated）：线程执行完 run 方法或因异常退出后的状态。
-
- 切换条件：
- 就绪到运行：线程调度器从就绪队列中选择一个线程分配 CPU 资源。
- 运行到阻塞：如遇到 synchronized 锁未获取到、wait 方法调用、I/O 操作等。
- 阻塞到就绪：如锁被释放、I/O 操作完成、notify 或 notifyAll 方法被调用使线程从 wait 状态唤醒等。
- 运行到死亡：线程正常执行完 run 方法或因未捕获的异常导致线程终止。

引用类型与 ThreadLocal

• 字符串与引用类型：
  • String：是不可变的字符序列，其对象一旦创建就不能被修改。它适用于字符串常量操作，因为不可变性保证了字符串在多线程环境下的安全性，并且可以被共享。例如：String str = "hello";。
  • StringBuilder：是可变的字符序列，非线程安全，适用于单线程下频繁修改字符串的场景，如字符串拼接操作，其性能比 String 频繁拼接要高。例如：

StringBuilder sb = new StringBuilder();
sb.append("hello");
sb.append(" world");
String result = sb.toString();

StringBuffer：也是可变的字符序列，但它是线程安全的，适用于多线程环境下的字符串操作，但由于加锁机制，性能相对 StringBuilder 稍低。例如：

StringBuffer sbf = new StringBuffer();
sbf.append("hello");
sbf.append(" world");
String result = sbf.toString();

String 的常量池特性：Java 为了提高字符串的使用效率，维护了一个字符串常量池。当创建字符串字面量时，JVM 会首先在常量池中查找是否存在相同内容的字符串，如果存在则直接返回该字符串的引用，否则在常量池中创建新的字符串对象并返回引用。

例如：String str1 = "hello"; String str2 = "hello"; 这里 str1 和 str2 可能指向常量池中的同一个字符串对象。

• String 类不可变的原因：
  - 安全性：不可变字符串可以在多线程环境下安全地共享，避免了因字符串修改导致的并发问题。
  - 哈希码缓存：字符串的哈希码在其生命周期内不会改变，这使得它可以在哈希相关的集合（如 HashMap）中高效地使用，因为不需要重新计算哈希码。
  - 字符串常量池：不可变性使得字符串可以被缓存和复用，提高了内存使用效率。

引用类型区别与场景：

强引用：是最常见的引用类型，如 Object obj = new Object(); 中的 obj 就是强引用。只要强引用存在，对象就不会被垃圾回收。

软引用：用于描述一些还有用但并非必需的对象。在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行二次回收。例如在缓存场景中，当内存紧张时可以回收软引用指向的缓存对象。

SoftReference<Object> softRef = new SoftReference<>(new Object());

弱引用：其生命周期更短，无论内存是否充足，只要垃圾回收器运行，弱引用指向的对象就会被回收。常用于解决内存泄漏问题，如在哈希表中，如果键使用弱引用，当对象没有其他强引用时，键可以被回收，避免哈希表中积累无用的键值对。

WeakReference<Object> weakRef = new WeakReference<>(new Object());

虚引用：也称为幽灵引用或幻影引用，是最弱的一种引用关系。无法通过虚引用获取对象实例，主要用于跟踪对象被垃圾回收的状态，在对象被回收时会收到一个系统通知。通常与引用队列结合使用，如：

ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> phantomRef = new PhantomReference<>(new Object(), queue);

---

ThreadLocal 原理：ThreadLocal 用于在多线程环境下为每个线程提供独立的变量副本。其原理是每个 Thread 对象内部都有一个 ThreadLocalMap，ThreadLocal 作为键，对应的值就是线程本地变量。当在一个线程中通过 ThreadLocal 设置变量时，实际上是将变量存储在该线程的 ThreadLocalMap 中。例如：

ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
threadLocal.set(1); // 在当前线程中设置值
Integer value = threadLocal.get(); // 获取当前线程中的值

在 ThreadLocal 的 set 方法中，首先获取当前线程，然后获取线程的 ThreadLocalMap，如果 Map 不存在则创建，接着将 ThreadLocal 实例作为键，要设置的值作为值存入 Map 中。get 方法类似，先获取当前线程的 ThreadLocalMap，再根据 ThreadLocal 实例作为键获取对应的值。

Spring 框架相关

• Spring Boot 与 Spring 对比：
  • Spring Boot 存在的必要性：
    • 简化配置：Spring 配置较为繁琐，需要大量的 XML 或 Java 配置文件来定义 bean、数据源、事务等。Spring Boot 采用约定优于配置的原则，通过自动配置机制，根据项目依赖和默认配置，自动为项目进行大量的基础配置，减少了开发者的配置工作量。例如，引入 spring-web 依赖后，Spring Boot 会自动配置一个嵌入式的 Tomcat 服务器，并设置好相关的端口、上下文路径等。
    • 快速启动：Spring Boot 提供了方便的项目启动器（starters），开发者可以通过选择不同的启动器快速搭建项目框架，并且可以通过命令行或配置文件方便地修改一些常见的配置参数，如端口号、数据库连接信息等，大大提高了项目的开发和启动效率。
    • 集成度高：Spring Boot 集成了很多常用的第三方库和框架，如数据库连接池（如 HikariCP）、日志框架（如 Logback）等，并提供了统一的配置方式，使得在项目中使用这些库更加方便。
• Spring AOP：
  • 使用场景：
    • 日志记录：在方法执行前后记录日志，方便排查问题和监控系统运行状态。例如，在业务方法执行前记录方法入参和调用时间，执行后记录返回结果和执行时长。
    • 权限验证：在方法调用前检查用户是否具有执行该方法的权限，如在控制器方法中验证用户是否已登录且具有相应的操作权限。
    • 事务管理：通过 AOP 实现事务的自动开启、提交和回滚，确保数据库操作的一致性。例如，在一个业务方法中包含多个数据库操作，AOP 可以将这些操作包裹在一个事务中，如果其中某个操作出现异常，事务会自动回滚，保证数据的完整性。
  • 实现原理：Spring AOP 主要基于动态代理机制。
    • 对于实现了接口的目标对象，Spring 默认使用 JDK 动态代理。JDK 动态代理通过 java.lang.reflect.Proxy 类和 InvocationHandler 接口实现。在运行时，JDK 动态代理会创建一个实现目标对象接口的代理类，代理类的每个方法调用都会被转发到 InvocationHandler 的 invoke 方法中，在 invoke 方法中可以在目标方法执行前后添加额外的逻辑，如日志记录、权限验证等。
    • 对于没有实现接口的目标对象，Spring 会使用 CGLIB 动态代理。CGLIB 动态代理是通过继承目标对象来实现的，在子类中重写目标对象的方法，并在重写的方法中添加额外的逻辑。CGLIB 动态代理的性能相对 JDK 动态代理可能稍低，但可以代理没有实现接口的类。
• Spring Boot 自动化配置：
  • 过程：Spring Boot 启动时，会从类路径下查找 META-INF/spring.factories 文件，该文件中配置了一系列的自动配置类。这些自动配置类会根据项目的依赖和配置情况，自动为项目配置各种组件。例如，如果项目中引入了 spring-boot-starter-web 依赖，WebMvcAutoConfiguration 类会自动配置 Spring MVC 的相关组件，如 DispatcherServlet、视图解析器等。在自动配置过程中，会通过条件注解（如 @ConditionalOnClass、@ConditionalOnMissingBean 等）来判断是否需要进行某项配置。如果满足条件，就会创建相应的 bean 并注入到 Spring 容器中。同时，开发者也可以通过在自己的配置类中使用 @EnableAutoConfiguration 注解或在 application.properties/application.yml 文件中设置相关属性来定制自动配置的行为。
• Spring 事务管理：
  • 事务传播机制：
    • REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是默认的传播行为。例如，在一个业务方法 A 中调用了另一个业务方法 B，且方法 A 已经开启了事务，如果方法 B 的事务传播机制是 REQUIRED，那么方法 B 会加入方法 A 的事务中。
    • REQUIRES_NEW：无论当前是否存在事务，都会创建一个新的事务。如果当前存在事务，会将当前事务挂起，等新事务执行完毕后再恢复原事务。例如，在一个事务方法中调用另一个事务方法，且后者的传播机制是 REQUIRES_NEW，那么后者会独立于前者执行自己的事务，即使前者出现异常回滚，后者的事务也可能正常提交。
    • NESTED：如果当前存在事务，则在嵌套事务内执行；如果当前没有事务，则创建一个新的事务。嵌套事务是外层事务的一个子事务，外层事务回滚时，嵌套事务也会回滚，但嵌套事务可以独立提交或回滚。例如，在一个事务方法中调用另一个事务方法，且后者的传播机制是 NESTED，如果后者出现异常回滚，不会影响外层事务的其他操作，除非外层事务也出现异常。
  • 事务失效的场景：
    • 方法非 public：Spring 事务管理默认只对 public 方法生效，因为事务的代理是基于接口或类的代理，如果方法不是 public，则无法通过代理拦截到方法调用，从而导致事务无法生效。
    • 异常被捕获但未抛出：Spring 事务是通过异常来触发回滚的，如果在事务方法中捕获了异常但没有抛出，事务管理器无法感知到异常，就不会进行回滚操作。例如，在一个事务方法中使用 try-catch 块捕获了异常，但没有在 catch 块中抛出 RuntimeException 或 Error 类型的异常，事务将不会回滚。
    • 事务方法嵌套调用：如果在一个事务方法内部直接调用另一个事务方法（不是通过代理调用），可能会导致事务失效。因为直接调用不会经过事务代理，无法应用事务的相关逻辑。例如，在一个 @Transactional 注解的方法 A 中，通过 this 关键字调用了另一个同样有 @Transactional 注解的方法 B，方法 B 的事务可能不会生效。

---

MySQL 数据库知识

• 事务与存储引擎：
  • ACID 特性：
    • 原子性（Atomicity）：事务是一个不可分割的工作单位，事务中的所有操作要么全部成功执行，要么全部回滚。例如，在银行转账事务中，从账户 A 转出 100 元到账户 B，这两个操作必须作为一个整体，要么都成功完成，要么都不执行，不能出现只转出而未转入或反之的情况。如果转账过程中出现错误，如账户余额不足或系统故障，整个事务会回滚，账户 A 和账户 B 的余额都不会改变。
    • 一致性（Consistency）：事务执行前后，数据库的完整性约束没有被破坏。例如，在数据库中有一个表的字段设置了非空约束，事务执行过程中不会插入或更新该字段为 null 值，保证数据始终符合预先定义的规则。再比如，在一个涉及多个表的事务中，如果存在外键约束，更新或插入数据时必须满足这些约束关系，以确保数据的一致性。
    • 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不能被其他事务干扰，各个事务之间相互隔离。例如，有两个事务同时对同一张表进行操作，一个事务在读取数据时，另一个事务对相同数据的修改不会影响到当前事务的读取结果，直到当前事务提交或回滚后，才能看到其他事务的修改。MySQL 提供了不同的隔离级别来控制事务之间的隔离程度，如读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable），不同隔离级别在并发性能和数据一致性上有不同的权衡。
    • 持久性（Durability）：一旦事务提交，其对数据库的修改将永久保存，即使系统发生故障也不会丢失。例如，事务提交后，数据会被持久化到磁盘等存储介质中，即使数据库服务器突然断电或崩溃，重启后数据仍然保持提交后的状态。MySQL 通过事务日志（如 redo log 和 binlog）来保证持久性，在系统恢复时可以根据这些日志重新执行已提交的事务，将数据恢复到一致状态。
  • 存储引擎种类及 InnoDB 使用 B+树索引原因：
    • 存储引擎种类：MySQL 常见的存储引擎有 InnoDB、MyISAM、Memory 等。InnoDB 是 MySQL 5.5 及以后版本的默认存储引擎，支持事务、行级锁和外键约束等特性，适用于大多数 OLTP（联机事务处理）应用场景。MyISAM 不支持事务和行级锁，但具有简单、高效的特点，适用于一些对事务要求不高的读密集型应用，如数据仓库、日志记录等。Memory 存储引擎将数据存储在内存中，读写速度非常快，但数据在服务器关闭后会丢失，通常用于临时表或对性能要求极高的特定场景。
    • InnoDB 使用 B+树索引原因：
      • 磁盘 I/O 优化：B+树的非叶子节点只存储索引键值，不存储数据记录，相比 B 树，相同数量的索引数据可以存储在更少的磁盘块中，使得树的高度更低。在查询数据时，减少了磁盘 I/O 次数，提高了查询效率。例如，对于一个有大量数据的表，使用 B+树索引可以更快地定位到数据所在的磁盘块。
      • 数据存储结构适配：InnoDB 采用聚簇索引（clustered index）的方式存储数据，数据行与索引键值紧密相连，按照索引顺序存储在磁盘上。B+树的叶子节点形成一个有序链表，便于范围查询（如 BETWEEN 操作）和全表扫描，能够很好地满足数据库的查询需求。例如，在执行 SELECT * FROM table WHERE column BETWEEN value1 AND value2 这样的查询语句时，B+树可以高效地遍历叶子节点获取满足条件的数据。
      • 查询性能提升：B+树的叶子节点存储了所有的索引键值和对应的数据行指针，在进行等值查询和范围查询时，都可以在叶子节点上快速定位到数据，而不需要像 B 树那样可能需要回溯到非叶子节点进行进一步查找。例如，在查询一个特定值或一个范围内的值时，B+树的结构使得查询可以直接在叶子节点上进行，减少了查找路径和时间。
  • B 树与 B+树索引结构差异：
    • 节点存储内容：B 树的每个节点都存储索引键值和对应的数据记录（如果是叶子节点）或指向子节点的指针（如果是非叶子节点）。而 B+树的非叶子节点只存储索引键值和指向子节点的指针，叶子节点存储索引键值和对应的数据行指针（在 InnoDB 中）或数据记录（在某些其他存储引擎中）。例如，在一个 B 树索引中，非叶子节点可能同时存储了部分数据，而 B+树的非叶子节点则更专注于索引键值的索引功能，数据存储在叶子节点，使得 B+树的非叶子节点可以存储更多的索引键值，降低树的高度。
    • 叶子节点连接方式：B 树的叶子节点之间没有直接的连接关系，而 B+树的叶子节点通过指针形成一个双向链表。这种连接方式使得 B+树在进行范围查询时可以方便地遍历叶子节点，提高了范围查询的效率。例如，在执行一个范围查询时，B+树可以从起始键值所在的叶子节点开始，通过链表依次访问后续的叶子节点，直到满足查询条件结束，而 B 树可能需要多次从根节点开始查找，效率相对较低。
• 索引相关知识：
  • 聚集索引和非聚集索引区别：
    • 聚集索引：数据行的物理存储顺序与索引键值的顺序一致。在 InnoDB 中，表的主键会自动成为聚集索引，如果没有显式指定主键，InnoDB 会选择一个唯一非空索引作为聚集索引，如果没有这样的索引，InnoDB 会隐式创建一个 6 字节的行 ID 作为聚集索引。聚集索引的叶子节点存储了实际的数据行，因此通过聚集索引进行查询时，可以直接获取到数据，速度较快。例如，对于一个以用户 ID 为主键的用户表，按照用户 ID 进行排序存储，当查询用户 ID 为特定值的用户信息时，可以通过聚集索引快速定位到对应的磁盘块并获取数据。
    • 非聚集索引：数据行的物理存储顺序与索引键值的顺序无关。非聚集索引的叶子节点存储的是索引键值和对应的聚集索引键值（在 InnoDB 中）或数据行指针（在其他一些存储引擎中）。在查询数据时，如果使用非聚集索引，首先通过非聚集索引找到对应的聚集索引键值或数据行指针，然后再通过聚集索引或指针去获取完整的数据行，这个过程称为回表操作。例如，在一个用户表中，如果有一个以用户姓名为列创建的非聚集索引，当查询用户姓名为特定值的用户信息时，先通过非聚集索引找到对应的用户 ID（假设用户 ID 是聚集索引键值），然后再通过用户 ID 去聚集索引中获取完整的用户信息。
  • 回表操作原理及避免方法：
    • 回表操作原理：当使用非聚集索引进行查询时，如果查询的列不在非聚集索引中，数据库需要根据非聚集索引的叶子节点存储的信息（如聚集索引键值）回到聚集索引中查找完整的数据行，这个过程就是回表操作。例如，在一个包含用户 ID、用户姓名、用户年龄等列的用户表中，如果创建了一个以用户姓名为索引的非聚集索引，当执行 SELECT * FROM users WHERE name = 'John' 这样的查询语句时，首先通过用户姓名的非聚集索引找到对应的用户 ID，然后再根据用户 ID 去聚集索引中获取用户的其他信息（如年龄等），这个从非聚集索引到聚集索引查找数据的过程就是回表操作。回表操作会增加磁盘 I/O 次数，降低查询效率，尤其是在查询结果集较大时影响更为明显。
    • 避免回表方法：合理创建联合索引是避免回表的一种有效方法。例如，如果经常需要查询用户姓名和年龄的信息，可以创建一个包含用户姓名和年龄的联合索引。这样，在查询时，如果查询条件只涉及用户姓名和年龄，就可以直接从联合索引中获取所需数据，而不需要回表操作。另外，在查询语句中只选择需要的列，避免使用 SELECT *，也可以减少回表操作的可能性。例如，如果只需要查询用户姓名和用户 ID，而不需要其他列的信息，在查询语句中明确指定这两列，数据库可以直接从索引中获取这些数据，而不需要回表获取其他不必要的列。
  • 公司使用索引的原则：
    • 避免在索引列上使用函数：如果在索引列上使用函数，数据库可能无法使用索引进行优化。例如，在一个存储日期的列上创建了索引，如果查询语句使用 WHERE YEAR(date_column) = 2023 这样的条件，数据库可能不会使用该索引，因为对索引列应用了函数。正确的做法是将日期范围作为条件进行查询，如 WHERE date_column BETWEEN '2023-01-01' AND '2023-12-31'，这样数据库可以利用索引快速定位到满足条件的数据。
    • 避免使用 LIKE ‘%…%’ 模糊查询：这种模糊查询方式在大多数情况下会导致数据库进行全表扫描，无法利用索引。例如，执行 SELECT * FROM table WHERE column LIKE '%keyword%' 这样的查询语句时，数据库需要遍历整个表来查找包含关键字的记录。如果确实需要进行模糊查询，可以考虑使用 LIKE ‘keyword%’ 这样的前缀匹配方式，在某些情况下数据库可以利用索引进行优化。例如，SELECT * FROM table WHERE column LIKE 'John%'，如果在 column 列上有合适的索引，数据库可以通过索引快速定位到以 ‘John’ 开头的记录。

项目设计与架构

• 权限系统设计：
  • 数据库表结构及关系：
    • 用户表：通常包含用户 ID、用户名、密码、用户状态（如启用/禁用）等字段。用户 ID 作为主键，用于唯一标识每个用户。例如，在一个简单的用户表中，可能有如下结构：

CREATE TABLE users (user_id INT PRIMARY KEY,username VARCHAR(50) NOT NULL,password VARCHAR(100) NOT NULL,status ENUM('enabled', 'disabled') NOT NULL DEFAULT 'enabled'
);

角色表：包含角色 ID、角色名称等字段，角色 ID 为主键。例如：

CREATE TABLE roles (role_id INT PRIMARY KEY,role_name VARCHAR(50) NOT NULL
);

权限表：存储权限信息，如权限 ID、权限名称、权限描述等，权限 ID 为主键。例如：

CREATE TABLE permissions (permission_id INT PRIMARY KEY,permission_name VARCHAR(50) NOT NULL,permission_description VARCHAR(200)
);

用户 - 角色关联表：用于建立用户和角色之间的多对多关系，通常包含用户 ID 和角色 ID 两个外键，共同构成联合主键。例如：

CREATE TABLE user_roles (user_id INT NOT NULL,role_id INT NOT NULL,PRIMARY KEY (user_id, role_id),FOREIGN KEY (user_id) REFERENCES users(user_id),FOREIGN KEY (role_id) REFERENCES roles(role_id)
);

角色 - 权限关联表：建立角色和权限之间的多对多关系，包含角色 ID 和权限 ID 两个外键，共同构成联合主键。例如：

CREATE TABLE role_permissions (role_id INT NOT NULL,permission_id INT NOT NULL,PRIMARY KEY (role_id, permission_id),FOREIGN KEY (role_id) REFERENCES roles(role_id),FOREIGN KEY (permission_id) REFERENCES permissions(permission_id)
);

资源存储位置：资源信息（如菜单、功能模块等）可以存储在单独的资源表中，资源表包含资源 ID、资源名称、资源 URL 等字段，资源 ID 为主键。然后通过权限 - 资源关联表建立权限和资源之间的关系，该表包含权限 ID 和资源 ID 两个外键，共同构成联合主键。例如：

CREATE TABLE resources (resource_id INT PRIMARY KEY,resource_name VARCHAR(50) NOT NULL,resource_url VARCHAR(200) NOT NULL
);CREATE TABLE permission_resources (permission_id INT NOT NULL,resource_id INT NOT NULL,PRIMARY KEY (permission_id, resource_id),FOREIGN KEY (permission_id) REFERENCES permissions(permission_id),FOREIGN KEY (resource_id) REFERENCES resources(resource_id)
);

• 单点系统实现：
  • 实现思路：单点登录（SSO）系统的实现通常基于共享认证机制。可以采用基于令牌（Token）的方式，用户在一个系统登录成功后，认证服务器会生成一个加密的令牌，并将其返回给用户。用户在访问其他系统时，携带这个令牌，其他系统通过验证令牌的有效性来确认用户的身份，而无需用户再次登录。例如，在一个企业内部有系统 A 和系统 B，用户在系统 A 登录后，系统 A 向认证服务器发送登录请求，认证服务器验证用户身份后生成一个包含用户信息和有效期的令牌（如 JWT - JSON Web Token）并返回给系统 A，系统 A 将令牌存储在用户的浏览器 Cookie 或本地存储中。当用户访问系统 B 时，系统 B 从用户请求中获取令牌，并向认证服务器发送验证请求，认证服务器验证令牌合法后，系统 B 允许用户访问，实现单点登录。
  • 会话管理：
    • Session 共享：可以使用集中式存储（如 Redis）来存储用户会话信息。当用户在一个系统登录成功后，将会话信息存储到 Redis 中，在其他系统需要验证用户身份时，从 Redis 中获取会话信息进行验证。例如，在一个基于 Spring Boot 的应用集群中，多个实例可以共享 Redis 中的会话数据。在用户登录系统 A 时，系统 A 将用户的会话信息（如用户 ID、登录时间、权限信息等）以键值对的形式存储到 Redis 中，键可以是用户的唯一标识（如用户 ID 或令牌）。当用户访问系统 B 时，系统 B 从请求中获取用户标识，然后从 Redis 中查询对应的会话信息，根据会话信息判断用户是否已登录和具有相应权限。
    • 会话一致性维护：为了保证在分布式环境下会话的一致性，可以采用会话粘性（Session Affinity）或分布式会话管理技术。会话粘性是指将用户的请求始终路由到处理其初始登录请求的服务器实例上，这样可以保证该服务器实例上的会话信息是最新的。例如，在负载均衡器上配置会话粘性，根据用户的某个标识（如 IP 地址或 Cookie 中的特定字段）将用户请求路由到同一台后端服务器。分布式会话管理技术则是通过在多个服务器实例之间同步会话信息来保证一致性，如使用消息队列或专门的分布式会话管理框架，当一个服务器实例上的会话信息发生改变时，及时通知其他相关服务器实例更新会话信息。
  • 跨域问题处理：
    • CORS（跨域资源共享）：在服务器端设置 Access-Control-Allow-Origin 等 CORS 头信息，指定允许访问的源。例如，如果单点登录系统的认证服务器域名为 auth.example.com，而系统 A 的域名为 app1.example.com，系统 B 的域名为 app2.example.com，在认证服务器的响应头中设置 Access-Control-Allow-Origin: app1.example.com,app2.example.com，允许系统 A 和系统 B 访问认证服务器的资源。同时，还可以设置其他相关头信息，如 Access-Control-Allow-Methods 来指定允许的 HTTP 方法（如 GET、POST 等），Access-Control-Allow-Headers 来指定允许的请求头信息。
    • JSONP（JSON with Padding）：对于一些不支持 CORS 的老旧浏览器，可以采用 JSONP 方式。在客户端，通过动态创建 <script> 标签，将请求的 URL 设置为认证服务器的某个接口，并带上回调函数名作为参数。认证服务器在返回数据时，将数据包装在回调函数中进行响应。例如，客户端代码如下：

function handleResponse(data) {// 处理认证服务器返回的数据
}var script = document.createElement('script');
script.src = 'https://auth.example.com/login?callback=handleResponse';
document.body.appendChild(script);

认证服务器在接收到请求后，根据用户的登录情况生成数据，并返回类似如下的响应：

handleResponse({ "status": "success", "user": { "id": 123, "name": "John" } });

• Token 认证：在跨域情况下，使用 Token 认证可以避免一些跨域问题。如前面所述，用户在登录后获取 Token，在访问其他系统时，将 Token 放在请求头（如 Authorization 头）中进行传递。系统在接收到请求后，通过验证 Token 的有效性来确认用户身份，而不需要依赖 Cookie 等可能存在跨域问题的机制。例如，在系统 A 登录后，用户获得一个 JWT Token，在访问系统 B 时，在请求头中添加 Authorization: Bearer <token>，系统 B 接收到请求后，解析 Token 并验证其有效性，如果有效则允许用户访问。