JDK21虚拟线程僵死、调查及展望

于 2025-07-10 07:30:23 发布
阅读量1k 收藏 19
点赞数 12
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/SOHU_TECH/article/details/149264809

01

虚拟线程诞生的背景

1.1 背景

说起虚拟线程，不得不提一下Java现有的线程模型，Java的线程模型基于操作系统线程（即“平台线程”）。每个线程与操作系统的调度器直接挂钩，线程的创建和销毁往往需要较大的开销。随着并发处理需求的激增，基于线程池和事件驱动的异步编程模型逐渐成为解决高并发问题的主流方式。

1.2 线程池的局限性

线程池是通过维护一组线程来处理任务，减少了频繁创建和销毁线程的性能开销，但在高并发场景下仍可能存在瓶颈：

  • 线程数量的限制：线程池中的线程是有限的，当请求数过多时，线程池可能无法满足所有请求，造成任务的阻塞；

  • 线程的上下文切换：线程池中的线程需要频繁地进行上下文切换，在高并发的情况下，操作系统需要花费大量的时间来管理线程的调度，导致性能的下降。

1.3 高并发的需求

随着微服务架构的普及以及对高并发处理能力的需求，很多业务开始采用Reactive编程模型，例如RxJava、Project Reactor等。这些编程框架强调通过事件驱动、非阻塞I/O来处理大量并发请求，极大提高了处理效率，但这依然存在以下问题：

  • 回调地狱和复杂性：大量的异步回调容易导致代码难以理解和维护，尤其是在处理复杂业务逻辑时；

  • 学习曲线：Reactive编程需要掌握新的概念（如背压、调度器等），对于传统同步编程的开发者来说，学习和理解的难度较大；

  • 调试困难和性能开销：由于涉及异步操作和多线程调度，调试变得更加复杂，额外的抽象层也可能带来性能损失，影响响应速度。

为了克服上述问题，JDK引入了虚拟线程，它通过轻量级线程模型来有效解决高并发问题。

02

虚拟线程的特点

Java的虚拟线程项目-Loom早在2017年即作为实验性项目进行开发，在历经JDK 19和20的预览版后，终于于2023年09月19日在JDK 21 LTS版本中正式发布了。

虚拟线程是一种新型线程，它是为了简化并发编程而设计的。与传统的线程不同，虚拟线程并不是直接由操作系统调度的，而是由JVM调度和管理，通过更高效的调度机制，使得数百万的线程也能在单台机器上高效运行。它具有如下特性：

  • 轻量级：每个虚拟线程的内存消耗非常小，相比传统线程，它们能够在短时间内被快速创建和销毁。官方建议虚拟线程不应池化，每次执行任务都可以创建一个新的虚拟线程，例如仅执行一次HTTP调用或JDBC查询；

  • 非阻塞I/O：虚拟线程适合用于处理大量的并发任务，尤其是在需要非阻塞I/O操作时，它们能够在等待I/O时挂起，并允许JVM将CPU时间分配给其他任务，从而提高了吞吐量；

  • JVM调度：JVM通过ForkJoin线程池来调度虚拟线程，并且会根据需要将虚拟线程挂起或恢复，从而避免了平台线程切换带来的开销；

  • 简化并发编程：虚拟线程本质上是同步代码的扩展，使用虚拟线程可以像编写串行代码一样编写并发代码，避免了线程池和Reactive编程的复杂性。

虚拟线程有助于提高应用程序的吞吐量，同时降低代码复杂度，增强维护性和扩展性。

03

虚拟线程的试用

由于我们的应用是基于SpringCloud平台开发的，为了保证兼容性和稳定性，希望以最小的改动来试用虚拟线程。经过调查和测试，如下是支持JDK21的无漏洞的最低版本：

spring-boot:2.6.15
spring-cloud:2021.0.8

另外，只针对spring-boot内嵌的web容器Tomcat开启虚拟线程，配置如下：

@Configuration
public class TomcatProtocolHandlerConfiguration {
    @Bean
    public TomcatProtocolHandlerCustomizer protocolHandlerCustomizer() {
        return protocolHandler -> {
            protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
        };
    }
}

