Java 必知必会

1、Error 和 Exception 什么区别？

• Error：表示严重的系统级错误，通常由JVM或底层环境引发，如内存溢出（OutOfMemoryError）、类加载失败（NoClassDefFoundError）等。这类问题通常无法通过程序恢复，开发者不建议捕获。
• Exception：表示程序运行中可预料的异常情况，如文件未找到（FileNotFoundException）、空指针（NullPointerException）等。这类异常应该被捕获并处理，以保证程序健壮性。
  • 检查异常（Checked Exception）：必须显式捕获（try-catch）或声明抛出（throws），如IOException。
  • 非检查异常（Unchecked Exception）：即RuntimeException及其子类，编译器不强制处理，但建议在代码逻辑中避免触发，如ArrayIndexOutOfBoundsException。

2、已经有了 String，为何还需要 StringBuffer、StringBuilder？

• String 是不可变的（所有属性用 final 修饰），每次修改（如拼接、截取）都会生成新对象，导致内存浪费和性能损耗，尤其在频繁操作时（如循环拼接）效率极低。
• StringBuffer 和 StringBuilder 是可变的，直接在原对象上修改字符数组，避免频繁创建新对象，显著提升性能。
  • StringBuffer 的方法通过 synchronized 关键字实现线程安全，适合多线程环境，但同步机制会降低性能。
  • StringBuilder 非线程安全，无同步开销，单线程环境下性能最优，是默认推荐的字符串操作工具。

3、Java动态代理的原理

3.1 JDK动态代理

原理：基于接口，通过Proxy和InvocationHandler生成代理类，要求被代理类实现接口。
优点：
简单易用，无需第三方依赖。
性能较好（生成后方法调用接近原生）。
缺点：
仅支持接口代理，无法代理未实现接口的类。
无法处理final类或final方法。

public interface UserService {
    void救人();
}

@Service
public class UserServiceImpl implements UserService {
    @Override
    public void救人() {
        System.out.println("医生: 救人操作");
    }
}

@Configuration
@EnableTransactionManagement
public class AppConfig {
    @Bean
    public PlatformTransactionManager transactionManager(DataSource dataSource) {
        return new DataSourceTransactionManager dataSource);
    }
}

// 测试类
@Autowired
private UserService userService;

@Test
public void testProxyType() {
    System.out.println(userService.getClass()); // 输出: com.sun.proxy. $ Proxy0（JDK 代理）
}

3.2 CGLIB动态代理

原理：基于类继承，通过生成目标类的子类实现代理，无需接口。
优点：
支持代理任意类（包括无接口、final类）。
无接口依赖，灵活性更高。
缺点：
依赖第三方库（如ASM），实现复杂。
性能开销较大（生成代理类耗时）。
可能破坏封装性（通过继承修改类行为）。

@Service
public class DoctorService {
    @Transactional
    public void手术() {
        System.out.println("医生: 手术操作");
    }
}

@Configuration
@EnableTransactionManagement
public class AppConfig {
    // 需要显式启用 CGLIB（Spring Boot 默认已启用）
    @Bean
    publicAdvisor advisor() {
        return new DefaultPointcutAdvisor(new MethodPointcut(), new TransactionInterceptor());
    }
}


// 测试
@Autowired
private DoctorService doctorService;

@Test
public void testProxyType() {
    System.out.println(doctorService.getClass()); // 输出: com.example DoctorService

$$
EnhancerBySpringCGLIB
$$
xxxx
}

3.3 Spring中的选择策略

Spring根据目标类是否实现接口自动选择：
有接口 → 优先使用JDK动态代理（性能更优）。
无接口 → 使用CGLIB代理。
总结：JDK代理适合接口明确的场景，CGLIB解决无接口和final类代理需求，两者互补满足不同开发需求。

4、Vector、ArrayList、LinkedLis的区别？

• 线程安全
  Vector：线程安全（方法用 synchronized 修饰），但性能较低。
  ArrayList 和 LinkedList：线程不安全，单线程效率更高。

• 底层结构
  Vector 和 ArrayList：基于数组实现，支持O(1) 随机访问。
  LinkedList：基于双向链表，插入/删除效率高（O(1)），但随机访问需遍历（O(n)）。

• 性能差异
  增删操作：
  Vector/ArrayList：中间插入/删除需移动元素（O(n)）。
  LinkedList：任意位置增删仅改指针（O(1)）。
  扩容：
  Vector：默认扩容 2 倍，支持自定义容量增量。
  ArrayList：默认扩容 1.5 倍，不可自定义。

• 适用场景
  Vector：需线程安全且读写均衡的场景（但更推荐 CopyOnWriteArrayList，其基于数组的写时复制机制，读无锁，写时复制新数组，适合读多写少场景。）。
  ArrayList：频繁随机访问或尾部操作。
  LinkedList：频繁增删或顺序访问（如队列、栈）。

5、HashTable、HashMap、TreeMap的区别？

• 性能优先：选择 HashMap（非并发）或 ConcurrentHashMap（并发）。
• 排序需求：使用 TreeMap。
• 遗留系统兼容：临时用 Hashtable，但优先迁移至 ConcurrentHashMap。

6、介绍下 ConcurrentHashMap 原理？

6.1 数据结构

Node数组 + 链表 + 红黑树：底层是 Node<K,V>[] 数组，哈希冲突时形成链表；当链表长度 ≥8 且 数组容量 ≥64 时，链表转红黑树（时间复杂度从 O(n) 降为 O(logN)）。

6.2 并发控制

• CAS + Synchronized：
  无锁操作：通过 CAS 实现节点的无锁插入（如空 bin 时直接 CAS 插入）。
  细粒度锁：链表或红黑树操作时，仅对头节点加锁（synchronized (f)），避免全局锁竞争。
• volatile 保证可见性：Node 的 val 和 next 字段为 volatile，确保读操作无需锁。

6.3 扩容机制

• 并发扩容：通过 nextTable 和 ForwardingNode 标记迁移状态，允许读写操作在扩容期间无缝切换新旧数组，避免阻塞。
• 逆序迁移：从数组尾部向前迁移节点，减少线程竞争。

6.4 与 JDK7 的区别

• 分段锁 → 细粒度锁：JDK7 用 Segment 分段锁，JDK8 直接锁单个链表头节点，提升并发度。
• 红黑树优化：解决长链表性能问题。

6.5 适用场景

• 高并发读写：适合多线程环境，性能优于 Hashtable 和 Collections.synchronizedMap()

总结：通过 CAS、细粒度锁、红黑树和并发扩容，Java 8 的 ConcurrentHashMap 在保证线程安全的同时，最大化并发性能。

7、线程池原理及配置最佳实践

参考：Java线程池实现原理及其在美团业务中的实践

线程数配置(最大线程数计算方式)：

• 通过监控线程平均执行时长，忽略线程上下文切换时间
• 线程数(最小设置值)：线程数 = QPS/(1000ms/平均执行时长)
• 线程数(推荐设置值)：线程数 = QPS/(1000ms/最大执行时长)
• 例如：线程平均执行20ms，则1000/20=50，代表单线程理想状态每秒处理50个请求，如果线程池每秒800QPS，则至少需要 800/50=16个线程。
• 推荐：如果用最大执行时长算出来的线程数（线程数 = QPS/(1000ms/最大执行时长)），比如线程数计算出来是100，当前机器资源满足的情况下，推荐就用最大执行时长算出来的值

队列选择：

• 同步队列：当任务数较多，且流量比较平缓，例如：QPS在800~1000之间波动，线程数足够的情况下，推荐使用同步队列
• 阻塞队列：当任务数不固定，波动明显，例如：QPS在10~1000之间波动，这时可以使用阻塞队列
• 推荐：高流量，线程数配置足够，使用同步队列；低流量，线程数配够，使用阻塞队列。且阻塞队列数> max(200,线程数*3)，如果任务数波动较大，阻塞队列配置1000+是很正常的情况
• 注意1：队列长度一定要比最大线程数多 ，多3倍是正常情况，如果最大线程数是100，队列长度至少配置300
• 注意2： 切换队列类型要重启机器生效，切换队列长度无需重启机器

8、谈谈 Java 的锁？

参考：不可不说的Java“锁”事

9、谈谈 AQS 原理？

Java AQS（AbstractQueuedSynchronizer）核心原理（精简版）

• 核心设计
  AQS 是一个构建锁和同步器的基础框架，核心由两部分组成：
  同步状态（state）：通过 volatile int 变量表示资源状态（如锁的持有次数、信号量许可证数等），支持原子操作（getState()/compareAndSetState()）。
  CLH 变体队列：基于双向链表的 FIFO 队列，用于管理竞争资源失败的线程，确保公平性和有序唤醒。
• 工作流程
  资源获取：线程尝试通过 CAS 修改 state 获取资源，若失败则封装为 Node 加入队列，并通过 LockSupport.park() 挂起。
  资源释放：持有者修改 state 并唤醒队列中的后继节点（公平锁按顺序唤醒，非公平锁允许插队）。
• 模板方法模式
  AQS 提供通用逻辑（如排队、阻塞），子类通过重写 tryAcquire()/tryRelease() 等钩子方法实现具体资源管理策略（如 ReentrantLock 的可重入性）。
