斗锋在干嘛的博客

A：Android的UI toolkit不是线程安全的，直接跨线程修改可能导致界面状态不一致。生命周期：主线程Looper伴随应用存在，其他线程Looper可随时退出。创建方式：主线程Looper由系统自动创建，其他线程需手动调用。消息优先级：主线程的消息队列包含系统级高优先级消息。Android应用启动时，系统会为主线程创建。方法强制检查，非主线程操作会抛出。创建主线程Handler发送消息。获取当前线程的Looper。方法初始化主线程消息队列。获取主线程Looper。避免在循环中频繁检查。

"对于简单场景，可以使用Thread.join()强制等待，或使用单线程线程池自动维护任务队列"："在Java19+环境中，虚拟线程提供了更轻量级的解决方案，适合高并发场景"："现代Java已经通过虚拟线程原生支持协程，这是未来高并发应用的重要方向"："线程适合CPU密集型任务，协程更适合IO密集型高并发场景"："协程在用户态调度，切换速度比线程快100倍以上"："协程的内存开销是KB级，而传统线程需要MB级"切换成本：协程（纳秒级）vs 线程（微秒级）调度方式：协程（用户态）vs 线程（内核态）

sleep()是可中断的，当线程在休眠期间收到中断信号时，会立即抛出。与wait()不同，sleep()被中断时不会释放已持有的锁；这种设计使得sleep()适合实现可取消的延迟任务。：sleep()方法是否可中断？返回false），因此通常需要在catch块中调用。：通过操作系统级的中断信号（如POSIX的。：当线程在休眠期间被中断时，会立即抛出。上层代码可能需要根据中断状态做处理。中断后会清除线程的中断状态（标志位，被清除后需手动恢复。遵循"不可屏蔽中断"原则。

只是向调度器提示愿意让出CPU，但调度器可能忽略该提示（尤其在高负载时）。会释放锁，而释放锁的前提是线程必须先持有锁（通过。释放当前对象锁（允许其他线程进入同步块）更安全，保证所有等待线程都有机会执行；仅作提示，不保证线程调度器一定采纳。的方法，不释放锁，时间到自动唤醒；适合优化CPU占用，但效果不确定。适合避免长时间占用CPU的场景。的情况下被唤醒（底层OS原因）效率更高，但可能导致线程饥饿；在同步代码块中调用（否则抛。：确保被唤醒后条件确实满足。的方法，会释放锁，必须通过。

A："守护线程是JVM的后台服务线程（如GC线程），它的生命周期依赖于用户线程——当所有用户线程结束时，即使守护线程还在运行，JVM也会退出。A："当JVM因所有用户线程结束而退出时，会直接终止所有守护线程，此时守护线程中的finally代码块可能来不及执行。绝对避免使用已被废弃的stop()/suspend()方法，它们会导致对象状态不一致或死锁。当所有非守护线程结束时，JVM会自动退出，：服务于用户线程，生命周期随JVM退出而结束。：JVM退出时可能直接终止守护线程。：让run()方法执行完毕。

底层原生线程绑定关系：一个Java Thread对象对应一个系统线程；：需要重新执行任务时，应创建新Thread实例或使用线程池。：线程可以多次调用start()吗？如需重新执行，应创建新线程而非复用旧线程。：线程执行完毕即销毁（类似一次性餐具）设计上线程生命周期不可逆；，再次调用时检查失败。无法通过任何API将。线程状态机限制：只有。状态的线程允许启动；

当多个线程同时操作同一个对象时，主要面临三大问题：问题分析：实际包含三步操作多线程执行可能丢失更新字节码证明：(2) 对象状态不一致竞态条件：检查余额与扣款操作不是原子的，可能导致超额支出特点：简单易用JVM自动管理锁获取/释放支持可重入优势：可中断锁获取超时机制公平锁选项性能对比：低竞争：原子类 > 锁高竞争：锁 > 原子类（避免大量CAS重试）适用场景：频繁读操作状态变更不频繁示例：ConcurrentHashMap使用5. 内存可见性保障(1)