上述代码中使用虚拟线程的核心代码是Executors.newVirtualThreadPerTaskExecutor()，进行上述配置后Tomcat即可使用虚拟线程处理请求。部署好进行流量压测，发现应用竟然僵死了。

3.1 服务器现场调查

由于应用在本地可以正常运行和访问，而部署到服务器压测会出现问题，所以需要到服务器上调查。

但是不幸的是，使用JDK的诊断工具执行都无反应，初步怀疑是整个应用僵死导致无法获取诊断信息。

3.2 日志调查

经过仔细调查系统日志，发现了如下可疑的地方：

这个是当虚拟线程被固定在平台线程上时打印的，JVM在发现这种情况时会打印被固定的线程栈。

在这里需要介绍一下什么是虚拟线程的固定：

当使用虚拟线程运行代码时，JVM会将虚拟线程挂载到平台线程进行执行。
JDK中的绝大多数阻塞操作都会卸载虚拟线程，使平台线程能挂载其他虚拟线程运行。
然而，有以下两种情况，在虚拟线程阻塞时，它会被固定在平台线程上：
1 执行synctronized块内的代码
2 执行native方法或外部函数
当虚拟线程固定在平台线程时，挂载了虚拟线程的平台线程就不能再挂载其他的虚拟线程了。

如果有大量的虚拟线程被固定在平台线程上，势必会妨碍系统的扩展性，为了能够监控这种情况，JDK提供了-Djdk.tracePinnedThreads=full参数，以便能够发生固定时打印线程栈。

3.3 真相浮出水面

经过大量调查后，这个参数让我们产生了疑问，随后以pinned为关键字搜索虚拟线程僵死的问题，结果发现了如下Bug:

https://github.com/openjdk/jdk/pull/17221: Running with -Djdk.tracePinnedThreads set can hang

导致JVM僵死的是这个参数：-Djdk.tracePinnedThreads=full，去除这个参数后，僵死问题果然消失了。

在查看了该Bug的修复代码后，发现核心的逻辑竟然仅仅是将synchronized替换为了ReentrantLock，如下：

但是按照官方的说法，虚拟线程固定应该仅仅影响应用扩展性，参考JEP 444，官方描述如下：

固定不会使应用程序不正确，但可能会妨碍其可扩展性。
如果虚拟线程执行阻塞操作（例如 I/O）时被固定，则其载体和底层操作系统线程在操作期间将被阻塞。
应该将频繁运行synchronized的代码修改为ReentrantLock来避免长期的固定。

而现实情况是使用synchronized后，会导致系统僵死，与官方描述不符。并且synchronized自从Java诞生以来就是同步编程使用的关键字，如果把所有synchronized的代码替换成ReentrantLock，显然不切实际。

所以需要深入研究一下虚拟线程固定导致僵死的本质原因。

04

虚拟线程僵死的本质原因

4.1 僵死案例

跟该Bug相关的还有其他僵死的案例，在深入研究了相关代码后，发现了导致僵死的本质原因：一种死锁的变种-平台线程饥饿导致的死锁。

这里列举一个尽量简单的简化代码：

public class Test {
    public static void main(String[] args) throws Exception {
        TestRunnable testRunnable = new TestRunnable();
        // 1.先启动一个虚拟线程抢占锁
        Thread.ofVirtual().name("unpinned").start(testRunnable);
        // 2.由于JVM采用CPU核数个平台线程调度虚拟线程，所以这里启动的虚拟线程数为CPU核数
        for (int i = 0; i < Runtime.getRuntime().availableProcessors(); i++) {
            Thread.ofVirtual().name("pinned-" + i).start(() -> {
                // 3.这里的锁是为了将虚拟线程固定在平台线程上
                synchronized (Test.class) {
                    testRunnable.run();
                }
            });
        }
        Thread.sleep(10 * 1000);
    }

    static class TestRunnable implements Runnable {
        ReentrantLock lock = new ReentrantLock();

        public void run() {
            try {
                lock.lock();
                Thread.sleep(10);
            } finally {
                lock.unlock();
            }
        }
    }
}

这里先解释一下上述代码的目的：

   - unpinned命名的虚拟线程获得ReentrantLock锁后，执行sleep时会被平台线程卸载，使平台线程可以运行其他虚拟线程；

   - pinned-*命名的虚拟线程由于synchronized而被固定在平台线程上。

