聊一次线程池使用不当导致的生产故障-图文解析

最新推荐文章于 2024-07-28 19:41:52 发布
最新推荐文章于 2024-07-28 19:41:52 发布
阅读量954 收藏 27
点赞数 16
文章标签： java tomcat k8s 线程 线程池
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhaozhiqiang1981/article/details/140721610
版权

聊一次线程池使用不当导致的生产故障–图文解析

原文作者：货拉拉技术团队

原文链接：https://juejin.cn/post/7382121812434747418

1 抢救

交代了背景：交付的软件运行中出现了故障，报警机制被触发，通过飞书与报警电话通知了作者，一个标识为zone-2的异地机房中的“bfe-customer-application-query-svc”应用程序(其实就是部署后的一个应用名称的全称)出现了RT（响应时间Response Time）飙升，随后整个zone-2机房处于不可用状态。

响应时间：计算机对用户的输入或请求作出反应的时间。通常速度越快，用户体验越好。

2 诊断病因

原文与解析

原文：bfe-customer-application-query-svc 是近期上线的新应用，故障发生时每个 zone 仅有 2 个 Pod 节点；

解析：

每个机房只有两个pod节点，pod是什么？

通过上下文阅读可以了解，该系统运维采用了k8s(kubernetes)技术，k8s太过于庞大在这里不再做展开讲解，我们进需要知道以下概念即可：

图片来自：https://www.jianshu.com/p/04ef80b76b6a

在这里插入图片描述

1.容器：简单理解为就是一个虚拟机，我们开发好一个项目，部署到服务器中，服务器需要对该项目配置环境，如果对一个服务器部署多个项目，尤其是不同语言的项目以及使用多种不同版本中间件对其进行环境配置的时候，很容易造成环境污染，导致项目的环境配置失败，所以通过docker等技术，把开发好的项目以及项目依赖的相关的库，中间件等元素统一部署到一个容器中，容器和容器之间隔离，互不干扰，这样就可以在一个服务器中部署多个项目并且不会污染服务器环境了。

2.node: k8s中的node中文称作节点，一个node可以简单理解为就是一台物理机，一台服务器。k8s至少需要一个主节点以及多个工作节点。

3.pod:在一个Node中可以部署多个pod，在java领域中，每个pod通常包含一个微服务容器，但有时一个Pod中会包含多个容器，这些容器通常是紧密耦合的，必须一起工作。例如，一个微服务和它的辅助服务（如日志收集器）可以部署在同一个Pod中。这种方式主要用于需要共享资源或紧密协作的场景。

k8s的主要工作之一就是增加弹性，当用户请求量以及计算量特别大的时候，可以考虑通过replicas参数的设置来增加副本的数量，概念类似于网络游戏的多开。

原文中的"两个Pod"的意思就是，同一个应用有两个副本，k8s会有对应的组件负责副本间的负载均衡等操作，如果其中一个pod挂了，会自动进行重启，如果node挂了，其中的pod会被部署到其他node中去。

原文：故障发生的前一天晚上，刚刚进行了确认订单页面二次估价接口（以下称作 confirmEvaluate）的切流（50% → 100%），故障发生时，该接口的 QPS 是前一天同时段的约 2 倍，如图1；

img

切流：就是更换调用的接口，简单说就是，原来调用的接口A我们觉得太慢了，于是新开发了接口B，我们把原来访问A接口的流量切换到B接口，这个过程叫做切流，为了防止B接口本身刚开发出来不稳定，所以不会一下子把所有的流量都切到B接口，而是先切50%,发现没有任何问题后再一点点的增加比例，直到100%.

原文：初步判断，故障可能是 confirmEvaluate 依赖的一个下游接口（以下称作 getTagInfo）超时抖动引起的（RT 上涨到了 500ms，正常情况下 P95 在 10ms 左右，持续约 1s）；综合这些信息来看，Pod 节点数过少 + 切流导致流量增加 + 依赖耗时突发抖动，且最终通过扩容得以恢复，这叠满的 buff， 将故障原因指向了 “容量不足” 。

但这只能算是一种定性的判断，就好比说一个人突然倒地不醒是因为心脏的毛病，但心脏（心血管）的疾病很多，具体是哪一种呢？在计算机科学的语境中提到 “容量” 这个词，可能泛指各种资源，例如算力（CPU）、存储(Mem) 等硬件资源，也可能是工作线程、网络连接等软件资源，那么，这次故障究竟是哪个或哪些资源不足了呢？还需要更细致的分析，才能解答。