• 应用场景
  支持独占锁（ReentrantLock）、共享锁（Semaphore、CountDownLatch）等，是 JUC 并发工具类的底层基础。
  关键点总结：AQS 通过 state 和队列实现线程排队与唤醒，结合模板方法模式分离通用逻辑与具体实现，提供高扩展性的同步框架。

这里通过三个工业级场景的代码示例说明区别（基于JDK 17）：

9.1 ReentrantLock（资源独占控制）

场景：支付系统的账户余额并发扣减

public class PaymentService {
    // 使用公平锁防止线程饥饿
    private final ReentrantLock lock = new ReentrantLock(true);
    private final Map<String, BigDecimal> accounts = new ConcurrentHashMap<>();

    public boolean deduct(String userId, BigDecimal amount) {
        lock.lock();  // 阻塞式获取锁
        try {
            BigDecimal balance = accounts.getOrDefault(userId, BigDecimal.ZERO);
            if (balance.compareTo(amount) >= 0) {
                accounts.put(userId, balance.subtract(amount));
                return true;
            }
            return false;
        } finally {
            lock.unlock();  // 必须finally释放
        }
    }

    // 可重入特性示例（嵌套锁）
    public boolean transfer(String from, String to, BigDecimal amount) {
        lock.lock();
        try {
            if (deduct(from, amount)) {  // 调用已加锁的方法
                accounts.compute(to, (k, v) -> v == null ? amount : v.add(amount));
                return true;
            }
            return false;
        } finally {
            lock.unlock();
        }
    }
}

9.2 Semaphore（资源流量控制）

场景：API网关的并发请求限流

public class ApiRateLimiter {
    // 允许100个并发请求 + 10个等待队列
    private final Semaphore semaphore = new Semaphore(100, true);
    private final Executor executor = Executors.newVirtualThreadPerTaskExecutor();

    public Response handleRequest(Request request) throws InterruptedException {
        if (!semaphore.tryAcquire(50, TimeUnit.MILLISECONDS)) {  // 带超时避免饥饿
            return new Response(429, "Too many requests");
        }
        
        try (executor) {
            Future<Response> future = executor.submit(() -> {
                try {
                    return processRequest(request);  // 实际业务处理
                } finally {
                    semaphore.release();  // 确保释放信号量
                }
            });
            return future.get(2, TimeUnit.SECONDS);  // 带超时控制
        } catch (TimeoutException e) {
            semaphore.release();
            return new Response(504, "Gateway timeout");
        }
    }
}

9.3 CountDownLatch（多线程协同）

场景：分布式系统服务启动依赖检查

public class ClusterHealthChecker {
    private final CountDownLatch latch = new CountDownLatch(3);
    private final ExecutorService executor = Executors.newFixedThreadPool(3);

    public void checkSystemReadiness() {
        executor.execute(() -> checkService("MySQL", "jdbc:mysql://cluster-node1,node2,node3"));
        executor.execute(() -> checkService("Redis", "redis://sentinel-master"));
        executor.execute(() -> checkService("Kafka", "kafka://broker1:9092,broker2:9092"));

        try {
            if (!latch.await(10, TimeUnit.SECONDS)) {  // 等待所有检查完成
                throw new IllegalStateException("Cluster not ready within 10s");
            }
        } finally {
            executor.shutdown();
        }
    }

    private void checkService(String name, String endpoint) {
        try (HttpClient client = HttpClient.newHttpClient()) {
            HttpRequest request = HttpRequest.newBuilder()
                    .uri(URI.create(endpoint + "/health"))
                    .timeout(Duration.ofSeconds(3))
                    .build();
            
            HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
            if (response.statusCode() == 200) {
                latch.countDown();  // 成功时递减计数器
            }
        } catch (Exception e) {
            // 记录异常但不中断其他检查
        }
    }
}

核心区别总结

工业级要点：

1. ReentrantLock配合tryLock()避免死锁
2. Semaphore使用tryAcquire()+超时防止系统雪崩
3. CountDownLatch结合await(timeout)保证系统健壮性

10、谈下Java 中的原子性、可见性、有序性

10.1 原子性（Atomicity）

定义
原子性指一个操作不可分割，要么全部执行成功，要么完全不执行，不会出现中间状态。若多线程环境下某个操作无法保证原子性，可能导致数据不一致。

核心实现

• 基本类型读写：int、boolean等基本类型的简单赋值（如 a = 10）是原子操作。
• synchronized：通过锁机制确保临界区代码的原子性。
• 原子类：如 AtomicInteger、AtomicReference，基于 CAS（Compare-And-Swap）实现无锁原子操作。

示例：非原子操作 vs 原子操作

// 非原子操作示例
int count = 0;
public void unsafeIncrement() {
    count++; // 实际包含3步：读值→加1→写回（非原子）
}

// 原子操作示例
AtomicInteger atomicCount = new AtomicInteger(0);
public void safeIncrement() {
    atomicCount.incrementAndGet(); // 原子性保证
}

问题分析：多线程并发调用 unsafeIncrement() 时，可能导致最终结果小于预期，而 safeIncrement() 通过原子类保证正确性。

10.2 可见性（Visibility）

定义
一个线程修改共享变量后，其他线程能立即感知到最新值。若缺乏可见性保障，线程可能读取到过期的缓存数据。

核心实现

• volatile：强制所有读写直接操作主内存，禁止指令重排序。
• synchronized：解锁前将变量刷新到主内存，加锁时清空工作内存。
• final：构造函数中初始化的 final 变量对其他线程可见。

示例：可见性问题与解决

// 可见性问题示例
boolean flag = true; // 无volatile修饰
new Thread(() -> {
    while (flag) {} // 可能死循环（线程读取本地缓存旧值）
}).start();
Thread.sleep(100);
flag = false; // 修改后其他线程可能无法感知

// 解决方案：使用volatile
volatile boolean volatileFlag = true;

关键点：未用 volatile 时，线程可能因缓存未更新而无法退出循环。

10.3 有序性（Ordering）

定义
程序执行顺序按代码顺序执行。由于编译器和处理器优化（指令重排序），实际执行顺序可能与代码顺序不一致，需通过同步机制保证有序性。

核心实现

• volatile：禁止指令重排序（通过内存屏障）。
• synchronized：单线程执行同步块，保证串行有序。
• happens-before原则：如线程启动规则、传递性规则等。

示例：双重检查锁单例模式（DCL）

public class Singleton {
    private static volatile Singleton instance; // volatile保证有序性
    
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // 无volatile时可能重排序导致未初始化完成
                }
            }
        }
        return instance;
    }
}

问题分析：若未用 volatile，new Singleton() 可能被重排序为：1.分配内存→3.引用赋值→2.初始化对象，导致其他线程获取未初始化的实例。

总结对比

面试要点：

1. volatile 不保证原子性（如 volatile int a; a++ 仍不安全）。
2. synchronized 同时保证原子性、可见性、有序性。
3. JMM（Java内存模型）：通过主内存与工作内存交互规则（如 lock、unlock 操作）实现三大特性。

11、Java 8 数组拷贝方法及效率分析

11.1 Java 8 数组拷贝的常用方法

1. System.arraycopy()

   • 原理：底层通过本地方法（Native）直接操作内存，支持灵活指定源数组、目标数组的起始位置和拷贝长度。
   • 优点：性能最优（尤其大数据量），时间复杂度为 O(n)。
   • 示例：

     int[] source = {1, 2, 3, 4, 5};
     int[] dest = new int[5];
     System.arraycopy(source, 0, dest, 0, source.length);
     

2. Arrays.copyOf()

   • 原理：内部调用 System.arraycopy()，但简化了操作（自动创建目标数组）。
   • 优点：代码简洁，适合整数组拷贝或扩展数组长度。
   • 示例：

     int[] source = {1, 2, 3};
     int[] dest = Arrays.copyOf(source, source.length * 2); // 扩展为长度6
     

3. Object.clone()

   • 原理：数组对象继承的浅拷贝方法，直接生成原数组的副本。
   • 优点：语法简单，性能接近 System.arraycopy()。
   • 局限性：仅适用于一维数组的完全拷贝。
   • 示例：

     int[] source = {1, 2, 3};
     int[] dest = source.clone();
     

4. 手动循环遍历

   • 原理：通过 for 循环逐个元素复制。
   • 优点：灵活性高（可自定义复制逻辑）。
   • 缺点：性能最差（时间复杂度 O(n) 但常数因子高）。
   • 示例：

     int[] source = {1, 2, 3};
     int[] dest = new int[source.length];
     for (int i = 0; i < source.length; i++) {
         dest[i] = source[i];
     }
     

5. Java 8 Stream API

   • 原理：通过 IntStream 或 Arrays.stream() 转换并生成新数组。
   • 优点：代码简洁，支持链式操作（如过滤、映射）。
   • 缺点：性能较低（涉及流式处理开销）。
   • 示例：

     int[] source = {1, 2, 3};
     int[] dest = IntStream.of(source).toArray();
     

11.2 效率对比与场景建议

根据多篇测试结果（如网页2的10,000,000元素测试）：

1. 性能排序（从高到低）：
   • System.arraycopy() > Arrays.copyOf() ≈ clone() > Stream API > 手动循环
2. 大数据量（>10,000元素）：
   • 优先选择 System.arraycopy()（如处理图像、日志数据）。