运行上述代码僵死的情况必现，但是把Thread.ofVirtual()替换为Thread.ofPlatform()，即虚拟线程替换为普通的线程，则不会出现僵死的情况。

其实如下代码都可能会出现僵死，只是概率小一点：

for (int i = 0; i < Runtime.getRuntime().availableProcessors() + 1; i++) {
    Thread.startVirtualThread(() -> {
        System.out.println("1");
        synchronized (Test.class) {
            System.out.println("2");
        }
    });
}

因为只要涉及到synchronized的代码，都有可能出现僵死，下面分析一下原因。

4.2 线程栈分析

当僵死后，通过jstack和jcmd打印线程栈，经过分析，列出简要的线程栈如下：

   - JVM的ForkJoinPool调度线程（即“平台线程”）栈类似如下：

"ForkJoinPool-1-worker-8" #39 [7256] daemon prio=5 os_prio=0 cpu=0.00ms elapsed=36.13s tid=0x00000285fb3fc980  [0x000000bf9bcfe000]
   Carrying virtual thread #33
 at jdk.internal.vm.Continuation.run(java.base@21/Continuation.java:248)
 at java.lang.VirtualThread.runContinuation(java.base@21/VirtualThread.java:223)
 at java.lang.VirtualThread$$Lambda/0x0000028581050af0.run(java.base@21/Unknown Source)
 at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(java.base@21/ForkJoinTask.java:1423)
 at java.util.concurrent.ForkJoinTask.doExec(java.base@21/ForkJoinTask.java:387)
 at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base@21/ForkJoinPool.java:1312)
 at java.util.concurrent.ForkJoinPool.scan(java.base@21/ForkJoinPool.java:1843)
 at java.util.concurrent.ForkJoinPool.runWorker(java.base@21/ForkJoinPool.java:1808)
 at java.util.concurrent.ForkJoinWorkerThread.run(java.base@21/ForkJoinWorkerThread.java:188)

由Carrying virtual thread #39可以看出平台线程挂载了虚拟线程39正在运行。

上面类似的ForkJoinPool的线程栈共有8个（运行实例代码的机器为8核），也就是说所有的平台线程正挂载着虚拟线程。

   - 名字为unpinned的虚拟线程栈类似如下：

{
   "tid": "22",
   "name": "unpinned",
   "stack": [
      "java.base\/java.lang.VirtualThread.parkNanos(VirtualThread.java:631)",
      "java.base\/java.lang.VirtualThread.sleepNanos(VirtualThread.java:803)",
      "java.base\/java.lang.Thread.sleep(Thread.java:507)",
      "Test$TestRunnable.run(Test.java:27)",
      "java.base\/java.lang.VirtualThread.run(VirtualThread.java:311)"
   ]
 }

该线程正在执行Thread.sleep(10)，等待时间到后被唤醒。

   - 名字为pinned-0的虚拟线程栈类似如下：

{
   "tid": "25",
   "name": "pinned-0",
   "stack": [
      "java.base\/jdk.internal.misc.Unsafe.park(Native Method)",
      "java.base\/java.lang.VirtualThread.parkOnCarrierThread(VirtualThread.java:673)",
      "java.base\/java.lang.VirtualThread.park(VirtualThread.java:603)",
      "java.base\/java.lang.System$2.parkVirtualThread(System.java:2639)",
      "java.base\/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:54)",
      "java.base\/java.util.concurrent.locks.LockSupport.park(LockSupport.java:219)",
      "java.base\/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:754)",
      "java.base\/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:990)",
      "java.base\/java.util.concurrent.locks.ReentrantLock$Sync.lock(ReentrantLock.java:153)",
      "java.base\/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:322)",
      "Test$TestRunnable.run(Test.java:25)",
      "Test.lambda$main$0(Test.java:13)",
      "java.base\/java.lang.VirtualThread.run(VirtualThread.java:311)"
   ]
 }

根据VirtualThread.parkOnCarrierThread可以看出，此虚拟线程由于争夺ReentrantLock正在park，但是由于synchronized被固定在了平台线程上，对应JDK源码如下：

   - 名字为pinned-1~7的虚拟线程栈类似如下：