2.1 初步定位异常指征：tomcat 线程池处理能力饱和，任务排队

经过一系列的排除，最终发可能是线程出现了问题，项目中使用tomcat作为线程池，在监控中发现线程池已经达到最大值了。

img

img

为了更好的理解曲线变化的含义，我们需要认真分析一下 tomcat 线程池的扩容逻辑。

原文用了一定篇幅介绍了tomcat的线程池，这里做一下展开讲解

池化技术：常见的诸如对象池，连接池，线程池

对象池：用户每次请求会调用对应的方法，方法中会创建对象，频繁的创建,销毁/回收对象很耗费时间，所以就创建一个对象池，把对象以单例的形式存放在对象池中，每次需要该对象的时候直接拿来就用即可。比如java中的spring，当然，我们一般叫他bean容器。

连接池：连接数据库等中间件时，每次创建，销毁连接很耗费时间，所以提前创建一些连接对象存放在集合中，称作连接池。

线程池：原理同上。

原文中提到，tomcat线程池继承自ThreadPoolExecutor,这个ThreadPoolExecutor是Java自己的JUC包下的线程池：

详细解释以及具体使用Demo引用自该链接内容:

https://blog.csdn.net/qishiheyongshi/article/details/132155705

 public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {}

线程池创建的七大参数：
        1、corePoolSize：线程池核心线程数量，核心线程不会被回收，即使没有任务执行，也会保持空闲状态。如果线程池中的线程少于此数目，则在执行任务时创建。
        2、maximumPoolSize：当线程数量达到corePoolSize，且workQueue队列塞满任务了之后，继续创建线程，但不能超过 maximumPoolSize。
        3、keepAliveTime：超过corePoolSize之后的“临时线程”的存活时间。
        4、unit：keepAliveTime的单位。
        5、workQueue：当线程数超过corePoolSize时，新的任务会处在等待状态，并存在workQueue中
        6、threadFactory：创建线程的工厂类，通常我们会自定义一个threadFactory设置线程的名称，这样我们就可以知道线程是由哪个工厂类创建的，可以快速定位。
        7、handler：线程池执行拒绝策略，当线程数量达到maximumPoolSize大小，并且workQueue也已经塞满了任务的情况下，线程池会调用handler拒绝策略来处理请求。

原文：

实际上， tomcat线程池（org.apache.tomcat.util.threads.ThreadPoolExecutor）继承了java.util.concurrent.ThreadPoolExecutor，而且并没有重写线程池扩容的核心代码，而是复用了java.util.concurrent.ThreadPoolExecutor#execute方法中的实现，如图4。 其中，第4行～第23行的代码注释，已经将这段扩容逻辑解释的非常清晰。即每次执行新任务（Runnable command）时：

  1. Line 25 - 26：(当有任务到来时)首先判断当前池中工作线程数是否小于 corePoolSize(核心线程数量)，如果小于 corePoolSize (核心线程数量)则直接新增工作线程执行该任务；
  2. Line 30：否则，尝试将当前任务放入 workQueue(工作队列)中等待
  3. Line 37：如果第 30 行未能成功将任务放入 workQueue(工作队列)，即 workerQueue.offer(command) 返回 false，则继续尝试新增工作线程执行该任务（第 37 行）；

上面这一段原文相对比较好理解，直接读完即懂。

图 4：tomcat 线程池扩容实现：

img

原文：

比较 Tricky(困难) 的地方在于 tomcat 定制了第 30 行 workQueue 的实现，代码位于org.apache.tomcat.util.threads.TaskQueue类中。TaskQueue 继承自 LinkedBlockingQueue，并重写了offer方法，如图5。可以看到：

  1. Line 4：当线程池中的工作线程数已经达到最大线程数时，则直接将任务放入队列；
  2. Line 6：否则，如果线程池中的工作线程数还未达到最大线程数，当提交的任务数（parent.getSubmittedCount()）小于池中工作线程数，即存在空闲的工作线程时，将任务放入队列。这种情况下，放入队列的任务，理论上将立刻被空闲的工作线程取出并执行；
  3. Line 8：否则，只要当前池中工作线程数没有达到最大值，直接返回false。此时图 4第30行workQueue.offer(command) 就将返回false，这会导致execute方法执行第37行的addWorker(command, false)，对线程池进行扩容；