3. 小数据量或简单场景：
   • 使用 Arrays.copyOf() 或 clone()（代码简洁且性能足够）。
4. 复杂操作（如过滤、转换）：
   • 考虑 Stream API（以性能损失换取代码可读性）。

11.3 最佳实践

1. 优先选择原生方法：
   • 在性能敏感场景（如高频调用、大数据处理），System.arraycopy() 是唯一选择。
2. 多维数组处理：
   • 需手动深拷贝（如循环嵌套调用 System.arraycopy() 或递归 clone()）。
3. 避免空指针：
   • 使用 Arrays.copyOf() 时，若原数组为 null 会抛出 NullPointerException。
4. 对象数组深拷贝：
   • 若元素为对象，需确保对象实现 Cloneable 接口或通过序列化实现深拷贝。

总结

在 Java 8 中，System.arraycopy() 是效率最高的数组拷贝方法，尤其适合大规模数据操作。若需代码简洁，可选用 Arrays.copyOf() 或 clone()。对于复杂逻辑或链式处理，Stream API 提供了一定便利性，但需权衡性能损失。

12、Java动态代理的两种方式及实现过程详解

Java动态代理是一种在运行时动态生成代理对象的技术，主要用于在不修改目标类代码的情况下增强其功能（如日志、事务管理等）。其核心实现方式分为 JDK动态代理 和 CGLIB动态代理，二者各有特点，适用于不同场景。

12.1 JDK动态代理（基于接口）

核心机制：通过实现接口并利用Java原生API（Proxy类 + InvocationHandler接口）生成代理对象。

详细实现步骤：

1. 定义接口
   代理类和目标类需实现相同接口。

   public interface UserService {
       void saveUser(String name);
   }
   

2. 实现目标类
   接口的具体业务实现。

   public class UserServiceImpl implements UserService {
       @Override
       public void saveUser(String name) {
           System.out.println("保存用户：" + name);
       }
   }
   

3. 创建InvocationHandler实现类
   定义代理逻辑（增强逻辑）。

   import java.lang.reflect.InvocationHandler;
   import java.lang.reflect.Method;
   
   public class LogHandler implements InvocationHandler {
       private Object target; // 目标对象
       public LogHandler(Object target) {
           this.target = target;
       }
   
       @Override
       public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
           System.out.println("【日志】方法执行前：" + method.getName());
           Object result = method.invoke(target, args); // 调用目标方法
           System.out.println("【日志】方法执行后：" + method.getName());
           return result;
       }
   }
   

4. 生成代理对象
   通过Proxy.newProxyInstance()动态创建代理实例。

   public class Main {
       public static void main(String[] args) {
           UserService target = new UserServiceImpl();
           LogHandler handler = new LogHandler(target);
           // 生成代理对象
           UserService proxy = (UserService) Proxy.newProxyInstance(
               target.getClass().getClassLoader(),
               target.getClass().getInterfaces(),
               handler
           );
           proxy.saveUser("张三"); // 调用增强后的方法
       }
   }
   

   输出：

   【日志】方法执行前：saveUser
   保存用户：张三
   【日志】方法执行后：saveUser
   

特点：

• 仅支持接口代理，目标类必须实现接口。
• 代理对象与目标对象是兄弟关系（实现同一接口）。

12.2 CGLIB动态代理（基于继承）

核心机制：通过继承目标类并利用字节码生成库（ASM）创建子类代理对象。

详细实现步骤：

1. 引入CGLIB依赖
   Maven配置：

   <dependency>
       <groupId>cglib</groupId>
       <artifactId>cglib</artifactId>
       <version>3.3.0</version>
   </dependency>
   

2. 定义目标类
   无需实现接口。

   public class ProductService {
       public void addProduct(String product) {
           System.out.println("添加商品：" + product);
       }
   }
   

3. 创建MethodInterceptor实现类
   定义代理逻辑。

   import net.sf.cglib.proxy.MethodInterceptor;
   import net.sf.cglib.proxy.MethodProxy;
   
   public class TransactionInterceptor implements MethodInterceptor {
       @Override
       public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
           System.out.println("【事务】开启事务");
           Object result = proxy.invokeSuper(obj, args); // 调用父类（目标类）方法
           System.out.println("【事务】提交事务");
           return result;
       }
   }
   

4. 生成代理对象
   使用Enhancer类配置代理。

   import net.sf.cglib.proxy.Enhancer;
   
   public class Main {
       public static void main(String[] args) {
           Enhancer enhancer = new Enhancer();
           enhancer.setSuperclass(ProductService.class); // 指定父类
           enhancer.setCallback(new TransactionInterceptor());
           ProductService proxy = (ProductService) enhancer.create();
           proxy.addProduct("手机"); // 调用增强后的方法
       }
   }
   

   输出：

   【事务】开启事务
   添加商品：手机
   【事务】提交事务
   

特点：

• 支持代理普通类（无需接口）。
• 代理对象是目标类的子类。
• 无法代理final类或方法（因继承机制限制）。

12.3 两种方式的对比与选型

选型建议：

• 目标类有接口 → 优先选择JDK动态代理（兼容性好）。
• 目标类无接口 → 使用CGLIB（需注意final限制）。

12.4 典型应用场景

1. AOP编程：Spring通过动态代理实现日志、事务等切面功能。
2. 远程调用：RPC框架（如Dubbo）代理远程服务调用。
3. 延迟加载：MyBatis懒加载通过代理实现SQL延迟执行。

12.5 最佳实践

1. 性能优化：
   • 缓存代理对象避免重复生成（如Spring单例模式）。
   • 对高频调用方法使用CGLIB（执行效率更高）。
2. 异常处理：
   • 在InvocationHandler或MethodInterceptor中统一捕获异常。
3. 避免陷阱：
   • JDK代理中this指向代理对象，非目标对象。
   • CGLIB代理会忽略final方法的增强。

通过合理选择代理方式，可显著提升代码的可维护性和扩展性，尤其在复杂业务系统中，动态代理是解耦核心逻辑与横切关注点的关键手段。

13、Java 8 核心新特性及代码示例（面试题答案）

13.1 Lambda 表达式

作用：简化匿名内部类，支持函数式编程。
代码示例：

// 旧写法：匿名内部类实现 Runnable
new Thread(new Runnable() {
    @Override
    public void run() {
        System.out.println("旧方式");
    }
}).start();

// Lambda 写法
new Thread(() -> System.out.println("Lambda 方式")).start();

解析：Lambda 表达式通过 ()->{} 语法替代冗余的匿名类代码，提升简洁性。

13.2 函数式接口与默认/静态方法

作用：支持单一抽象方法的接口，允许接口定义默认和静态方法。
代码示例：

// 函数式接口定义
@FunctionalInterface
interface Calculator {
    int calculate(int a, int b);
    // 默认方法
    default void log() {
        System.out.println("计算结果已记录");
    }
    // 静态方法
    static void info() {
        System.out.println("计算器接口");
    }
}

// 使用 Lambda 实现
Calculator add = (a, b) -> a + b;
add.calculate(3, 5); // 输出 8
add.log();           // 调用默认方法
Calculator.info();   // 调用静态方法

解析：@FunctionalInterface 标注函数式接口，默认方法避免破坏现有实现，静态方法直接通过接口调用。

13.3 Stream API

作用：声明式处理集合数据，支持链式操作与并行计算。
代码示例：

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
List<Integer> evenSquares = numbers.stream()
    .filter(n -> n % 2 == 0)    // 过滤偶数
    .map(n -> n * n)            // 平方
    .collect(Collectors.toList()); // 收集结果
System.out.println(evenSquares); // 输出 [4, 16]

解析：filter、map 为中间操作，collect 为终端操作，支持惰性求值与并行流（parallelStream()）。

13.4 方法引用

作用：简化 Lambda 表达式，直接引用已有方法。
代码示例：

List<String> names = Arrays.asList("Alice", "Bob");
names.forEach(System.out::println); // 方法引用替代 Lambda

解析：System.out::println 等价于 s -> System.out.println(s)，语法更简洁。

13.5 Optional 类

作用：避免空指针异常，明确处理可能为 null 的值。
代码示例：

Optional<String> optional = Optional.ofNullable(getName());
String result = optional.orElse("默认值");
optional.ifPresent(name -> System.out.println(name)); // 值存在则执行

解析：orElse 提供默认值，ifPresent 避免显式判空。

13.6 新的时间日期 API（java.time）

作用：替代易错的 Date 和 Calendar，提供线程安全的时间处理。
代码示例：

LocalDate today = LocalDate.now();
LocalDate nextWeek = today.plusDays(7);
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
System.out.println(nextWeek.format(formatter));

解析：LocalDate、LocalDateTime 等类不可变且线程安全，DateTimeFormatter 简化格式化。

总结与高频面试考点

提示：回答时建议结合代码示例解释设计意图（如 Stream 的惰性求值优化性能），并对比旧版本实现（如 Runnable 匿名类 vs Lambda）以体现理解深度。

14、在Java中，实现两个线程交替打印1到100的数字

在Java中实现两个线程交替打印1到100的数字，可通过多种线程同步机制实现。以下是几种典型方法及其代码示例：

14.1 等待/通知机制（wait() 和 notify()）

