jiaruchunBlog

想要确保消息能够精准到达 RabbitMQ，并且绝不掉链子？就像寄送包裹，确保邮局不出差错一样。要保障消息投递的可靠性，除了依赖 RabbitMQ 本身的稳定性外，还需要配置以下几个关键点： 消息确认机制：确保每条消息都经过确认，避免消息丢失。持久化：将消息存储在磁盘上，确保即使系统崩溃，消息也不会丢失。死信队列：当消息无法处理时，将其放入一个特定的队列中，以便稍后再处理。简单来说，就是做好**“投递保障”和“灾后恢复”**，确保即使在系统崩溃或网络异常时，消息也能顺利送达。 🎩 知识内容：确保消息能够精准无误地到达 RabbitMQ，是企业级消息系统设计中的一项关键要求。通过实现可靠的消息投递机制，我们可以确保即使在网络不稳定、服务宕机等情况下，消息仍然能够顺利到达消费者，避免“掉链子”。 🛠️ RabbitMQ 提供的保障机制消息持久化：默认情况下，RabbitMQ 中的消息是非持久化的，意味着一旦服务器崩溃，消息就会丢失。为了避免这种情况，可以将消息和队列设置为持久化（durable），确保即使 RabbitMQ 崩溃或重启，消息也能恢复。 队列持久化（Durable ...

Java 线程池有四种内置的拒绝策略，用来处理当任务太多，无法继续接受时的情况。每种策略的处理方式不同，帮助程序更灵活地应对任务积压。 这四种拒绝策略是：AbortPolicy（抛异常）：如果线程池无法接受新的任务，它会抛出一个错误，告诉你任务没有被处理。CallerRunsPolicy（调用者执行）：如果线程池满了，它会把任务交给发起任务的“调用者”来处理，而不是丢弃任务或报错。DiscardOldestPolicy（丢弃最旧任务）：线程池会丢弃掉队列里最早的任务，然后把新的任务加进来。就像是做队列管理，丢掉排在最前面的任务。DiscardPolicy（直接丢弃）：如果线程池满了，新的任务就会被直接丢弃，不做任何处理。自定义拒绝策略：如果这些内置的策略不符合你的需求，你还可以自己定义拒绝策略，来根据特定需求灵活处理任务。 总之，这些拒绝策略让你能够根据不同情况做出合适的反应，避免任务过多时程序崩溃或者不做处理。 🧠 知识内容1️⃣ AbortPolicy（默认策略）特点：直接抛出 RejectedExecutionException 异常。适用场景：必须明确通知调用者任务未被...

Java 线程池就像是一个高效的“打工人管理工具”💼。它提前创建了一些工人（也就是线程），然后根据实际需要分配给不同的任务。这样，程序就不需要每次都重新创建和销毁线程，节省了大量的时间和资源。 关键点：核心线程：线程池一开始就准备好了“基础工人”，随时可以派遣任务。最大线程数：如果任务特别多，线程池会派更多的“临时工”来帮忙，但最多也只能有这个数量的工人。任务队列：如果所有的工人都在忙，新的任务会排队等着被处理，不至于丢掉任务。拒绝策略：如果任务实在太多，超过了最大线程数和队列的容量，线程池会采取一定的策略来“拒绝”这些任务，比如直接放弃或者通知主程序。总之，线程池就是一个聪明的任务分配器，它通过一些规则管理工人的工作，避免了频繁创建工人的麻烦，提高了程序的效率。🌟 知识内容：🌟 线程池的关键配置：核心线程数（corePoolSize）：始终保持存活的线程数，就像公司的“固定员工”👨‍💻。最大线程数（maximumPoolSize）：线程池中允许的最大线程数，是“能招到的临时工”上限📈。空闲存活时间（keepAliveTime）：非核心线程在无任务时的存活时间，过期会...