img

图 5：tomcat TaskQueue offer() 方法实现

通过分析这两段代码，得到如图6的 tomcat 线程池扩容流程图。

img

图 6：tomcat 线程池扩容逻辑流程图

上面的原文读起来有点困难，我稍作翻译，注意，tomcat的ThreadPoolExecutor扩容策略和JUC的ThreadPoolExecutor略有不同，JUC的是如果核心线程池已经满了，队列也满了，但总线程数还没有到达线程最大值，就会创建新的线程，直到达到线程最大值后触发拒绝策略。这个过程就是JUC的线程池的扩容过程。

而Tomcat线程池扩容过程是：核心线程池满了，总线程数没满，则直接创建新的线程，直到总线程数满了，再把新提交进来的任务放入队列，队列如果再满了，经过二次判断(就是队列装不下了，在拒绝策略异常处理中还会再执行一次尝试存入队列)依旧放不进队列，才会执行拒绝策略。

在这里插入图片描述

2.2 线程池处理能力饱和的后果：任务排队导致探活失败，引发 Pod 重启

标题中的探活失败，引发 Pod 重启是什么意思？下面是k8s的配置以及对应的Pod重启条件

livenessProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  initialDelaySeconds: 20
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

timeoutSeconds: 5 表示探针请求的超时时间为 5 秒。如果在 5 秒内没有收到响应，探针将认为检查失败。

是的，如果存活探针连续 failureThreshold 次（在这个例子中是 3 次）检测失败，k8s将认为 Pod 不健康，并自动重启该 Pod。

而/actuator/health这样的探针地址是由springboot的actuator模块提供的，用于监控和管理 Spring Boot 应用。它包含了一系列的生产就绪特性，可以帮助你监控应用的健康状态、收集应用的度量数据、审计事件、查看应用的配置信息等。我们需要再对应的服务的依赖中引入下面的依赖才可以成功使用探针：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

原文：

当前，该应用基于默认配置，使用 SpringBoot 的健康检查端口（Endpoint），即actuator/health，作为容器的存活探针。而问题就有可能出在这个存活探针上，k8s 会请求应用的actuator/health端口，而这个请求也需要提交给 tomcat 线程池执行。

设想如图7中的场景。Thread-1 ～ Thread-200 因处理业务请求而饱和，工作队列已经积压了一些待处理的业务请求（待处理任务 R1 ～ R4），此时 k8s 发出了探活请求（R5），但只能在队列中等待。对于任务 R5 来说，最好的情况是刚刚放入工作队列就立刻有大于等于5个工作线程从之前的任务中释放出来，R1～R5 被并行取出执行，探活请求被立即处理。但线程池因业务请求饱和时，并不存在这种理想情况。通过前文已经知道，confirmEvaluate 的耗时飙升到了 5s，排在 R5 前面的业务请求处理都很慢。因此比较坏的情况是，R5 需要等待 R1、R2、R3、R4 依次执行完成才能获得工作线程,将在任务队列中积压 20s(4×54\times54×5)， 甚至更久。

img

图 7：在任务队列中等待的探活请求

而 bfe-customer-application-query-svc 的探活超时时间设置的是 1s，一旦发生积压的情况，则大概率会超时。此时 k8s 会接收到超时异常。果然，如图8、图9，通过查阅 Pod 事件日志，我发现 Pod-1（..186.8）在 08:53:59 记录了探活失败，随后触发了重启，Pod-2（..188.173）则是在 08:53:33 记录了探活失败，随后也触发了重启。而这两个时间正是在上文提到的 “线程池达到饱和" 的两个时间点附近（Pod-1 08:54:00 和 Pod-2 00:53:30）。

由于 zone-2 仅有 2 个 Pod，当 Pod-1 和 Pod-2 陆续重启后，整个 zone-2 便没有能够处理请求的节点了，自然就表现出完全不可用的状态。

img

图 8：探活失败（..186.8）

img

图 9：探活失败（..188.173）

但为什么只有 zone-2 会整个不可用呢？于是，我又专门对比了 zone-1 的两个 Pod，如 图10到图13。从图10、图11可以看到，zone-1 的两个 Pod 在下游依赖抖动时也发生了类似 zone-2 的 tomcat 线程池扩容，不同之处在于，zone-1 两个 Pod 的线程池都没有达到饱和。从图12、图13也可以看到，zone-1 的两个 Pod 在 八点五十分前后这段时间内，没有任何探活失败导致重启的记录。