原理：利用synchronized同步块和共享锁对象，通过wait()让线程等待并释放锁，notify()唤醒其他线程。
代码示例（来自）：

public class AlternatePrint {
    private static int count = 1;
    private static final Object lock = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            while (count <= 100) {
                synchronized (lock) {
                    if (count % 2 == 1) { // 奇数线程
                        System.out.println(Thread.currentThread().getName() + ": " + count++);
                        lock.notify();
                    } else {
                        try { lock.wait(); } 
                        catch (InterruptedException e) { e.printStackTrace(); }
                    }
                }
            }
        }, "奇数线程").start();

        new Thread(() -> {
            while (count <= 100) {
                synchronized (lock) {
                    if (count % 2 == 0) { // 偶数线程
                        System.out.println(Thread.currentThread().getName() + ": " + count++);
                        lock.notify();
                    } else {
                        try { lock.wait(); } 
                        catch (InterruptedException e) { e.printStackTrace(); }
                    }
                }
            }
        }, "偶数线程").start();
    }
}

关键点：

• 使用while而非if检查条件，防止虚假唤醒。
• notify()唤醒其他线程，wait()释放锁并等待。

14.2 可重入锁与条件变量（ReentrantLock 和 Condition）

原理：通过ReentrantLock创建两个条件变量（Condition），分别控制奇偶线程的执行顺序。
代码示例（参考）：

import java.util.concurrent.locks.*;

public class AlternatePrintLock {
    private static int count = 1;
    private static ReentrantLock lock = new ReentrantLock();
    private static Condition oddCondition = lock.newCondition();
    private static Condition evenCondition = lock.newCondition();