{
   "tid": "33",
   "name": "pinned-7",
   "stack": [
      "Test.lambda$main$0(Test.java:13)",
      "java.base\/java.lang.VirtualThread.run(VirtualThread.java:311)"
   ]
 }

pinned-1~7的虚拟线程都在等待synchronized锁。

从上述线程栈可以看出核心的地方在于竞争锁的过程：

   - unpinned的虚拟线程获得了ReentrantLock锁，之后进行sleep；

   - pinned-0的虚拟线程获得了synchronized锁，由于需要等待ReentrantLock锁，故执行了park；

   - pinned-1~7的虚拟线程在等待synchronized锁。

这里用下图来描述一下整体的过程：

  • 第①步中，unpinned线程获得ReentrantLock锁后，正在sleep；

  • 第②步中，pinned-0线程获得synchronized锁；

  • 第③步中，pinned-0线程尝试获取ReentrantLock锁，但是unpinned线程正在持有，所以pinned-0线程进行了park；

  • 第④步中，pinned-1~7的线程尝试获取synchronized锁，但是该锁已被pinned-0线程获取，故都进入block状态；

  • 第⑤步中，平台线程ForkJoinPool-1-worker-1~8均挂载了虚拟线程，但是由于synchronized的原因，即使虚拟线程已经park了，也无法卸载。

当unpinned线程醒来后，需要被调度到平台线程继续运行，但是没有空闲的平台线程，由于平台线程饥饿导致的死锁便出现了！

这里提到没有空闲的平台线程，可是之前说的JVM的ForkJoinPool调度线程栈类似如下：

"ForkJoinPool-1-worker-8" #39 [7256] daemon prio=5 os_prio=0 cpu=0.00ms elapsed=36.13s tid=0x00000285fb3fc980  [0x000000bf9bcfe000]
   Carrying virtual thread #33
 at jdk.internal.vm.Continuation.run(java.base@21/Continuation.java:248)
 at java.lang.VirtualThread.runContinuation(java.base@21/VirtualThread.java:223)

上面的线程栈只是显示Carrying virtual thread #33，并没有显示线程状态，怎么知道没有空闲的平台线程呢？

确实是这样，JDK 21的调度线程比较特殊，无论是使用jstack -l还是jcmd Thread.dump_to_file -format=json都无法打印出调度线程的状态，甚至明明知道线程在等待synchronized锁，可是却无法输出等待锁的信息。

不过可以通过Arthas可以获取调度线程的状态，如下：

跟预料的一致，调度线程中，除了ForkJoinPool-1-worker-1在WAITING，其余的都被BLOCKED了，确实没有空闲的了。

下面再看一下AQS（AbstractQueuedSynchronizer）等待队列的情况，以便进一步明确上面的推断。

4.3  内存分析

得益于强大的MAT（Eclipse Memory Analyzer Tool），使得分析内存对象变得容易，这里获取到了代码中的TestRunnable对象的引用如下：

从上图可以看出，TestRunnable对象持有一个ReentrantLock对象，这里分别说一下AQS等待队列中的对象：

   - 由 ① exclusiveOwnerThread可知，它就是代码中的name为unpinned虚拟线程，由于该线程在执行sleep代码，所以它已经从平台线程卸载，所以carrierThread为null，目前该虚拟线程持有锁；

   - 由 ② head可知，在AQS队列中它是第一个节点（对应unpinned虚拟线程），它的status为0，waiter为null，即没有在等待锁；

   - 由 ③ next可知，在AQS队列中它是第二个节点（由waiter属性可知对应pinned-0虚拟线程），它的status为1，表示在等待锁。

其中head节点（unpinned线程）sleep完毕后，应该执行unlock，被移出队列，以便pinned-0线程执行，但是不幸的是，由于没有空闲的平台线程，它永远无法被移出，这就跟之前的线程栈分析对上了。

由于JVM默认的调度并行度就是cpu核数，如果虚拟线程固定在平台线程上，很容易出现平台线程不够用的情况，甚至出现线程饥饿导致的死锁。

总结：这种虚拟线程固定导致的调度线程饥饿进而引起的死锁问题，并不能通过扩大调度线程数彻底解决。