img

图 10：tomcat 线程池使用情况（..92.140）

img

图 11：tomcat 线程池使用情况（..167.148）

img

图 12：探活成功（..92.140）

img

图 13：探活成功（..167.148）

显然， zone-1 并没有置身事外，同样受到了耗时抖动的影响，同样进行了线程池扩容。但可用线程仍有余量，因此并没有遇到 zone-2 探活失败，进而触发 Pod 重启的问题。

2.3 深度检查：寻找线程池处理能力恶化的根因

原文中作者感觉是SOA 调用下游 getTagInfo 耗时增加，导致 tomcat 线程陆续陷入等待，最终耗尽了所有可用线程。其中，调用上下游的相关服务指的是当前服务调用其他服务器或其他容器中的服务，不是自己容器内部的服务，为了提高调用效率，比如需要计算的结果需要通过来自A,B,C三个服务的数据，而依次调用这三个服务的数据太慢了，所以会采用多线程的方式并行处理。

2.3.1 与推论相矛盾的关键证据：WAITING状态线程数飙升

这一小节作者主要工作时查看问题线程的状态究竟是WAITING还是TIMED_WAITING。

原文中作者发现监控中给出的阻塞线程状态为WAITING,而作者认为应该是TIMED_WAITING。但是作者查看了IOReactorWorker 的源码后发现，对线程状态修改的关键代码都给与了超时参数的设置，这与监控中给出的WAITING状态不符，所以排除了IOReactorWorker 。

在 Java 中，线程可以处于以下六种状态之一：

  1. 新建（NEW）：
    • 线程对象被创建，但尚未调用 start() 方法。
    • 例如：Thread t = new Thread();
  2. 可运行（RUNNABLE）：
    • 线程已经调用了 start() 方法，等待被线程调度器选中执行。
    • Java 将操作系统中的就绪（ready）和运行（running）状态统一称为“可运行”状态。
  3. 阻塞（BLOCKED）：
    • 线程等待获取一个监视器锁（monitor lock）。
    • 例如：线程试图进入一个同步块或方法，但该锁被其他线程持有。
  4. 等待（WAITING）：
    • 线程等待其他线程执行特定操作（如通知或中断）。
    • 进入方式：调用 Object.wait()、Thread.join() 或 LockSupport.park()。
    • 例如：synchronized (obj) { obj.wait(); }
  5. 超时等待（TIMED_WAITING）：
    • 线程在指定时间内等待，可以在超时后自动返回。
    • 进入方式：调用 Thread.sleep(long millis)、Object.wait(long timeout)、Thread.join(long millis)、LockSupport.parkNanos(long nanos) 或 LockSupport.parkUntil(long deadline)。
    • 例如：Thread.sleep(1000);
  6. 终止（TERMINATED）：
    • 线程的 run() 或 main() 方法执行结束，或者因异常退出。
    • 例如：线程正常执行完毕或抛出未捕获的异常。

至于WAITING和TIMED_WAITING的区别，通过下图就可以了解，其实TIMED_WAITING中的方法里多了一个参数，可以理解为过期时间，简单说就是，WAITING 状态的线程本身不会主动唤醒，处于 WAITING 状态的线程不会参与锁竞争。它们在等待被唤醒时，不会尝试获取任何锁。因此，WAITING 状态的线程不会影响其他线程对锁的竞争。必须依赖其他线程调用 notify() 或 notifyAll() 方法来唤醒它。只要没有其他线程调用这些方法，处于 WAITING 状态的线程就会一直休眠下去。而TIMED_WAITING状态的线程一旦过期时间到达，则自动被唤醒进入blocked状态，可以参与锁竞争。

image.png

2.3.3 弄巧成拙的业务代码

作者发现既然调用的三方框架不存在导致WATING状态线程的操作，那么监控中大量的WATING状态的线程从何而来呢，最终，作者在项目中的业务代码(自己人写的)发现了问题。

问题1：调用上下游接口没有超时处理

img

CompletableFuture