    public static void main(String[] args) {
        new Thread(() -> {
            while (count <= 100) {
                lock.lock();
                try {
                    if (count % 2 == 1) {
                        System.out.println("奇数线程: " + count++);
                        evenCondition.signal(); // 唤醒偶数线程
                    } else {
                        oddCondition.await(); // 等待
                    }
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally { lock.unlock(); }
            }
        }).start();

        new Thread(() -> {
            while (count <= 100) {
                lock.lock();
                try {
                    if (count % 2 == 0) {
                        System.out.println("偶数线程: " + count++);
                        oddCondition.signal();
                    } else {
                        evenCondition.await();
                    }
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally { lock.unlock(); }
            }
        }).start();
    }
}

优势：

• 支持更细粒度的线程控制（如唤醒指定线程）。
• 避免synchronized的隐式锁限制。

14.3 信号量（Semaphore）

原理：通过两个信号量控制奇偶线程的交替执行，初始信号量奇数线程为1，偶数线程为0。
代码示例：

import java.util.concurrent.Semaphore;

public class AlternatePrintSemaphore {
    private static int count = 1;
    private static Semaphore oddSemaphore = new Semaphore(1);
    private static Semaphore evenSemaphore = new Semaphore(0);

    public static void main(String[] args) {
        new Thread(() -> {
            while (count <= 100) {
                try {
                    oddSemaphore.acquire();
                    if (count % 2 == 1) {
                        System.out.println("奇数线程: " + count++);
                    }
                    evenSemaphore.release();
                } catch (InterruptedException e) { e.printStackTrace(); }
            }
        }).start();

        new Thread(() -> {
            while (count <= 100) {
                try {
                    evenSemaphore.acquire();
                    if (count % 2 == 0) {
                        System.out.println("偶数线程: " + count++);
                    }
                    oddSemaphore.release();
                } catch (InterruptedException e) { e.printStackTrace(); }
            }
        }).start();
    }
}

特点：

• 无需显式锁，通过信号量许可机制实现交替。

14.4 共享变量标志（volatile）

原理：通过volatile变量控制线程执行顺序，无锁但需注意可见性。
代码示例：

public class AlternatePrintVolatile {
    private static volatile int count = 1;
    private static volatile boolean isOdd = true;

    public static void main(String[] args) {
        new Thread(() -> {
            while (count <= 100) {
                if (isOdd && count % 2 == 1) {
                    System.out.println("奇数线程: " + count++);
                    isOdd = false;
                }
            }
        }).start();

        new Thread(() -> {
            while (count <= 100) {
                if (!isOdd && count % 2 == 0) {
                    System.out.println("偶数线程: " + count++);
                    isOdd = true;
                }
            }
        }).start();
    }
}

注意：

• 需确保volatile变量的原子操作，否则可能因竞态条件导致错误。

总结与选型建议

推荐：优先选择wait()/notify()或ReentrantLock，前者适合基础场景，后者适合需要精细控制的场景。若需高性能且条件简单，可尝试volatile标志位。

15、ThreadLocal 作用与实现机制详解

15.1 ThreadLocal 的核心作用

ThreadLocal 用于为 每个线程提供独立的变量副本，实现线程间的 数据隔离，避免多线程共享变量时的竞争问题。
典型应用场景：

1. 用户身份存储：在 Web 请求中存储当前用户的登录信息（如用户 ID），确保线程内共享。
2. 事务管理：Spring 使用 ThreadLocal 保存数据库连接，保证同一事务中使用同一连接。
3. 日志跟踪：为每个请求分配唯一的 Trace ID，跨方法调用时通过 ThreadLocal 传递。

对比共享变量：

• synchronized 解决线程安全问题，但性能较低。
• ThreadLocal 以空间换时间，每个线程独立操作副本，无锁竞争。

15.2 实现机制

ThreadLocal 依赖 ThreadLocalMap（线程内部的哈希表）存储数据，核心流程如下：

1. 数据结构：

   • 每个线程的 Thread 类中有一个 ThreadLocalMap 成员变量。
   • ThreadLocalMap 的 Key 是弱引用的 ThreadLocal 对象，Value 是强引用的变量值。

   // Thread 类源码
   public class Thread implements Runnable {
       ThreadLocal.ThreadLocalMap threadLocals = null; // 存储线程本地变量
   }
   

2. 数据操作流程：

   • set()：将当前 ThreadLocal 实例作为 Key，存入当前线程的 ThreadLocalMap。
   • get()：从当前线程的 ThreadLocalMap 中查找 Key 对应的 Value。

   public void set(T value) {
       Thread t = Thread.currentThread();
       ThreadLocalMap map = getMap(t); // 获取线程的 ThreadLocalMap
       map.set(this, value); // Key 是当前 ThreadLocal 实例
   }
   

3. 内存泄漏风险：

   • 原因：Entry 的 Key 是弱引用（ThreadLocal 对象），Value 是强引用。若 ThreadLocal 对象被回收，Key 变为 null，但 Value 仍被 Entry 强引用，导致无法回收。
   • 解决：使用后调用 remove() 清理 Entry，避免线程池复用线程时残留旧数据。

15.3 代码示例

场景：多线程安全计数器，每个线程独立计数。

public class ThreadLocalDemo {
    private static ThreadLocal<Integer> counter = ThreadLocal.withInitial(() -> 0);

    public static void main(String[] args) {
        ExecutorService executor = Executors.newFixedThreadPool(3);
        for (int i = 0; i < 5; i++) {
            executor.execute(() -> {
                int count = counter.get(); // 获取当前线程的副本
                count++;
                counter.set(count);        // 更新副本
                System.out.println(Thread.currentThread().getName() + " count: " + count);
                counter.remove();          // 清理防止内存泄漏（重要！）
            });
        }
        executor.shutdown();
    }
}

输出：

pool-1-thread-1 count: 1  
pool-1-thread-2 count: 1  
pool-1-thread-3 count: 1  
pool-1-thread-1 count: 1  
pool-1-thread-2 count: 1  

解析：

• 每个线程独立操作自己的计数器副本，互不干扰。
• 使用线程池时，必须调用 remove() 清理 ThreadLocal，否则线程复用会导致旧值残留。

15.4 高频面试考点

1. 与 Synchronized 区别：
   • ThreadLocal 通过数据隔离避免竞争；Synchronized 通过锁机制同步共享资源。
2. 弱引用与内存泄漏：
   • 解释 Entry 的 Key 弱引用设计及潜在泄漏风险。
3. 正确使用姿势：
   • 初始化使用 withInitial()，任务结束调用 remove()。

总结

ThreadLocal 是解决线程安全问题的轻量级方案，核心在于 线程隔离数据 和 ThreadLocalMap 存储机制。使用时需注意内存泄漏问题，推荐结合 try-finally 确保 remove() 调用。在面试中，结合代码示例和底层原理回答，可充分展示对多线程编程的深入理解。

16、Lock与synchronized的区别及代码示例

16.1 核心区别对比

16.2 代码示例说明

1. 基本用法对比

• synchronized
  修饰方法或代码块，自动加锁/解锁：

  // 修饰方法
  public synchronized void syncMethod() {
      // 同步逻辑
  }
  
  // 修饰代码块
  public void syncBlock() {
      synchronized(this) {
          // 同步逻辑
      }
  }
  

• Lock
  显式加锁，需手动释放：

  private Lock lock = new ReentrantLock();
  
  public void lockMethod() {
      lock.lock();  // 手动加锁
      try {
          // 同步逻辑
      } finally {
          lock.unlock();  // 确保释放锁
      }
  }
  

  关键点：unlock()必须放在finally中，避免死锁。

16.2 可中断与超时获取锁

• Lock支持灵活锁获取：

  public void tryLockExample() throws InterruptedException {
      if (lock.tryLock(1, TimeUnit.SECONDS)) {  // 尝试1秒内获取锁
          try {
              // 成功获取锁后的逻辑
          } finally {
              lock.unlock();
          }
      } else {
          // 超时未获取锁的逻辑
      }
  }
  

  优势：避免线程无限阻塞，提升系统响应性。

16.3 公平锁示例

• Lock支持公平锁：

  // 创建公平锁（按线程等待顺序分配锁）
  private Lock fairLock = new ReentrantLock(true);
  

  适用场景：避免线程饥饿问题（如订单处理需按提交顺序执行）。

16.4 条件变量（Condition）

• Lock通过Condition实现复杂同步：

  private Lock lock = new ReentrantLock();
  private Condition condition = lock.newCondition();
  
  public void awaitExample() throws InterruptedException {
      lock.lock();
      try {
          condition.await();  // 释放锁并等待
      } finally {
          lock.unlock();
      }
  }
  
  public void signalExample() {
      lock.lock();
      try {
          condition.signal();  // 唤醒等待线程
      } finally {
          lock.unlock();
      }
  }
  

  对比：synchronized只能通过wait()/notify()实现单一条件，而Lock可创建多个Condition（如生产者-消费者模型中的不同队列）。

16.5 适用场景总结

• 优先使用synchronized：

  • 简单同步需求（如单方法内的线程安全控制）
  • 代码简洁性要求高，无需复杂锁逻辑。

• 优先使用Lock：

  • 需要尝试获取锁、可中断锁或超时控制（如分布式锁防死锁）
  • 高并发场景下需公平性（如秒杀系统按请求顺序处理）
  • 多条件变量需求（如复杂线程协作场景）。

16.6 面试回答技巧

1. 结合场景举例：如高并发订单系统用公平锁，数据库连接池用tryLock避免阻塞。
2. 底层原理延伸：
   • synchronized基于对象头Mark Word的锁状态切换。
   • Lock基于AQS（AbstractQueuedSynchronizer）队列同步器实现。
3. 性能对比：JDK1.6后synchronized优化后性能接近Lock，但Lock在高竞争下更灵活。

通过代码示例和场景化对比，能清晰展示对两者差异的理解，体现实际开发中的技术选型能力。

17、volitale的作用，为什么要指令重排序

17.1 volatile的作用

volatile是Java中用于修饰变量的关键字，其核心作用是通过内存屏障技术实现以下特性：

1. 保证可见性

• 问题背景：在多线程环境下，普通变量的修改可能仅存在于线程的本地缓存（如CPU Cache），其他线程无法立即感知。
• 解决机制：volatile变量通过强制将修改后的值立即写入主内存，并通知其他线程的缓存失效（MESI协议），使所有线程读取时直接从主内存获取最新值。
• 示例：

  volatile boolean flag = false;
  // 线程A修改flag为true后，线程B能立即感知到变化
  

2. 禁止指令重排序

• 问题背景：编译器和处理器为了优化性能，可能对指令进行重排序（如调整无关代码的执行顺序），但在多线程中可能导致逻辑错误。
• 解决机制：volatile通过插入内存屏障（Memory Barrier）限制指令重排序，确保程序执行顺序符合预期。
  • 写操作屏障：在volatile写操作前插入StoreStore屏障，写操作后插入StoreLoad屏障。
  • 读操作屏障：在volatile读操作后插入LoadLoad屏障和LoadStore屏障。
• 经典应用：单例模式的双重检查锁（DCL），防止对象未完全初始化就被使用：

  public class Singleton {
      private static volatile Singleton instance;
      public static Singleton getInstance() {
          if (instance == null) {
              synchronized (Singleton.class) {
                  if (instance == null) {
                      instance = new Singleton(); // 防止指令重排导致对象未初始化完成
                  }
              }
          }
          return instance;
      }
  }
  

17.2 指令重排序的原因与必要性

指令重排序的本质是优化程序执行效率，具体原因如下：

1. 提升硬件资源利用率

• CPU流水线优化：现代CPU采用流水线技术并行处理指令。若某条指令需等待内存操作（如加载数据），后续无关指令可提前执行，减少空闲时间。
• 多核CPU并行性：多个CPU核心可同时执行不同指令，减少对同一内存区域的竞争。例如：

  int a = 1;  // 指令1
  int b = 2;  // 指令2
  

  若指令1和2无依赖关系，CPU可能调整执行顺序以提高并行度。

2. 编译器优化

• 代码逻辑无关性：编译器在保证单线程结果正确的前提下，可能调整语句顺序以减少寄存器读写次数。例如：

  int x = 10;      // 操作A
  int y = x + 5;   // 操作B（依赖A）
  int z = 20;      // 操作C（无依赖）
  

  操作C可能被重排到操作B之前，以充分利用寄存器资源。

3. 重排序的风险
   指令重排序在多线程中可能导致数据不一致性。例如：

// 线程A
context = loadContext();  // 操作1
inited = true;             // 操作2（可能被重排到操作1前）

// 线程B
if (inited) {              // 若操作2先执行，B可能读到未初始化的context
    context.doSomething();
}

此时需通过volatile修饰inited变量，禁止操作1和2的重排序。

17.3 总结

• volatile的核心价值：通过内存屏障实现可见性和有序性，但不保证原子性（如i++需配合锁）。
• 指令重排序的权衡：在单线程中提升效率，但在多线程中需通过同步机制（如volatile、锁）规避风险。

18、读写锁锁降级的原理与必要性

18.1 锁降级的定义

锁降级是指线程在持有写锁（独占锁）的同时获取读锁（共享锁），随后释放写锁，使得锁状态从写锁降级为读锁的过程。其核心在于：写锁未释放时获取读锁，确保数据的一致性。

18.2 锁降级的实现原理

1. AQS状态管理
   ReentrantReadWriteLock通过AQS（AbstractQueuedSynchronizer）的state变量实现锁状态管理：

   • 高16位记录读锁数量（共享锁计数）；
   • 低16位记录写锁重入次数（独占锁计数）。
     当线程持有写锁时，若尝试获取读锁，系统会检查当前线程是否持有写锁，若满足条件则直接增加读锁计数（无需排队等待），实现写锁到读锁的平滑转换。

2. 互斥规则

   • 写锁独占性：写锁存在时，其他线程无法获取读锁或写锁；
   • 读锁共享性：读锁存在时，其他线程可获取读锁，但无法获取写锁。
     锁降级通过先获取读锁再释放写锁，确保写锁释放后，其他写线程无法立即修改数据（读锁仍被持有）。

18.3 为什么需要锁降级

1. 保证数据可见性

   • 问题：若线程A释放写锁后直接读取数据，此时线程B可能获取写锁并修改数据，导致线程A读取到过期数据。
   • 解决：线程A在释放写锁前获取读锁，强制其他写线程阻塞，确保当前线程读取的是自己修改后的最新数据。

2. 防止竞态条件
   在事务性操作中，若数据修改需分阶段完成（如数据库事务），锁降级允许线程在完成部分修改后仍持有读锁，阻止其他线程在事务未完成时介入，避免中间状态被错误读取。

3. 性能优化

   • 减少锁竞争：锁降级避免了写锁释放后立即重新获取读锁的等待时间，降低线程切换开销。
   • 避免死锁：直接释放写锁再获取读锁可能导致其他线程插入修改，而锁降级通过原子性操作规避了这一问题。

18.4 锁降级与锁升级的对比

18.5 示例代码

public class Cache {
    private volatile boolean updated = false;
    private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

    public void processData() {
        rwl.readLock().lock();
        if (!updated) {
            rwl.readLock().unlock();
            rwl.writeLock().lock();  // 获取写锁
            try {
                if (!updated) {
                    // 修改数据
                    updated = true;
                }
                rwl.readLock().lock();  // 锁降级：写锁未释放时获取读锁
            } finally {
                rwl.writeLock().unlock();  // 释放写锁，此时仍持有读锁
            }
        }
        try {
            // 使用数据（其他写线程无法修改）
        } finally {
            rwl.readLock().unlock();
        }
    }
}

说明：

• 通过writeLock().lock()和readLock().lock()的顺序实现降级；
• finally块确保写锁一定被释放。

18.6 总结

锁降级通过写锁与读锁的原子性切换，解决了数据修改后的可见性与竞态问题，同时优化了高并发场景下的性能。其核心在于利用读写锁的互斥规则与AQS状态管理机制，确保数据一致性与线程安全。在开发中，锁降级常用于缓存更新、事务处理等读多写少的场景。

19、Java并发包（java.util.concurrent）核心类及使用场景详解

19.1 并发集合类

1. ConcurrentHashMap

   • 功能：线程安全的哈希表，支持高并发读写操作，通过分段锁（JDK1.7）或CAS + 同步块（JDK1.8）实现高效并发。
   • 场景：
     • 缓存系统（如全局配置存储）；
     • 高并发统计场景（如实时计数器）。

2. CopyOnWriteArrayList / CopyOnWriteArraySet

   • 功能：写时复制的线程安全集合，读操作无锁，写操作复制底层数组。
   • 场景：
     • 读多写少的监听器列表（如事件通知系统）；
     • 白名单/黑名单等低频更新的数据存储。

3. ConcurrentLinkedQueue

   • 功能：基于链表的无界线程安全队列，通过CAS实现非阻塞算法。
   • 场景：
     • 生产者-消费者模式（如异步任务队列）；
     • 高吞吐量的日志处理。

4. BlockingQueue（如LinkedBlockingQueue、ArrayBlockingQueue）

   • 功能：支持阻塞操作的队列，提供put()和take()方法。
   • 场景：
     • 任务缓冲池（如线程池任务队列）；
     • 流量控制（如限制请求处理速率）。

19.2 同步工具类

1. CountDownLatch

   • 功能：计数器同步工具，等待其他线程完成任务后继续执行。
   • 场景：
     • 启动前等待多个服务初始化完成；
     • 并行计算后汇总结果。

2. CyclicBarrier

   • 功能：可循环使用的栅栏，线程在指定屏障点同步等待。
   • 场景：
     • 多阶段任务（如分布式计算分阶段提交）；
     • 游戏关卡同步（所有玩家到达检查点后继续）。

3. Semaphore

   • 功能：信号量，控制资源访问的并发数。
   • 场景：
     • 限流（如数据库连接池）；
     • 文件IO并发控制（限制同时操作的文件数）。

4. Exchanger

   • 功能：线程间交换数据的同步点。
   • 场景：
     • 双线程协作（如数据清洗与存储线程交替工作）；
     • 管道式处理（流水线作业中传递中间结果）。

19.3 线程池与执行框架

1. ExecutorService（如ThreadPoolExecutor）

   • 功能：管理线程生命周期，支持任务提交、执行和结果获取。
   • 场景：
     • Web服务请求处理（固定线程池避免资源耗尽）；
     • 批量数据处理（通过线程池提升处理效率）。

2. ScheduledExecutorService

   • 功能：支持定时或周期性任务调度。
   • 场景：
     • 心跳检测（如每5秒发送心跳包）；
     • 定时数据拉取（如每日凌晨同步日志）。

19.4 原子变量与锁

1. 原子类（AtomicInteger、AtomicReference等）

   • 功能：基于CAS实现无锁线程安全操作。
   • 场景：
     • 计数器（如统计在线用户数）；
     • 状态标记（如开关切换）。

2. ReentrantLock与ReentrantReadWriteLock

   • 功能：显式锁，支持公平锁、可中断锁和条件变量。
   • 场景：
     • 复杂同步逻辑（如数据库事务顺序控制）；
     • 缓存系统读写分离（读多写少场景）。

19.5 其他实用工具

1. CompletableFuture

   • 功能：异步编程工具，支持链式调用和组合任务。
   • 场景：
     • 多服务聚合调用（如并行调用多个API后合并结果）；
     • 回调式任务编排（如订单支付成功后发送通知）。

2. Phaser

   • 功能：灵活的分阶段同步器，支持动态注册线程。
   • 场景：
     • 分批次任务处理（如批量文件分阶段压缩上传）；
     • 动态调整线程协作阶段（如游戏副本进度同步）。

总结与选型建议

注意：以上类的选择需结合实际并发压力和数据一致性要求。例如，频繁写操作的场景应避免使用CopyOnWrite集合（内存开销大），优先选择ConcurrentHashMap。

20、Java 8 死锁产生原因与避免方法详解

20.1 死锁的产生原因

在 Java 8 中，死锁的产生仍遵循 四个必要条件：

1. 互斥条件：资源（如锁）一次只能被一个线程持有。
2. 持有并等待：线程持有至少一个资源，同时等待其他线程释放其他资源。
3. 不可抢占：资源只能由持有它的线程主动释放，无法被强制剥夺。
4. 循环等待：多个线程形成环形等待链，如线程 A 等待线程 B 的资源，线程 B 又等待线程 A 的资源。

典型代码示例（Java 8 中的死锁场景）：

public class DeadlockExample {
    private static final Object lockA = new Object();
    private static final Object lockB = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (lockA) {
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (lockB) {} // 等待 lockB
            }
        }).start();