05

虚拟线程为什么需要固定

根据Java官方的解释，之所以虚拟线程遇到synchronized不能从平台线程卸载，跟synchronized的实现有关。

具体为synchronized是通过监视器来实现的，每个Java对象都与一个监视器关联。同一时刻只有一个线程可以持有锁对象的监视器。而JVM会追踪当前哪个线程持有锁对象的监视器，但是JVM追踪的是平台线程，而非虚拟线程。

如果平台线程在synchronized块内卸载了虚拟线程，JVM会将其他虚拟线程调度到该平台线程，而该平台线程正在持有锁对象的监视器，那么其他虚拟线程就可以执行synchronized块内的代码，互斥就失效了。

具体底层原因跟JVM的锁实现有关，可以参见Java's Virtual Threads - Next Steps：https://www.youtube.com/watch?v=KBW4LbCoo6c。

在上述视频中，Loom团队为了解决固定情况已经制定了解决方案。

06

虚拟线程固定最新进展

6.1 固定问题解决

在JEP 491中，Java官方宣称已经解决了synchronized引起虚拟线程的固定问题，具体更改如下：

他们更改了synchronized关键字的实现，以便虚拟线程可以独立于平台线程获取，保留和释放监视器，并且支持在等待监视器时释放平台线程，以便平台线程可以挂载其他虚拟线程。当监视器被释放时，重新挂载虚拟线程，以恢复执行并再次尝试获取监视器。

该JEP将于2025年3月18日，包含在JDK 24的发布中。

我使用JDK 24的体验版本测试，虚拟线程固定导致僵死的情况确实消失了，并且确实如官方所说，虚拟线程在等待synchronized锁时，会释放平台线程。

在JEP 491描述中，关于JEP 444中使用ReentrantLock替换synchronized的描述也变了，参见如下：

如果您正在编写新代码，我们同意《Java 并发实践》第 13.4 节中的建议：
synchronized在切实可行的情况下使用，因为它更方便且更不容易出错，而ReentrantLock在需要更多灵活性时使用。
无论哪种方式，都应通过缩小锁定范围来减少争用的可能性，并尽可能避免在持有锁定时执行 I/O 或其他阻塞操作。

另外，除了synchronized外，一些类加载或初始化时也会导致固定，但是这些情况目前很少引起问题，如果将来被证明有问题，官方会重新审视它们。

6.2 前景展望

目前最新的JDK LTS版本还是JDK 21，其将支持到2031年，而一些业务已经升级到JDK 21，那么JEP 491是否会合并到JDK 21中呢？

由于JEP 491基于了破坏JDK 19-22兼容性的提议实现的，也就是说合并到JDK 21可能比较困难。

不过好消息的是，JDK发版很快，根据发布计划，下一个LTS版本马上也就发布了：

最后总结，任何事物生来都是不完美的，只有在实践中不断地调整与完善，才能实现真正的成熟与卓越。

07

参考文献

  1. JEP 444: https://openjdk.org/jeps/444

  2. JEP 491: https://openjdk.org/jeps/491

  3. jdk.tracePinnedThreads导致僵死：https://github.com/openjdk/jdk/pull/17221

  4. jdk.tracePinnedThreads修复：https://github.com/openjdk/jdk22/commit/3017281956f3c8b50f064a75444c74a18d59e96d

  5. 虚拟线程+c3p0导致僵死：https://blog.ydb.tech/how-we-switched-to-java-21-virtual-threads-and-got-deadlock-in-tpc-c-for-postgresql-cca2fe08d70b

  6. 虚拟线程+logback导致僵死：https://jira.qos.ch/browse/LOGBACK-1711

  7. 虚拟线程+系统输出导致僵死：https://www.reddit.com/r/java/comments/1512xuo/virtual_threads_interesting_deadlock/

  8. OpenJdk Mail list：https://mail.openjdk.org/pipermail/loom-dev/2023-July/

  9. Java's Virtual Threads - Next Steps：https://www.youtube.com/watch?v=KBW4LbCoo6c

  10. 破坏JDK 19-22兼容性提议：https://bugs.openjdk.org/browse/JDK-8331422

  11. JDK 21: https://openjdk.org/projects/jdk/21/

  12. JDK 24: https://openjdk.org/projects/jdk/24/

  13. Java release: https://www.java.com/releases/