CompletableFuture 是 Java JUC中提供的一种工具，用来简化和增强异步编程。它的主要作用是让你可以更方便地处理并行任务和异步操作。

  1. 异步任务：
    • 你可以让某个任务在后台运行，不会阻塞主线程。比如，你可以在后台下载文件，同时继续处理其他任务。
  2. 组合任务：
    • 你可以把多个异步任务组合起来，形成一个任务链。比如，先下载文件，然后解压，再处理文件内容。
  3. 异常处理：
    • 如果异步任务中出现了异常，你可以很方便地捕获并处理这些异常，不会让程序崩溃。
  4. 手动完成：
    • 你可以手动设置任务的结果，比如在某些条件下提前返回结果。

  • 并行计算：同时执行多个计算任务，提高效率。
  • 异步 I/O 操作：处理耗时的输入输出操作，比如网络请求，不会阻塞主线程。
  • 复杂工作流：通过组合多个异步任务，完成复杂的操作流程。

DEMO:

public class CompletableFutureExample {
    public static void main(String[] args) {
        // 模拟调用第一个服务
        CompletableFuture<Integer> future1 = CompletableFuture.supplyAsync(() -> {
            // 模拟服务调用延迟
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return 10; // 返回结果
        });

        // 模拟调用第二个服务
        CompletableFuture<Integer> future2 = CompletableFuture.supplyAsync(() -> {
            // 模拟服务调用延迟
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return 20; // 返回结果
        });

        try {
            // 分别获取两个服务的结果
            Integer result1 = future1.get();
            Integer result2 = future2.get();

            // 将结果相加
            Integer finalResult = result1 + result2;

            // 打印结果
            System.out.println("结果: " + finalResult);
        } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
        }
    }
}

问题就出在future1.get()和future2.get()这里，开大get()方法，我们会发现：

在这里插入图片描述

内部使用了waitingGet方法，也就是说，当前线程在等待任务执行完成之前会一直处于Waiting状态，直到任务执行完成为止，如果任务执行过程中遇到了高耗时这样的网络抖动的情况，也只能干等着，没有任何操作，直到线程池耗尽。

原文中作者并未给出解决方案，我个人理解应该是这样的， 简单说当遇到调用上下游接口遇到长耗时这样的网络抖动的情况时，不应该等到最终tomcat线程池耗尽，pod重启才报警给技术人员，而是应该在长耗时发生时立即写入日志，频繁发生时应直接报警，交给技术人员处理：

public class CompletableFutureExample {
    public static void main(String[] args) {
        // 模拟调用第一个服务
        CompletableFuture<Integer> future1 = CompletableFuture.supplyAsync(() -> {
            // 模拟服务调用延迟
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return 10; // 返回结果
        });

        // 模拟调用第二个服务
        CompletableFuture<Integer> future2 = CompletableFuture.supplyAsync(() -> {
            // 模拟服务调用延迟
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return 20; // 返回结果
        });

        try {
            // 分别获取两个服务的结果，设置超时时间为2秒
            Integer result1 = future1.get(2, TimeUnit.SECONDS);
            Integer result2 = future2.get(2, TimeUnit.SECONDS);

            // 将结果相加
            Integer finalResult = result1 + result2;

            // 打印结果
            System.out.println("结果: " + finalResult);
        } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
        } catch (TimeoutException e) {
            // 处理超时异常
            System.err.println("获取结果超时，执行相应的处理逻辑");
            // 例如：记录日志、重试、返回默认值等
            Integer defaultResult = 0; // 默认值
            System.out.println("使用默认值: " + defaultResult);
        }
    }
}

其中 future2.get(2, TimeUnit.SECONDS);的带参的get方法会调用timedGet方法，线程状态是TIMED_WAITING的，如果超时，会触发TimeoutException，我们妥善捕获并处理该异常即可。

在这里插入图片描述

问题2：自定义线程池没有考虑业务需求

原文介绍的项目中，他们自定义了线程池，名字叫做BizExecutorsUtils

  1. Line 16：可以看到线程池的最大线程数只有 20；
  2. Line 19：工作队列却很大，可以允许 1K+ 个任务排队；

img

原文也提到了，EXECUTOR 是静态初始化的，在同一个 JVM 进程中全局唯一。这里的线程池定义，很难不让我想到只有 3 个诊室，却排了 500 号病人的呼吸内科。这种现象被称作瓶口效应（也就是瓶颈）

问题3：pod数量太少

CI （持续集成Continuous Integration, CI）团队为了降低成本，多次找到应用的 Owner 并以 CPU 水位为唯一标准沟通缩容计划，最终两边达成一致，将每个 zone 的 Pod 数量缩容到了 2 个。但实际这个应用不是CPU密集，而是I/O密集的。