        new Thread(() -> {
            synchronized (lockB) {
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (lockA) {} // 等待 lockA
            }
        }).start();
    }
}

结果：两个线程互相等待对方释放锁，导致程序无限阻塞。

20.2 避免死锁的五大策略

针对上述条件，Java 8 提供以下方法避免死锁：

1. 固定锁的获取顺序

   • 原理：破坏循环等待条件，强制所有线程按全局一致顺序获取锁（如按对象哈希值排序）。
   • 示例：

     public void doWork() {
         Object firstLock = (lockA.hashCode() < lockB.hashCode()) ? lockA : lockB;
         Object secondLock = (firstLock == lockA) ? lockB : lockA;
         synchronized (firstLock) {
             synchronized (secondLock) {} // 确保顺序一致
         }
     }
     

2. 使用超时机制（TryLock）

   • 原理：通过 ReentrantLock.tryLock() 设置超时时间，若获取失败则释放已持有的锁，避免无限等待。
   • 示例：

     Lock lock1 = new ReentrantLock();
     Lock lock2 = new ReentrantLock();
     if (lock1.tryLock(1, TimeUnit.SECONDS)) {
         try {
             if (lock2.tryLock(1, TimeUnit.SECONDS)) {
                 // 成功获取两个锁
             } else {
                 lock1.unlock(); // 释放已持有的锁
             }
         } finally { /* 清理逻辑 */ }
     }
     

3. 减少锁的持有时间与范围

   • 原理：缩小同步代码块范围，尽早释放锁资源，降低竞争概率。
   • 示例：优先使用 synchronized 块而非同步方法。

4. 使用并发工具替代显式锁

   • 原理：利用 java.util.concurrent 包中的线程安全容器（如 ConcurrentHashMap）或工具类（如 Semaphore），减少手动锁管理的复杂度。
   • 适用场景：高并发计数器、任务队列等。

5. 死锁检测与恢复

   • 检测工具：
     • jstack：通过 jstack <PID> 分析线程堆栈，定位死锁线程。
     • JConsole/VisualVM：图形化工具监控线程状态并检测死锁。
   • 恢复策略：若检测到死锁，可终止部分线程或强制释放资源（需谨慎设计）。

20.3 Java 8 中的优化与注意事项

1. 无锁编程：使用原子类（如 AtomicInteger）替代锁，基于 CAS 实现线程安全操作。
2. 函数式并发：结合 CompletableFuture 和 Stream API 简化异步任务编排，降低锁依赖。
3. 避免嵌套锁：尽量不在一个锁的作用域内获取另一个锁，必要时使用锁合并或锁分解。

总结

在 Java 8 中，死锁的产生与避免机制与早期版本一致，核心在于破坏四个必要条件。通过 固定锁顺序、超时机制、并发工具 和 无锁设计 等策略，可有效规避死锁问题。实际开发中，建议结合工具检测（如 jstack）与代码规范（如减少锁粒度）提升程序的健壮性。

21、Java 线程的生命周期状态详解

Java 线程的生命周期描述了线程从创建到销毁的完整过程，其状态由 java.lang.Thread.State 枚举类明确定义。根据 JDK 1.5 及之后的版本，线程的生命周期包含 6 种核心状态，以下是详细说明及状态转换逻辑：

21.1 新建状态（NEW）

• 定义：线程对象通过 new Thread() 创建后，但尚未调用 start() 方法启动。
• 特点：
  • 线程实例已分配内存，但未与操作系统线程关联。
  • 仅能调用 start() 方法启动线程，其他操作会抛出异常。

21.2 可运行状态（RUNNABLE）

• 定义：调用 start() 方法后，线程进入可运行状态，等待线程调度器分配 CPU 时间片。
• 子状态：
  • 就绪（Ready）：线程在队列中等待 CPU 资源。
  • 运行中（Running）：线程正在执行 run() 方法代码。
• 触发条件：
  • 调用 start() 方法。
  • 从阻塞/等待状态被唤醒（如锁释放、notify() 调用）。

21.3 阻塞状态（BLOCKED）

• 定义：线程因竞争同步锁失败而暂停执行。
• 触发条件：
  • 尝试进入 synchronized 代码块，但锁已被其他线程持有。
• 退出条件：锁被释放后，线程重新进入 RUNNABLE 状态。

21.4 等待状态（WAITING）

• 定义：线程无限期等待其他线程的显式唤醒操作。
• 触发条件：
  • 调用 Object.wait()（无超时参数）。
  • 调用 Thread.join()（无超时参数）。
• 退出条件：其他线程调用 notify()/notifyAll() 或目标线程终止。

21.5 计时等待状态（TIMED_WAITING）

• 定义：线程在指定时间内等待条件达成。
• 触发条件：
  • 调用 Thread.sleep(long millis)。
  • 调用 Object.wait(long timeout) 或 Thread.join(long millis)。
• 退出条件：超时结束或收到唤醒信号。

21.6 终止状态（TERMINATED）

• 定义：线程执行完毕或异常终止。
• 触发条件：
  • run() 方法正常执行完成。
  • 未捕获的异常导致线程终止。
  • 显式调用已弃用的 stop() 方法（不推荐）。

状态转换图与逻辑