synchronized 就是 Java 的“锁王”，它保证多个线程同时访问时，大家不会互相干扰，操作能井然有序。 它的工作原理是通过 JVM 的 “Monitor 锁” 和对象里的 “身份证”——Mark Word 来实现的，确保线程安全。 简单来说： 同一时间，只有拿到锁的线程才能执行操作，其他线程只能排队等着。通过这种方式，synchronized 确保了每次只有一个线程在进行操作，避免数据混乱或错误。总结：synchronized 就是 Java 中的“锁王”，它确保线程之间按顺序执行，不会互相干扰，保证了线程安全。 知识内容 synchronized 的实现原理synchronized 的底层实现依赖于 JVM 的 Monitor 机制 和 对象头 中的 Mark Word。 Monitor 机制：每个 Java 对象都可以关联一个 Monitor，它负责管理线程的互斥访问。当一个线程进入 synchronized 代码块时，它会尝试获取对象的 Monitor 锁。如果锁被其他线程持有，当前线程会被阻塞，直到锁被释放。🔒对象头和 Mark Word：每个 Java...

死锁是因为多个线程互相等待对方释放资源，导致谁也动不了。🛑 要避免死锁，可以破坏“互斥、占有且等待、不可抢占、循环等待”这四个条件中的一个。🔑 例如： 让资源共享 ✅一次性申请所有资源 ✅允许资源被抢占 ✅避免循环等待 ✅知识内容：🔍 死锁的四个必要条件： 互斥条件：每个资源只能被一个线程占用。占有和等待：线程在持有至少一个资源的同时，等待获取其他资源。不可抢占：线程所获得的资源在未使用完毕之前不能被其他线程抢占。循环等待：多个线程形成一种头尾相接的循环等待资源关系。🔍 避免死锁的方法： 按序申请资源：确保所有线程在获取多个锁时，按照相同的顺序获取锁。尽量减少锁的范围：将锁的粒度尽可能缩小，减少持有锁的时间。可以通过拆分锁或使用更细粒度的锁来实现。使用尝试锁机制：使用 ReentrantLock 的 tryLock 方法，尝试在一段时间内获取锁，如果无法获取，则可以选择放弃或采取其他措施，避免死锁。设置超时等待时间：为锁操作设置超时，防止线程无限期地等待锁。避免嵌套锁：尽量避免在一个锁的代码块中再次尝试获取另一个锁。🎉 代码演示： public class Deadlo...

简单说就是，ThreadLocal 的 key 用的是“弱引用”，这样如果它没用了，垃圾回收器可以及时把它清理掉，不会让它赖在内存里白白占地方，从而避免资源浪费。 🗑️💡 🧠 知识内容🚀 1. 设计原因如果 ThreadLocalMap 的键使用 强引用，会产生以下问题： 🧵 线程池问题：线程池中的线程通常会长时间存在，而 ThreadLocal 的生命周期较短。如果使用强引用，ThreadLocal 即使不再使用，仍然无法被回收。 📈 引用链：强引用会导致以下链条无法断开： Thread -> ThreadLocalMap -> Entry (key: ThreadLocal, value)即使 ThreadLocal 对象没有被使用，它仍然因为强引用的存在无法被回收，从而浪费内存资源。 解决方案： 使用 弱引用！弱引用的特性是，当垃圾回收器发现没有其他强引用指向 ThreadLocal 对象时，会将其回收，从而断开引用链，避免内存泄漏。🔗 2. 弱引用的引用链当 ThreadLocal 对象不再被强引用时，以下情况发生： 🔄 GC 自动回收：弱引用...