定义了线程池，名字叫做BizExecutorsUtils

  1. Line 16：可以看到线程池的最大线程数只有 20；
  2. Line 19：工作队列却很大，可以允许 1K+ 个任务排队；

[外链图片转存中…(img-ZMecMTWh-1721987114724)]

原文也提到了，EXECUTOR 是静态初始化的，在同一个 JVM 进程中全局唯一。这里的线程池定义，很难不让我想到只有 3 个诊室，却排了 500 号病人的呼吸内科。这种现象被称作瓶口效应（也就是瓶颈）

问题3：pod数量太少

CI （持续集成Continuous Integration, CI）团队为了降低成本，多次找到应用的 Owner 并以 CPU 水位为唯一标准沟通缩容计划，最终两边达成一致，将每个 zone 的 Pod 数量缩容到了 2 个。但实际这个应用不是CPU密集，而是I/O密集的。

在这里插入图片描述

zhaozhiqiang1981
关注
  • 16
    点赞
  • 踩
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Windows Server 2019 故障转移群集 （MSCS）安装部署-图文详解
03-27
在Windows Server 2019中，故障转移群集（MSCS）是一种高可用性解决方案，它允许多台服务器（节点）协同工作，共同提供应用程序和服务。在群集中，当某个节点发生故障时，其他节点会自动接管服务，确保用户服务的...
计算机网络故障诊断与排除-物理层故障诊断与排除-图文.pptx
11-21
计算机网络故障诊断与排除是计算机网络管理中的一项重要任务，而物理层故障诊断与排除是计算机网络故障诊断与排除中的一部分。物理层是OSI分层结构体系中最基础的一层，它建立在通信媒体的基础上，实现系统和通信...
手把手教你使用vue-cli脚手架(图文解析)
08-28
手把手教你使用vue-cli脚手架（图文解析） 本篇文章主要介绍了使用vue-cli脚手架的详细教程，从环境搭建到项目初始化的每一步骤都进行了详细的解析。下面是本篇文章的知识点总结： 一、Vue-cli脚手架的优势 * 有...
计算机组装与维护技能(故障排除)-图文.pptx
11-21
这可能是由于CPU超频、风扇故障、散热片安装不当或散热硅脂涂抹不均。处理方法包括检查风扇运行情况，确保散热片与CPU接触紧密，涂抹适量的散热硅脂，并考虑降低CPU频率以减轻其负荷。 2. **计算机自动关机或重启**...
Win Server 2019 MSCS下 Oracle11g,19c 故障转移群集部署-图文详细讲解
03-27
【Windows Server 2019 MSCS 下 Oracle11g,19c 故障转移群集部署详解】 在IT领域，确保业务连续性和高可用性是至关重要的，尤其是在关键应用如Oracle数据库服务中。Windows Server 2019 提供了故障转移群集（MSCS，...
golang 接口
m0_70982551的博客
07-24 880
接口定义了一组方法，这些方法没有具体的实现。接口类型的变量可以存储任何实现了这些方法的类型的值。// 更多方法...在Go语言中，接口值是指存储了实现某个接口的具体类型值的变量。接口值由两部分组成：1.动态类型：这是接口值当前存储的实际类型。2.动态值：这是实际存储的值，该值必须实现了接口中定义的所有方法。
Swagger使用Map接受参数时，页面如何显示具体参数及说
a1058926697的博客
07-26 470
后端使用Map接受参数，要求在swagger页面上显示具体的参数名称、类型及说明。当Map接受参数数量少时，可以使用Swagger自带的注解。自定义注解 @ApiGlobalModel。编写处理注解对应的插件。
springboot之自动装配
weixin_50153914的博客
07-23 581
Spring Boot 通过一系列注解和条件配置实现了自动装配机制，使得开发者无需手动配置大量的 XML 文件或 Java 配置类。自动配置机制利用文件中的自动配置类，并结合条件注解和组件扫描，实现了灵活且强大的自动装配功能。这样，开发者可以专注于业务逻辑的实现，而无需处理繁琐的配置细节。
Java的@DateTimeFormat注解与@JsonFormat注解的使用对比
訾博（ZiBo）的博客
07-27 562
在Spring和Jackson框架中，日期和时间格式化是一个常见需求。注解主要用于Spring的表单绑定，而注解则用于Jackson的JSON序列化和反序列化。了解这两个注解的使用场景和方法，可以帮助开发者更高效地处理日期和时间。和是处理日期和时间格式化的两个重要注解。主要用于Spring MVC的请求参数绑定，而主要用于Jackson的JSON序列化和反序列化。了解它们的使用场景和功能，可以帮助开发者更高效地处理日期和时间格式化需求。通过本文的介绍，希望读者能够更清晰地理解和。
Java修炼 2024.7.26 0:24
2301_80011650的博客
07-26 405
问题：编写一个方法，找出一个数组中的众数（出现次数超过数组长度一半的元素）。例如，输入 [2, 2, 1, 1, 2]，输出 2。编写一个方法，找出一个整数数组中的第二大元素。例如，输入 [3, 5, 1, 8, 7]，输出 7。例如，输入 5，输出 5。问题：编写一个方法，将给定的字符串逆转。问题：使用数组实现栈，并提供基本操作（push、pop、peek、isEmpty）。问题：实现一个单向链表，并提供基本的操作（添加、删除、查找元素）。问题：编写一个方法来查找一个给定字符串的所有子串。
Java代码基础算法练习-数的特性-2024.07.25
Sakurapaid的博客
07-25 349
小A喜欢两种性质都成立的数字，小B喜欢至少符合一种性质的数字，小C喜欢不符合这两种性质的 数字。给出一个数字，请输出三个人是否喜欢这个数字。如果喜欢输出1，否则输出0，用空格分隔。输入数字 num，先定义三个整型代表三个人的喜欢与否，先默认设为 0。之后判断num对于性质1、2的条件，分别用 boolen 类型标识。对于每个整型进行判断，是否改为 1 代表喜欢。性质2：大于4且不大于12;
新建springboot项目找不到java版本8?
最新发布
weixin_74009895的博客
07-28 84
新建springboot项目找不到java版本8?
SSM框架整合——常用方式整合SSM框架（三）Spring和MyBatis整合
PAP
07-26 171
SSM框架整合——常用方式整合SSM框架（三）Spring和MyBatis整合
19.jdk源码阅读之FutureTask
前端、移动端、后端源码级底层原理分享
07-25 860
FutureTask 是 Java 并发包中的一个重要类，它实现了 RunnableFuture 接口，结合了 Future 和 Runnable 的特性。FutureTask 通常用于异步任务的执行和结果的获取。
Jvm基础（一）
G81948577的博客
07-19 1032
本地方法就是不使用java编写的，比如C++编写的程序，只是需要传递参数。
教务管理平台/高校教务管理系统的设计与实现/教务网站/学生成绩管理系统/学生课程管理系统
weixin_47958760的博客
07-27 424
本毕业设计的内容是设计并且实现一个基于JSP技术的教务管理平台。采用MYSQL为数据库开发平台，SSM框架，Tomcat网络信息服务作为应用服务器。教务管理平台的功能已基本实现，主要有学生、教师、课程信息、课程选择、教师课表、学生成绩、图书信息、考试等管理功能。 论文主要从系统的分析与设计 、数据库设计和系统的详细设计等几个方面来进行论述，系统分析与设计部分主要论述了系统的功能分析、系统的设计思路，数据库设计主要论述了数据库的设计，系统的详细设计部分主要论述了几个主要模块的详细设计过程。
android audio不同音频流，(八)music流音量APK按键调整
五味香的专栏
07-24 418
apk通过监测按键事件，再调用AudioManager函数接口，调节STREAM_MUSIC流音量调节。
PHP中static的使用
likeshopgood的博客
07-24 861
本文详细介绍了PHP中static关键字的使用，并通过实例展示了其强大功能。利用静态属性和方法，我们可以在类实例间共享数据和行为，从而提高代码的效率和可维护性。然而，使用静态成员时，需注意内存管理和访问权限的特殊性，以确保代码的健売性和可管理性。关于我们本文由ChatMoney团队出品，ChatMoney专注于AI应用落地与变现，我们提供全套、持续更新的AI源码系统与可执行的变现方案，致力于帮助更多人利用AI来变现，欢迎进入ChatMoney获取更多AI变现方案！
Java 使用 POI 导出Excel，设置同一个单元格的内容显示不同的文字颜色
viman3344的专栏
07-27 352
在使用Apache POI的库生成Excel的时候，如何在一个Cell中的文字中显示不同的颜色？下面是一个示例代码，演示如何在单元格中设置不同颜色的文本。more。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值