以下是线程状态转换的典型路径：

        +----------------+     start()      +-----------------+
        |      NEW        | --------------->|    RUNNABLE      |
        +----------------+                  +-----------------+
                    |                              |
                    |          获取锁失败           | sleep()/wait()
                    +---------------------------> BLOCKED
                    |                              |
                    |          锁释放               +-----------------+
                    +---------------------------> RUNNABLE
                    |                              |
                    |          调用 wait()          | wait(timeout)
                    +---------------------------> WAITING/TIMED_WAITING
                    |                              |
                    |          notify()/超时        +-----------------+
                    +---------------------------> RUNNABLE
                    |                              |
                    |          run()结束/异常        |
                    +---------------------------> TERMINATED

关键注意事项

1. RUNNABLE 包含就绪与运行中：Java API 层面不区分这两种状态，由操作系统调度决定。
2. 避免过时方法：如 stop()、suspend() 和 resume()，这些方法易导致死锁和数据不一致。
3. 锁与资源竞争：合理使用 synchronized 或 Lock 接口管理同步，避免长时间阻塞。

22、http协议，在设计http接口得时候需要考虑什么问题？

通过理解线程状态及其转换逻辑，开发者可以更高效地设计并发程序，优化资源利用并规避潜在问题。

在设计HTTP接口时，需综合考虑协议规范、安全性、性能、可维护性等多个维度，以下是要点总结：

22.1 协议与规范设计

1. RESTful设计原则

   • 资源为核心：URL使用名词（如/users而非/getUsers），通过HTTP方法（GET/POST/PUT/DELETE）表达操作意图。
   • 版本控制：在URL或请求头（如Accept: application/vnd.api.v1+json）中明确API版本，例如/v1/users。
   • 状态码规范：使用标准HTTP状态码（如200成功、400客户端错误、401未授权）告知请求结果。

2. URL与参数设计

   • 路径规则：使用小写字母和连字符（如/user-profiles），避免文件扩展名。
   • 分页与过滤：通过Range头或page/limit参数支持大数据集分页，减少单次响应体积。

22.2 安全性设计

1. 传输安全

   • 强制HTTPS：防止中间人攻击，确保数据加密传输。
   • 身份认证：采用Token（如JWT）、OAuth 2.0或API Key机制验证调用方身份。

2. 防篡改与防重放

   • 参数签名：通过时间戳（timestamp）和签名（sign）验证请求合法性，防止数据篡改。
   • 限流与防刷：基于IP或用户维度限制接口调用频率，例如使用令牌桶算法。

3. 敏感数据保护

   • 数据脱敏：返回的敏感字段（如手机号）部分替换为星号。
   • 加密存储：密码等敏感信息使用非对称加密（如RSA）或哈希算法（如SHA-256）处理。

22.3 性能优化

1. 协议与传输优化

   • HTTP/2或HTTP/3：利用多路复用、头部压缩等特性提升传输效率。
   • 数据压缩：启用Gzip/Brotli压缩响应体，减少网络传输量。

2. 缓存策略

   • 客户端缓存：通过Cache-Control和ETag头实现资源缓存验证。
   • 服务端缓存：对热点数据使用Redis或Memcached缓存查询结果。

3. 异步处理与并行化

   • 非核心逻辑异步化：如日志记录、消息通知通过消息队列（如Kafka）异步处理。
   • 并行请求：拆分大接口为多个子接口，前端并行调用。

22.4 数据与错误处理

1. 数据格式与结构

   • 统一数据格式：响应体采用JSON，包含code（状态码）、message（描述）、data（业务数据）。
   • 时间标准化：时间字段使用UTC时区及ISO8601格式（如2025-03-30T12:00:00Z）。

2. 错误处理与日志

   • 明确错误信息：返回可读的错误描述及解决建议（如{"code": 4001, "message": "Invalid token"}）。
   • 请求追踪：通过Request-Id头实现全链路日志跟踪。

22.5 可维护性与扩展性

1. 单一职责原则

   • 每个接口聚焦单一功能（如GET /users仅获取用户列表，不混入权限校验逻辑）。

2. 兼容性设计

   • 版本迭代兼容：通过Deprecation头标记旧版本，逐步迁移而非强制升级。
   • 参数扩展性：预留扩展字段（如extra_params）以适应未来需求。

3. 文档与测试

   • 自动化文档：使用Swagger/OpenAPI生成交互式文档，包含请求示例、参数说明。
   • Mock测试：提供模拟接口响应，方便前端并行开发。

总结

设计高效、安全的HTTP接口需平衡规范性与灵活性。核心原则包括：遵循RESTful规范、强制安全措施、优化传输性能、清晰的数据与错误处理，以及完善的文档支持。实际开发中可结合具体业务场景选择优先级，例如高并发场景侧重缓存和异步化，金融类接口强化签名与加密。

23、HTTP 各个 Method 的语义与核心特性

HTTP 方法（Method）是客户端与服务器交互的“动作指令”，定义了资源操作的核心语义。以下是主要方法的语义、幂等性、安全性及适用场景的总结：

1. GET

• 语义：获取指定资源（如查询数据、读取文件）。
• 幂等性：是（多次请求结果一致）。
• 安全性：是（不修改服务器资源）。
• 参数传递：通过 URL 查询字符串（如 ?id=123），长度受限且明文可见。
• 典型场景：
  • 加载网页内容或 API 数据（如 GET /users 获取用户列表）。
  • 搜索查询（参数通过 URL 传递，需注意敏感信息泄露风险）。

2. POST

• 语义：创建新资源或触发非幂等操作（如提交表单、执行支付）。
• 幂等性：否（重复提交可能产生多个资源）。
• 安全性：否（可能修改服务器状态）。
• 参数传递：请求体（支持 JSON、表单、文件等），无长度限制。
• 典型场景：
  • 用户注册（POST /register 创建新用户）。
  • 文件上传或复杂数据处理（如订单提交后触发库存扣减）。

3. PUT

• 语义：全量更新资源（替换现有数据）。
• 幂等性：是（多次更新结果与一次更新一致）。
• 安全性：否（修改资源）。
• 参数传递：请求体需包含完整资源字段（如 PUT /users/1 更新用户所有信息）。
• 典型场景：
  • 替换用户资料（如修改全部个人信息）。
  • 同步客户端与服务器数据（强制覆盖）。

4. DELETE

• 语义：删除指定资源。
• 幂等性：是（无论资源是否存在，结果一致）。
• 安全性：否（修改资源）。
• 参数传递：通过 URL 路径标识资源（如 DELETE /orders/456）。
• 典型场景：
  • 删除用户账户或订单记录。
  • 清理临时文件或过期数据。

5. PATCH

• 语义：部分更新资源（仅修改指定字段）。
• 幂等性：取决于实现（通常设计为幂等）。
• 安全性：否（修改资源）。
• 参数传递：请求体仅包含需修改的字段（如 PATCH /users/1 仅更新手机号）。
• 典型场景：
  • 局部调整（如修改用户头像或订单状态）。
  • 修复数据错误（避免全量覆盖的开销）。

6. HEAD

• 语义：获取资源的元信息（响应头），不返回响应体。
• 幂等性：是。
• 安全性：是。
• 典型场景：
  • 检查资源是否存在或更新（如验证文件最后修改时间）。
  • 预加载资源元数据（节省带宽）。

7. OPTIONS

• 语义：查询服务器对资源的支持方法（跨域请求时自动触发）。
• 幂等性：是。
• 安全性：是。
• 典型场景：
  • CORS 预检请求（返回 Access-Control-Allow-Methods 头）。
  • 调试接口能力（如确认服务器是否支持 PUT/DELETE）。

8. 其他方法

• CONNECT：建立隧道（如 HTTPS 代理通信）。
• TRACE：回显请求消息（用于诊断，但存在安全风险，通常禁用）。

核心特性总结

设计建议

1. 遵循 RESTful 规范：GET 用于读，POST 用于写，PUT/DELETE 用于更新/删除。
2. 幂等性设计：确保 PUT、DELETE 等方法的重复请求不会产生副作用。
3. 安全性控制：敏感操作（如 DELETE）需结合鉴权（如 Token、OAuth）。

通过合理选择方法，可提升接口可读性、安全性和维护性。例如，优先用 PATCH 而非 PUT 实现局部更新，减少网络传输开销。

24、HTTP/2 核心特性与优化解析

HTTP/2 是 HTTP/1.1 的重大升级，专注于提升传输效率和性能。以下是其核心特性、技术原理及实践建议的详细分析：

24.1 核心特性与改进

1. 二进制分帧传输

   • 特性：将 HTTP 报文拆分为更小的二进制帧（Frame），取代 HTTP/1.1 的明文传输。帧类型包括数据帧（DATA）、头帧（HEADERS）等，每个帧包含流标识符（Stream ID），支持乱序传输和重组 。
   • 优势：解析效率更高，减少冗余字符（如换行符）的传输开销，错误率更低。

2. 多路复用（Multiplexing）

   • 原理：单个 TCP 连接上并发处理多个请求和响应，通过流标识符区分不同请求，彻底解决 HTTP/1.1 的队头阻塞（Head-of-Line Blocking）问题 。
   • 性能提升：减少 TCP 连接数（HTTP/1.1 通常需要 6-8 个连接），降低延迟和资源消耗。例如，加载包含多个资源的页面时，所有请求可通过一个连接完成 。