A：防止ThreadLocal对象被强引用导致无法回收，而Value是强引用需手动remove清理。是 Java 提供的线程本地变量机制，它为每个线程创建一个独立的变量副本，A：通过为每个线程创建独立变量副本，从根本上避免共享资源竞争，无需加锁。A：采用开放寻址法（线性探测），不同于HashMap的链表法。：与线程绑定（线程终止时自动清理）：上下文传递、线程私有对象管理。：每个线程只能访问自己的副本。：线程隔离数据，无锁线程安全。：天然线程安全，无需同步。✅ 正确做法：使用后调用。（Netty优化版）

分粗粒度锁和细粒度锁（如ConcurrentHashMap分段锁）；分乐观锁（如CAS）和悲观锁（如synchronized）；支持锁升级（偏向锁→轻量级锁→重量级锁）非公平锁：吞吐量高约10%，但可能饥饿。：线程循环尝试获取锁（避免上下文切换）：在对象头记录线程ID，避免CAS操作。支持公平/非公平、可中断、超时等特性。公平锁：减少饥饿，但上下文切换多。分独占锁和共享锁（如读写锁）。：用CAS替换操作系统互斥锁。乐观读锁+写锁混合模式。悲观锁：直接加锁（如。：获取失败时线程进入。分公平锁和非公平锁；

是指两个或多个线程在执行过程中，因争夺资源而造成的一种互相等待的现象，导致所有线程都无法继续执行下去。"死锁的四个必要条件是互斥、占有等待、不可抢占和循环等待。实际项目中，我会优先评估锁的必要性，尽量用无锁方案，必要时采用锁顺序+超时策略。：必须同时满足这四个条件才会发生死锁，破坏任意一个即可避免死锁。：已分配给线程的资源不能被强行剥夺，必须由线程自行释放。：线程持有至少一个资源，并等待获取其他资源。：多个线程形成头尾相接的等待资源关系。：锁顺序固定、超时机制、死锁检测。：代码审查时注意锁的嵌套和顺序。

禁止 JVM 和 CPU 对指令重排序。，仅通过内存屏障保证可见性和有序性。适用于需要原子操作的场景。适用于状态标志等简单场景，而。（如计数器、共享资源访问）。还能保证原子性和互斥访问。不是原子的，因为它包含。，未获取锁的线程会进入。（如计数器、共享资源）。（如 DCL 单例）。，它仅适用于特定场景。

volatile的线程安全能力"volatile可以保证可见性和有序性，但不能保证复合操作的原子性，因此不能完全保证线程安全。它适用于状态标志等简单场景，但不适合计数器等需要原子性的场景。DCL中的关键作用"在双重检查锁定模式中，volatile主要解决指令重排序问题。它能确保Singleton实例完全初始化后才被其他线程看到，避免了获取到未初始化完成的对象的问题。实际效果。

AQS是Java并发包的核心基础框架，JUC中大多数同步器（如ReentrantLock、CountDownLatch等）都是基于它实现的。

同步器状态变更CLH队列中的节点状态管理。

在JDK1.6之后，Java团队对进行了多项重要优化，使其从"重量级锁"变成了可以根据竞争情况自动调整的高效同步机制。

可见性是指当一个线程修改了共享变量的值后，其他线程能够立即感知到这个修改的特性。CPU缓存不一致：各线程可能读取自己CPU缓存中的副本指令重排序：编译器和处理器优化可能导致代码执行顺序改变。

即使在单核CPU环境下，多线程编程仍然是提高系统吞吐量和响应性的重要手段，关键在于理解其适用场景和实现原理。：即使单核CPU，操作系统也会为每个线程分配时间片（通常10-100ms）：当一个线程因I/O操作阻塞时，CPU可以立即切换到另一个就绪线程执行。：例如GUI程序，一个线程处理UI事件，另一个线程执行后台计算。：在单线程模型中，任何阻塞操作都会导致CPU完全停止工作。：可以同时执行两个线程的指令（但共享执行单元）：CPU保存当前线程状态，加载下一个线程状态。：线程切换可能导致共享数据不一致。