博客
搜狐新闻直播间适配HarmonyOs实现点赞动画
07-24 958
Ark UI中，UI的变化是通过状态变量控制的，由此需要设计一个数组，初始化为空数组，当触发一次动画操作时，向数组中添加一个数据，此时系统会根据数组的数量自动渲染对应的组件，当组件准备完成时执行属性动画，控制动画的状态变量放在数组里的对象中，当动画执行结束时，从数组中移除该数据，相应的组件也随之移除。
博客
用 MCP 扩展 Cursor 能力：解锁 Sentry 服务数据新玩法
07-24 768
服务的另一个核心组件，专门用于获取应用的会话统计数据，包括崩溃率、用户数量、会话持续时间等关键指标。问题的详细信息，包括问题标题、状态、级别、首次和最后出现时间、事件数量，以及最关键的堆栈跟踪信息。能够帮助我们监控和分析应用的稳定性表现，及时发现潜在问题，提供数据支持以优化用户体验和应用质量。可直接查询到更为全面、丰富的应用信息，全方位提升了数据的可获取性与利用价值。- 分组和排序：支持对数据进行分组和排序，便于比较分析不同维度的数据。信息以及可能的解决方案，这可以显著提升问题排查与解决的效率。
博客
线程锁漫谈
07-24 630
在开发中往往是多线程的，如果多个线程同时对同一资源进行读写，就可能造成资源抢夺的问题，导致数据计算结果不是我们想要的结果。从操作系统的层面，有些系统已经内置了解决方案，在遇到此类优先级反转的情况时，会出让高优先级线程的优先级给让低优先级线程，保证锁内资源执行的正常。的崩溃，如果执行次数很少，还是可以考虑的。但是，自旋锁的效率相对是很高的，因为不用进行线程唤醒的操作，而是让线程直接进入盲等状态，相当于运行了一个。可以进行跨平台使用，可以创建两种类型的锁，一个是互斥锁，一个是递归锁，在初始化时指定类型。
博客
视频审核中多模态应用
07-24 814
模型的训练过程，就是每个batch输入一定数量的图像和文本，通过各自模型encode成embedding，然后将图像的embedding和文字的embedding分别计算余弦相似度，损失函数要做的就是让成对的文本接近1，让不成对的文本接近0通过这样的方式，不断地调整两个encoder的权重，使得损失函数效果更好，以达到两个模型更高的对应表达。违规图片的检测，最先想到的方法就是建立违规图片数据库，视频进审时，针对视频关键帧提取图片特征，同图片违规数据库匹配，如果命中的话，则标记当前视频为违规视频。
博客
狐友抽奖平台构建之路
07-17 620
结合以上实际场景，我们引入预占库存的逻辑，将奖品分为总资源池和活动资源池，逻辑上相互独立，当新建一个玩法活动配置奖品库存时，需要进行预占库存的操作，会从总资源池中预占一部分库存，作为该活动的奖品库存，当活动的奖品库存发放完时，活动运营可以选择追加库存，当活动结束时，如果奖品库存仍有剩余，会自动返还至总资源池。在实际的业务场景下，运营人员分为两种角色，活动运营人员与运营BD人员，前者主要负责活动的策划和执行层面，后者负责活动奖品的商务拓展，与外部商家对接，获得商家的赞助。
博客
矢量图Vector安卓详解
07-17 304
通过VectorDrawable的创建过程，我们可以了解到所有图片资源，最终都会通过解释xml中的标签，在inflateFromTag方法中创建图片对象，如VectorDrawable，GradientDrawable，ColorDrawable等。的属性和SVG中的属性基本一一对应，其中pathData对应了SVG中的d属性，绘制命令也完全一致，包括了10个命令：M，L，H，V，C，S，Q，T，A，Z。ImageView中的动画默认会停在初始画面，需要在代码中通过start函数来启动动画。
博客
鸿蒙搜狐新闻如何在Native调用ArkTS方法
07-17 589
01前言鸿蒙作为一款新兴的智能操作系统，现在适配鸿蒙系统的应用越来越多，同时会面临三端兼容问题，如同一产品功能，需要维护iOS、Android、鸿蒙三端代码。拿文件上传、下载功能场景举例，同时要适配iOS、Android、鸿蒙三端，目前比较好的方案是文件上传、下载功能下沉到C，三端native代码可以复用，但是在鸿蒙上存在如下一个问题：Native文件上传、下载进度怎么从Native线程异步回调给ArkTs线程对应JS回调方法？答案：通过Node-API提供的线程安全函数，可以把文件上传、下载进度从nati
博客
使用AVPlayer播放FairPlay DRM视频的最佳实践
07-17 968
01DRM 介绍DRM，即数字版权管理（Digital Rights Management），是指使用加密技术保护视频内容、通过专业技术安全地存储和传输密钥（加密密钥和解密密钥）、并允许内容生产商设置商业规则，限制内容观看者的一种系统。1.1 DRM 工作流程DRM使用对称加密算法（Symmetric-key algorithms）对视频内容进行加密，对称加密算法使用同一把密钥加密和解密；首先，通过密钥（通常为AES-128）将内容加密，然后传输给客户端。这把密钥由专用服务器提供，安全可靠；当客户端想要播放
博客
基于LLM的流量回放系统
07-17 771
无论是GET请求或者POST请求，其实都是很多的key、value的组合，那么去重的优先级是， 优先key不同的数据， 这个不同包括key的绝对值不同，也包括key的多与少，如图中所示，当通过这种方式去重后，一般每个接口路径下，一种返回形状，可能只能剩下5个以内的数据了，但是这会出现一个问题，因为请求参数可能会有一些id，他们的值不同则代表了不同的文章、用户，去重后会造成这类数据的减少，但这种问题几乎无法预计，所以这里直接采用了最简单的办法，对已经去重的数据做随机补充。
博客
ViewPager2的滚动机制与优化
07-10 392
我们以C卡片为例,如果不操作的话那么我们的卡片应该处于右边C位置,然而实际上我们的卡片确却是在左边B位置,这样我们需要向下移动的卡片的距离为2*小卡片高度+ 大卡片高度,以此类推,D卡片需要多滑动一个小卡片的距离,以此类推,然而为了平滑移动需要乘以。然而，设计师的酷炫效果往往给开发者带来不小的挑战。可以看到第一张图片小卡片的人头部分没有显示出来,但是移动到第一张卡片的时候却显示的整张完整的图片,这样做的原因是为了在小卡片的时候显示我们想要显示的区域,这样效果会更好,那么这个效果我们需要怎么做呢？
博客
基于Redis的向量召回，支撑 AI 业务
07-10 320
传统的问答库多以关键词匹配为核心，但面对复杂的用户表达和多样化的问题场景，单纯的关键词匹配显得无能为力，给用户笨拙低效的体验。然而，智能客服的关键在于能够快速、准确地理解用户的问题，并提供有效的解决方案，而这背后离不开强大的问答库支持。当用户输入问题时，将问题也转换为向量，并通过向量相似度计算，召回匹配的问答数据，实现对用户问题的精准匹配。相比传统方法，向量搜索能够理解问题中的语义含义，识别出用户隐含的意图，即使用户的问题表述与问答库中的内容不完全一致，也能提供相关性较高的答案。
博客
当测试遇见AI：用 Streamlit+AutoGen+Deepseek 构建智能用例生成器
07-10 424
未来的测试领域，AI 将成为需求理解的翻译官、测试设计的参谋长、质量风险的预警器，最终实现 "让测试更智能，让质量更可靠" 的目标。它借助 Streamlit 构建出友好的用户界面，利用 AutoGen 库和 Deepseek 语言模型进行交互，只要用户输入需求，就能快速生成测试用例，极大提升了测试工作的效率。负责搭建用户界面，收集用户的需求和高级选项信息，提供交互功能，比如按钮点击、输入框输入等，还能实时显示生成的测试用例和相关状态信息，就像一个热情的 “接待员”，和用户进行互动。
博客
iOS静态代码检查方案解读
07-10 265
的程序，和我们人工分析的过程类似，符号执行引擎会分析程序逻辑的各个分支满足的条件，然后提前把这些条件准备好，如果有多个独立条件并存就会用排列组合的方式设计条件列表，再将这些不同预设的条件放到引擎中模拟执行，观察并记录符号的状态变化，具体某一项分析检查器只需要在合适的时机去读取符号的当前状态，判定是否有误即可知道代码是否存在问题了。前面我们讲述了如何使用 clang 针对单个文件进行分析，但实际的场景中，我们一般并不会单个的去编译一个个文件，而是利用针对工程的集成构建工具，例如。
博客
鸿蒙富文本实践
03-27 1264
图片组件 RichEditorImageSpanResult 就麻烦一些，首先通过 .valueResourceStr 可以获取到图片的资源路径 resource:///icon_emotion_8.png ，刨除协议头 resource:/// 与文件后缀 .png ，就得到了图片名 icon_emotion_8，通过配置表可以匹配到对应的表情关键字"[鼓掌]"。上面的文本就转换为："第一次见面她帮他出头，他被她拽拽的气质吸引，对她一见钟情，多年后重逢续写故事"、"[色]"、"这该死的羁绊～"。
博客
Argo Workflows 原理及应用
03-13 1400
01组件概述Argo Workflows是一个开源的容器原生工作流引擎，允许用户在Kubernetes集群上定义并执行复杂的业务流程。支持对相关流程进行个性化编排，包括执行顺序、相互之间的依赖等等。Argo Workflows 是以 Kubernetes 自定义资源定义（Custom Resource Definitions，简称 CRD）的形式来实现其功能。CRD 是 Kubernetes 提供...
博客
鸿蒙跨平台框架ArkUI-X
03-06 2021
01引言目前，移动端主流跨平台方案有Flutter、React Native、uni-app等等，还有刚推出不久的Compose-Multiplatform，真所谓是百花齐放。这些框架各有特点，技术实现各有差异，比如Flutter通过Dart编写的UI描述对接Flutter渲染引擎，React Native 则是借助大前端成熟的发展背景，利用JS引擎生成UI描述，渲染时转化为原生控件，复用了原生渲...
博客
Android 根据View生成图片
02-27 1033
01背景随着Android技术发展，经常有将某个界面截图保存下来分享，或者生成用户或者商品二维码图片方便加好友或者购买，所以这个功能在实际应用中非常有用，下面我将重点针对这些情况进行讲解，废话不多说了，先画个序列图，如下：序列图实现步骤：步骤一：创建View；首先，我们需要创建一个View，这个View可以是任何view，比如一个TextView或者一个Image View，也可以是LinearL...
博客
动态隐私检查方案优化与实现
02-20 1000
01背景在移动应用开发过程中，隐私保护是一项至关重要的工作。以往我们采用了一种动态隐私检查工具，通过xposed方式实现，然而，这种方案存在着诸多限制。需要特定型号的手机和复杂的安装操作，不适用于集成到自动化测试系统中。02两种方案的比较2.1 xposed 方式的实现以往我们采用了xposed框架实现了动态隐私检查功能。该方案通过修改Android系统的运行时环境，拦截应用程序的方法调用，实现隐...
博客
掌握Swift宏：深入探索SwiftSyntax与宏的实用指南
01-23 597
欢迎来到 Swift 宏的世界。我们将探索 Swift 5.9 版本中引入的一项革命性特性——宏（Macro），它为我们提供了一种在编译时处理源代码的能力。宏可以帮助我们自动化代码生成，减少模板代码，并使得代码更加简洁和易于理解。我们将从宏的基本概念开始，逐步深入了解关联宏（attached macro）和独立宏（freestanding macro）的区别与应用。接着，我们会学习如何通过 Swi...
博客
矢量图SVG应用探索
01-16 1084
随着计算机技术的不断发展，图形设计和多媒体制作领域对图像质量、可编辑性和跨平台兼容性的要求越来越高，而矢量图作为一种强大的图像类型，正好满足了这些需求。在软件开发中，基于矢量图无限缩放性、小文件体积、高度可编辑性、跨平台兼容性和透明背景等独特优势，也会被大家广泛使用。01矢量图与SVG矢量图，也称为向量图，是一种基于数学方程和几何属性的图形表示方法。它不同于位图，位图由像素组成，缩放时可能出现失真...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值