3. 头部压缩（HPACK 算法）

   • 机制：通过静态字典（预定义常见头部字段）、动态字典（动态维护新增字段）和霍夫曼编码（Huffman Coding）压缩头部，减少 50% 以上的头部体积 。
   • 场景：高频请求（如携带相同 Cookie 的请求）可显著节省带宽。

4. 服务器推送（Server Push）

   • 功能：服务器主动向客户端推送资源（如 CSS、JS 文件），无需等待客户端解析 HTML 后再发起请求 。
   • 示例：请求 index.html 时，服务器可同时推送 style.css 和 script.js，减少往返延迟。

24.2 与 HTTP/1.1 的关键差异

24.3 实际应用建议

1. 启用 HTTPS

   • 主流浏览器（Chrome、Firefox 等）仅支持基于 TLS 的 HTTP/2（h2），非加密版本（h2c）已被废弃 。
   • 操作：配置服务器 SSL 证书，并在 Nginx/Apache 中开启 HTTP/2 支持（如 Nginx 的 listen 443 ssl http2）。

2. 性能优化场景

   • 高并发请求：如电商页面加载（多图片、脚本），HTTP/2 可减少连接数并提升加载速度 。
   • 移动端应用：低带宽环境下，头部压缩和多路复用能显著改善用户体验。

3. 兼容性处理

   • 降级策略：若客户端不支持 HTTP/2，服务器自动回退至 HTTP/1.1 。
   • 测试工具：使用 curl --http2 或浏览器开发者工具验证协议版本 。

24.4 局限性及注意事项

• TCP 层队头阻塞：HTTP/2 解决了应用层阻塞，但 TCP 丢包重传仍可能导致整体延迟（此问题在 HTTP/3 中通过 QUIC 协议解决）。
• 服务器推送的合理使用：过度推送可能浪费带宽，需结合资源优先级和实际需求动态调整 。
• 性能瓶颈：若网站请求数少或网络延迟高，HTTP/2 的优势可能不明显 。

总结

HTTP/2 通过二进制分帧、多路复用、头部压缩和服务器推送等机制，显著提升了 Web 传输效率，尤其适用于高并发、多资源的场景。实际部署时需结合 HTTPS 配置、服务器优化及客户端兼容性策略，最大化其性能优势。对于更极致的延迟优化，可关注下一代协议 HTTP/3 的 QUIC 实现 。

25、HTTP 状态码分类与核心含义

HTTP 状态码是服务器对请求处理结果的标准化响应标识，通过三位数字代码和原因短语传递信息。以下是主要分类及常见状态码的解析：

25.1 信息性响应（1xx）

表示请求已接收，需客户端继续操作或等待：

• 100 Continue：服务器已接收请求头，客户端应继续发送请求体（适用于大文件上传前的验证）。
• 101 Switching Protocols：服务器同意切换协议（如从 HTTP 升级到 WebSocket）。
• 102 Processing：请求已被接收，但处理仍在进行（常见于 WebDAV 扩展场景）。
• 103 Early Hints：服务器提前返回部分响应头，提示客户端预加载资源（优化页面渲染速度）。

25.2 成功响应（2xx）

表示请求已被正确处理：

• 200 OK：请求成功，响应体中包含目标资源（如网页、JSON 数据）。
• 201 Created：资源创建成功（如通过 POST 新增用户，响应头中返回 Location 字段）。
• 202 Accepted：请求已被接受但未完成处理（适用于异步任务，如批量数据处理）。
• 204 No Content：请求成功但无返回内容（常用于 DELETE 请求或表单提交后的无刷新操作）。
• 206 Partial Content：服务器返回部分内容（支持断点续传或视频分段加载）。

25.3 重定向（3xx）

表示资源位置变化，需客户端调整请求路径：

• 301 Moved Permanently：资源永久迁移（客户端应更新书签或缓存）。
• 302 Found：资源临时移动（客户端下次仍需请求原地址）。
• 304 Not Modified：资源未修改，客户端可复用本地缓存（通过 If-Modified-Since 头验证）。
• 307 Temporary Redirect：临时重定向，要求客户端保持原请求方法（如 POST 请求转发）。
• 308 Permanent Redirect：永久重定向，且强制保持原请求方法（防止 POST 被转为 GET）。

25.4 客户端错误（4xx）

表示请求存在语法或权限问题：

• 400 Bad Request：请求格式错误（如参数缺失或 JSON 解析失败）。
• 401 Unauthorized：未提供有效身份凭证（需通过 WWW-Authenticate 头提示认证方式）。
• 403 Forbidden：服务器拒绝执行请求（如权限不足或 IP 被封禁）。
• 404 Not Found：资源不存在（需检查 URL 或路由配置）。
• 409 Conflict：请求与资源状态冲突（如并发修改同一数据时的版本冲突）。

25.5 服务器错误（5xx）

表示服务器处理请求时发生内部故障：

• 500 Internal Server Error：服务器内部异常（如代码逻辑错误或数据库连接失败）。
• 501 Not Implemented：服务器不支持请求方法（如未实现的 PATCH 接口）。
• 502 Bad Gateway：网关或代理服务器从上游收到无效响应（如反向代理后的服务崩溃）。
• 503 Service Unavailable：服务暂时不可用（常见于服务器维护或过载限流）。
• 504 Gateway Timeout：网关等待上游响应超时（如依赖的 API 服务响应缓慢）。

总结

HTTP 状态码通过简洁的代码快速定位问题类型，例如：

• 开发调试：4xx 错误多与客户端输入相关，需检查请求参数和权限；5xx 错误需排查服务端日志。
• 用户体验优化：合理使用 304 缓存和 206 分段加载可提升页面性能。
• API 设计：规范返回状态码（如 201 替代 200 表示资源创建），增强接口可读性。

更多详细状态码可参考 RFC 7231 或 HTTP 官方文档。

26、如何理解 Java 内存模型（JMM）及内存可见性？

26.1 Java 内存模型（JMM）的核心定义与作用

Java 内存模型（JMM）是 Java 多线程编程的核心抽象规范，它定义了线程与主内存之间的交互规则，确保在多核、多线程环境下程序的正确性。JMM 的主要目标是解决以下问题：

• 主内存与工作内存的隔离：所有变量存储在主内存（共享区域），每个线程拥有独立的工作内存（本地缓存），线程只能通过操作工作内存中的变量副本来间接访问主内存。
• 内存可见性：当一个线程修改共享变量时，其他线程是否能及时感知到这一变化。
• 指令重排序：编译器和处理器可能对指令进行优化重排，但需保证单线程执行结果的正确性，同时避免多线程环境下的逻辑错误。

26.2 内存可见性问题的根源

内存可见性问题源于现代计算机的硬件架构特性：

• 多级缓存不一致：CPU 的每个核心都有自己的缓存，线程修改共享变量时可能仅更新本地缓存，未及时同步到主内存。
• 指令重排序：编译器和处理器为提高性能可能重新排列指令顺序，导致线程间操作顺序不一致。

例如，以下代码可能因可见性问题导致逻辑错误：

// 线程 A
sharedFlag = true;  // 修改共享变量，但未及时同步到主内存

// 线程 B
if (sharedFlag) {   // 可能读取到旧值
    // 执行操作
}

26.3 JMM 如何保证内存可见性

JMM 通过以下机制解决可见性问题：

• volatile 关键字：

  • 强制变量的读写直接操作主内存，绕过工作内存。
  • 插入内存屏障（Memory Barrier），禁止指令重排序，确保修改对其他线程立即可见。
  • 示例：volatile boolean flag = false;。

• 锁机制（如 synchronized）：

  • 线程进入同步块前清空工作内存，强制从主内存重新加载变量。
  • 退出同步块时将变量刷新回主内存，保证修改对其他线程可见。

• final 关键字：

  • 保证对象初始化完成后对其他线程可见（通过禁止构造函数重排序）。

26.4 有序性与 happens-before 原则

JMM 通过 happens-before 规则 定义操作间的顺序约束，确保多线程环境下的逻辑正确性：

1. 程序顺序规则：单线程中代码顺序决定操作顺序。
2. 锁规则：解锁操作先于后续加锁操作。
3. volatile 规则：写操作先于后续读操作。
4. 传递性规则：若 A 先于 B，B 先于 C，则 A 先于 C。
5. 线程启动规则：Thread.start() 先于线程内的任何操作。

例如：

// 线程 A
synchronized (lock) {
    x = 1;  // 写操作
}

// 线程 B
synchronized (lock) {
    if (x == 1) {  // 读操作
        // 保证看到 x=1
    }
}

26.5 实际开发中的应用建议

• 优先使用 volatile：适用于状态标记（如开关标志），无需锁的高效可见性保证。
• 同步代码块：复杂操作（如计数器自增）需通过 synchronized 或原子类（AtomicInteger）保证原子性和可见性。
• 避免过度依赖硬件特性：JMM 屏蔽了底层差异，但需遵循其规范，避免因平台优化导致意外行为。

26.6 总结

Java 内存模型通过 主内存-工作内存的抽象、内存屏障 和 happens-before 规则，在多线程环境下实现了内存可见性和操作有序性。理解 JMM 是编写高效、安全并发程序的基础，开发者需结合 volatile、锁机制和原子类等工具，规避缓存不一致和指令重排序带来的风险。