虽然 ThreadLocal 非常方便，但它也有一些缺点，特别是在某些情况下，可能会带来以下几个问题： 内存泄漏问题 💧如果使用 ThreadLocal 的时候没有及时清理线程中的数据，它可能会导致 内存泄漏。这就好比你在某个地方放了很多私人物品，但没有在离开时把它们收拾好。这样，东西就会积累在那儿，占用空间，最后导致资源浪费。 Hash 冲突效率低 🏃ThreadLocal 依赖 哈希表 来存储每个线程的独立数据。当多个线程的数据在哈希表中发生冲突时，查找和存取数据的效率就会变低。这就像在一个很拥挤的商场里找东西，当人太多时，找到你要的东西会变得特别慢。 主动清理数据的性能开销较高 🔧由于 ThreadLocal 让每个线程都有自己的数据副本，这些副本可能会在使用完后一直存在，除非我们主动去清理它们。清理这些数据需要额外的处理，这会增加额外的 性能开销。就像你在办公室工作时，如果每次都要清理桌子，浪费了很多时间和精力。 所以，尽管 ThreadLocal 很方便，但在使用时需要特别注意这些潜在的缺点，尤其是在复杂或高并发的场景下。 知识内容 🧠 内存泄漏问题...

在 Java 中，创建多线程的方法有 5种：1️⃣ 实现 Runnable 接口2️⃣ 继承 Thread 类3️⃣ 结合 Callable 和 FutureTask4️⃣ 使用线程池（ExecutorService）5️⃣ 借助 CompletableFuture 这些方法各有优缺点，根据场景选择合适的方法才是王道！🧠 🧠 知识内容1️⃣ 实现 Runnable 接口 🏃‍♂️用 Runnable 写任务逻辑，就像写清单一样交给线程去执行。任务简单，场景轻量，用它准没错！👍 🛠️ 核心特点： 任务解耦：任务逻辑独立，线程只是跑腿的。轻量级：适合不需要返回值的任务。📋 示例代码： class MyRunnable implements Runnable {@Overridepublic void run() {System.out.println(“🏃 任务运行中：” + Thread.currentThread().getName());}} public class Main {public static void main(String[] args) {Th...

@Transactional 注解的本质就是 声明式事务管理，它的作用是帮我们 自动管理事务，不用自己手动写一堆 beginTransaction、commit、rollback 之类的代码。 Spring 利用 AOP（面向切面编程），在运行时 解析 @Transactional 里的事务配置，然后决定什么时候开启事务、什么时候提交、什么时候回滚。 📌 重点： @Transactional 让事务管理变得简单，不需要我们手写事务处理代码。事务控制交给 Spring 处理，代码更清晰，业务逻辑更专注。支持灵活配置，可以指定 事务的传播行为、隔离级别、回滚策略 等。简单来说，加上 @Transactional，Spring 就会在该方法执行时 自动开启一个事务，执行完成后 提交，如果中间遇到异常，就会 自动回滚，保证数据一致性！ 🚀 📚 知识内容1️⃣ 声明式事务的工作原理@Transactional 注解在 Spring 中属于声明式事务管理的一部分，它并不会直接进行事务的处理，而是通过 AOP（面向切面编程）实现事务增强。AOP 拦截器会在目标方法执行之前或之后，按照配置...

在 Spring AOP 中，默认使用两种代理方式来增强对象的功能： JDK 动态代理：这种方式适用于目标类实现了 接口 的情况。代理对象是通过接口来创建的，代理的工作是基于接口的。 CGLIB 动态代理：在 Spring Boot 2.x 版本中，默认使用这种方式。它是通过 继承 目标类来创建一个子类进行代理，适合那些 没有接口 的类。 简单来说，JDK 动态代理 依赖接口，而 CGLIB 动态代理 则通过类的继承来创建代理。 📚 知识内容🔍 JDK 动态代理JDK 动态代理的核心是 Java 的反射机制，它通过 java.lang.reflect.Proxy 类生成代理对象，代理对象必须实现目标对象的接口。JDK 动态代理代理接口中的方法，通过 InvocationHandler 的 invoke() 方法来处理增强逻辑。 工作原理： 代理接口：代理类和目标类必须实现同一个接口。代理创建：通过 Proxy.newProxyInstance() 动态生成代理类，并把目标类和增强逻辑传入。方法调用：当代理类调用目标方法时，InvocationHandler 的 invoke(...