JVM性能分析 —— G1 日志分析

jvm:jvm GC日志解析:G1日志解析 1、背景简介 1.1、应用背景介绍 1)业务特点:流量高峰都集中在白天,凌晨流量很低。 2)应用特点: 对外提供了很多核心业务接口,早6点之后,流量逐渐增加。 凌晨会通过自动化调度,跑一些数据处理任务,主要都是核心业务数据的缓存预热【从DB(mysql/es)读取,写入到redis】。 1.2、jdk版本(openjdk) 由于oracle声明将针对企业用户对于JDK 8 u191之后的版本需要付费购买商业许可。所以公司统一都切换到了openjdk,目前应用的版本是:openjdk 1.8.0_272- 阅读详情

日志级别

JVM 日志级别中的 fine、finer 和 finest 这三个级别

  • fine:JVM 配置参数为 -XX:G1LogLevel=fine 或使用 -XX:+PrintGC。
    • 用于输出一些常规性的信息,不会产生太多的日志输出。
  • finer:JVM 配置参数为 -XX:G1LogLevel=finer 或使用 -XX:+PrintGCDetails。
    • 用于输出更加详细的调试信息,帮助开发人员进行问题排查。
  • finest:JVM 配置参数为 -XX:G1LogLevel=finest。
    • 用于输出非常详细的跟踪信息,会产生大量的日志输出。

G1LogLevel 是一个实验性的 VM 选项,需要先通过 -XX:+UnlockExperimentalVMOptions 参数来解锁,才能使用。所以一般使用 -XX:+PrintGC 和 -XX:+PrintGCDetails

GC 暂停类型

  1. GC pause (G1 Evacuation Pause)
    • "Evacuation Pause"是 G1 垃圾收集器在执行垃圾收集时使用的一种暂停模式。
    • 在这种模式下,G1 会先标记需要回收的对象,然后将存活对象复制到新的内存区域(称为"转移"或"疏散")。
  2. GC pause (G1 Humongous Allocation)
    • 这种暂停发生在 G1 收集器处理大对象 (Humongous Object) 时。
    • G1 会触发一个特殊的暂停来回收这些大对象。
  3. Full GC (Allocation Failure)
    • 这种暂停是在应用程序内存不足时发生的完全垃圾收集 (Full GC) 。
    • G1 无法在年轻代和老年代中找到足够的空间分配新对象时,会触发 Full GC。
  4. Full GC (System.gc())
    • 这种 Full GC 是由开发者手动触发的,通过调用 System.gc() 方法。通常不建议频繁调用 System.gc(),因为它可能会导致应用程序性能的严重下降。
    • 当开发者调用 System.gc() 时,Java 虚拟机会尝试执行一次完整的垃圾收集。这种 Full GC 与 Allocation Failure 导致的 Full GC 不同,它是由开发者主动触发的。

垃圾回收的示例代码

public class G1GCAnalysis {
   
   

    private static final int KB = 1024;
    private static final int cacheSize = 1024;
    private static Random random = new Random();

    public static void main(String[] args) throws InterruptedException {
   
   
        long startTime = System.currentTimeMillis();
        long intervalTime = TimeUnit.SECONDS.toMillis(1);
        long endTime = startTime + intervalTime;
        // 缓存数据,用户保存对象,部分晋升到老年代
        Object[] objects = new Object[cacheSize];
        // 设置循环运行1000ms
        while (System.currentTimeMillis() < endTime){
   
   
            for (int i = 0; i < 100; i++) {
   
   
                // 创建对象,部分对象在新生代被回收,部分对象会晋升到老年代再回收
                byte[] bytes = new byte[64 * KB];
                int randomIndex = random.nextInt(2 * cacheSize);
                if (randomIndex < cacheSize){
   
   
                    // 若被覆盖且原引用对象是老年代对象,制造老年代垃圾对象
                    objects[randomIndex] = bytes;
                }
            }
            // 睡眠一下,让对象多熬过几次新生代垃圾回收,以晋升到老年代
            Thread.sleep(10);
        }
    }
}

-XX:+PrintGC(简洁版)

本文分析 G1 日志,所有配置使用 G1 垃圾收集器(-XX:+UseG1GC);同时设置最大、最小堆内存为 100M(-Xms100M -Xmx100M);配置打印触发垃圾回收时的时间(-XX:+PrintGCDateStamps)。

-XX:+UseG1GC -Xms100M -Xmx100M -XX:+PrintGCDateStamps

配置 -XX:+PrintGC 日志级别

-XX:+UseG1GC -Xms100M -Xmx100M -XX:+PrintGCDateStamps -XX:+PrintGC

G1 日志输出

2024-08-07T19:05:30.973+0800: [GC pause (G1 Evacuation Pause) (young) 83M->78M(100M), 0.0010787 secs]
2024-08-07T19:05:30.989+0800: [GC pause (G1 Evacuation Pause) (young) (initial-mark) 85M->82M(100M), 0.0012699 secs]
2024-08-07T19:05:30.990+0800: [GC concurrent-root-region-scan-start]
2024-08-07T19:05:30.990+0800: [GC concurrent-root-region-scan-end, 0.0000719 secs]
2024-08-07T19:05:30.990+0800: [GC concurrent-mark-start]
2024-08-07T19:05:30.991+0800: [GC concurrent-mark-end, 0.0007155 secs]
2024-08-07T19:05:30.991+0800: [GC remark, 0.0007150 secs]
2024-08-07T19:05:30.992+0800: [GC cleanup 84M->84M(100M), 0.0003412 secs]
2024-08-07T19:05:31.004+0800: [GC pause (G1 Evacuation Pause) (young) 86M->84M(100M), 0.0012786 secs]
2024-08-07T19:05:31.005+0800: [GC pause (G1 Evacuation Pause) (mixed) 88M->81M(100M), 0.0010569 secs]
2024-08-07T19:05:31.034+0800: [GC pause (G1 Evacuation Pause) (mixed)-- 89M->91M(100M), 0.0017680 secs]
2024-08-07T19:05:31.050+0800: [GC pause (G1 Evacuation Pause) (mixed)-- 99M->100M(100M), 0.0011720 secs]
2024-08-07T19:05:31.051+0800: [Full GC (Allocation Failure)  100M->59M(100M), 0.0096012 secs]

G1 日志详解

  1. [GC pause (G1 Evacuation Pause) (young) 83M->78M(100M), 0.0010787 secs]
    • GC pause (G1 Evacuation Pause) (young) 表示 G1 收集器在年轻代进行正常垃圾收集时发生的暂停。每一次 YGC 回收整个新生代分区。
    • 83M->78M(100M) 表示垃圾收集前后,年轻代已使用内存从 83M 降低到 78M,年轻代总内存 100M。
    • 0.0010787 secs 表示这次 YGC 暂停持续了大约 1.0787 毫秒。
  2. [GC pause (G1 Evacuation Pause) (young) (initial-mark) 85M->82M(100M), 0.0012699 secs]
    • 这是 G1 收集器同时进行年轻代垃圾收集 (YGC) 和初始标记的暂停。(初始标记在 YGC 的同时完成)
    • 年轻代已使用内存从 85M 降低到 82M,年轻代总内存 100M;耗时大约 1.2699 毫秒。
    • 初始标记是 G1 收集器 GC 流程的一个重要步骤,用于快速找到标记根对象。
  3. [GC concurrent-root-region-scan-start]
    • 这表示 G1 收集器开始并发扫描根区域。
    • 并发根区域扫描可以在应用程序运行的同时快速找出哪些区域包含了根对象。
  4. [GC concurrent-root-region-scan-end, 0.0000719 secs]
    • 这表示 G1 收集器的并发根区域扫描操作已经结束。
    • 这个并发扫描根区域操作总共持续了 0.0719 毫秒。
  5. [GC concurrent-mark-start]
    • 这表示 G1 收集器开始并发标记阶段。
  6. [GC concurrent-mark-end, 0.0007155 secs]
    • 这表示 G1 收集器的并发标记操作已经结束。
    • 这个并发标记操作总共持续了 0.7155 毫秒。
  7. [GC remark, 0.0007150 secs]
    • 这表示 G1 收集器进入了 Remark(重新标记)阶段,这个阶段持续了 0.7150 毫秒。
  8. [GC cleanup 84M->84M(100M), 0.0003412 secs]
    • 这表示 G1 收集器进入了 Cleanup 清理阶段的暂停。
    • 该阶段主要作用:统计存活对象、交换标记位图、重置RSet、把空闲分区放到空闲分区列表中。
    • 清理阶段并不会清理垃圾对象,也不会执行存活对象的拷贝,所以内存几乎不会变化。
    • 堆已用内存从 84M 降为 84M,总内存为 100M,整个清理阶段持续了 0.3412 毫秒。
  9. [GC pause (G1 Evacuation Pause) (mixed) 88M->81M(100M), 0.0010569 secs]
    • 这是 G1 收集器在进行混合(年轻代和老年代)垃圾收集时发生的暂停。
    • 堆已用内存从 88M 降为 81M,总堆内存为 100M,整个 Mixed GC 持续了 1.0569 毫秒。
  10. [Full GC (Allocation Failure) 100M->59M(100M), 0.0096012 secs]
    • 这是一次完整的垃圾收集的暂停,发生在无法在年轻代和老年代找到足够内存分配新对象时。
    • 导致这次 Full GC 的原因是发生了内存分配失败(Allocation Failure)。
    • 在这个 Full GC 中,G1 会回收整个堆内存,从 100MB 压缩到 59MB,整个 Full GC 操作持续了约 9.6 毫秒。

-XX:+PrintGCDetails(详细版)

配置 -XX:+PrintGCDetails 日志级别

-XX:+UseG1GC -Xms100M -Xmx100M -XX:+PrintGCDateStamps -XX:+PrintGCDetails

G1 日志输出

-XX:+PrintGCDetails 日志级别统计GC线程整体工作情况,-XX:G1LogLevel=finest 日志级别除了输出GC线程统计信息外,还会输出每个GC线程的工作情况,-XX:G1LogLevel=finest 日志级别输出信息包含 -XX:+PrintGCDetails 日志级别的输出信息,所以在下面介绍 -XX:G1LogLevel=finest 时进行每行日志的详细解释。可以直接跳转到 -XX:G1LogLevel=finest 一节。

2024-08-07T19:25:46.191+0800: [GC pause (G1 Evacuation Pause) (young), 0.0013358 secs]
   [Parallel Time: 0.7 ms, GC Workers: 13]
      [GC Worker Start (ms): Min: 930.5, Avg: 930.7, Max: 931.0, Diff: 0.6]
      [Ext Root Scanning (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 1.3]
      [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.4]
         [Processed Buffers: Min: 0, Avg: 0.6, Max: 2, Diff: 2, Sum: 8]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 0.0, Avg: 0.2, Max: 0.3, Diff: 0.3, Sum: 3.2]
      [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.2]
         [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 13]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [GC Worker Total (ms): Min: 0.1, Avg: 0.4, Max: 0.6, Diff: 0.6, Sum: 5.4]
      [GC Worker End (ms): Min: 931.1, Avg: 931.1, Max: 931.1, Diff: 0.0]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.1 ms]
   [Other: 0.5 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.1 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.1 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.0 ms]
   [Eden: 7168.0K(7168.0K)->0.0B(5120.0K) Survivors: 1024.0K->1024.0K Heap: 85.4M(100.0M)->81.8M(100.0M)]
 [Times: user=0.00 sys=0.00, real=0.00 secs] 
 
2024-08-07T19:25:46.206+0800: [GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0008776 secs]
   [Parallel Time: 0.5 ms, GC Workers: 13]
      [GC Worker Start (ms): Min: 945.0, Avg: 945.0, Max: 945.1, Diff: 0.1]
      [Ext Root Scanning (ms): Min: 0.1, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 1.4]
      [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.3]
         [Processed Buffers: Min: 0, Avg: 0.7, Max: 1, Diff: 1, Sum: 9]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 0.2, Avg: 0.2, Max: 0.3, Diff: 0.1, Sum: 3.2]
      [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.2]
         [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 13]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [GC Worker Total (ms): Min: 0.4, Avg: 0.4, Max: 0.4, Diff: 0.1, Sum: 5.2]
      [GC Worker End (ms): Min: 945.4, Avg: 945.4, Max: 945.4, Diff: 0.0]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.1 ms]
   [Other: 0.3 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.1 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.1 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.0 ms]
   [Eden: 5120.0K(5120.0K)->0.0B(4096.0K) Survivors: 1024.0K->1024.0K Heap: 86.8M(100.0M)->84.2M(100.0M)]
 [Times: user=0.00 sys=0.00, real=0.00 secs] 
2024-08-07T19:25:46.207+0800: [GC concurrent-root-region-scan-start]
2024-08-07T19:25:46.207+0800: [GC concurrent-root-region-scan-end, 0.0000562 secs]
2024-08-07T19:25:46.207+0800: [GC concurrent-mark-start]
JVM从入门到精通(十一): CMS日志详解,G1日志详解,JVM常见参数总结;补充纤程知识 CMS 日志格式分析 使用CMS:添加参数UserConcMarkSweepGC(CMS+ParNew) CMS常用参数 -XX:+UseConcMarkSweepGC -XX:ParallelCMSThreads CMS线程数量 -XX:CMSInitiatingOccupancyFraction 使用多少比例的老年代后开始CMS收集,默认是68%(近似值),如果频繁发生SerialOld卡顿,应该调小,(但是调小的缺点是频繁CMS回收),这个参数可能会问到,你不背下来,只要知道有这么个参数可以调,就 阅读详情

相关推荐

IDEA内存优化全攻略:从JVM参数到插件索引,彻底解决卡顿

IntelliJ IDEA 作为 Java 开发者最常用的 IDE,其底层 JVM 内存管理机制直接影响开发体验。理解堆内存、元空间与代码缓存的分工,是定位“卡顿、OOM”等问题的前提。合理调整 -Xmx 等 JVM 参数,配合 G1 垃圾回收器的停顿目标设置,能显著提升大项目下的响应速度。在此基础上,插件瘦身与索引缓存管理同样关键,很多“内存爆红”其实源于后台插件和过期索引而非堆大小不足。同时借助 GC 日志验证 Full GC 频率,可以避免盲目调参。无论是单模块 Maven 项目还是多微服务并行加载,

weixin_28829629的博客 213

java虚拟机——如何排查jvm问题

排查JVM问题需要综合使用多种工具和方法,从监控、日志分析、性能分析、线程分析、垃圾收集分析等多个角度入手。通过这些步骤,你可以更全面地了解和解决JVM相关的各种问题。

oopxiajun博客专栏 1198

Java日志分析工具:12种“百宝箱”全解析

🔥关注墨瑾轩,带你探索编程的奥秘!🚀🔥超萌技术攻略,轻松晋级编程高手🚀🔥技术宝库已备好,就等你来挖掘🚀🔥订阅墨瑾轩,智趣学习不孤单🚀🔥即刻启航,编程之旅更有趣🚀。

java专栏 1450

JVM第7篇-性能监控 & JVM性能调优案例

性能监控一、JVM监控及诊断工具-命令行篇1.1 基础故障处理工具1.1.1 jps: 虚拟机进程状况工具命令格式使用1.1.2 jstat: 虚拟机统计信息监视工具命令格式使用1.1.3 jinfo: Java配置信息工具命令格式使用1.1.4 jmap: Java内存映像分析工具命令格式1.1.5 jstack: Java堆栈跟踪工具命令格式使用二、JVM监控及诊断工具-GUI篇三、JVM运行时参数四、调优概述4.1 生产环境中的问题4.2 调优基本问题为什么要调优?调优的大方向不同阶段的考虑总结4.3

qq_43478625的博客 2399

Minecraft 1.20.1 Forge服务器进阶部署指南:从MCSM面板配置到性能调优

本文详细介绍了Minecraft 1.20.1 Forge服务器的高级部署与性能优化技巧,涵盖MCSM面板的多实例管理、定时任务和文件同步功能,以及JVM参数调优、高负载场景优化和崩溃排查方法。通过实战案例和配置建议,帮助管理员提升服务器稳定性和玩家体验。

weixin_31102231的博客 313

后端开发:Spring Boot的性能分析与调优工具

A: 需要任务排队时用ArrayBlockingQueue,需要无限队列用SynchronousQueue。A: 根据对象晋升模式计算,推荐占堆内存1/4到1/3。Q: 线程池队列应该用Array还是Linked?Q: 如何选择Young区大小?

架构师的AI之路,分享AI应用开发架构的学习与实践。 1039

jvm调优 详细 多个案例分析

什么时候需要调优

qq_39989608的博客 3646

JVM虚拟机:G1垃圾回收器的日志分析

本文我们将学习G1垃圾回收器的日志。

huanfeng_AI的博客 966

Java领域JVM的垃圾回收日志分析

本文旨在为Java开发者提供全面的JVM垃圾回收日志分析指南。我们将覆盖从基础概念到高级分析技术的所有内容,包括如何启用GC日志、解读日志内容、识别性能问题以及基于日志进行调优。文章首先介绍GC基础概念,然后深入分析各种GC算法的日志格式,接着讲解日志分析工具和实际案例,最后探讨高级分析技巧和未来发展趋势。: Java虚拟机,执行Java字节码的运行时环境: 垃圾回收,自动内存管理机制Heap: 堆内存,存储对象实例的内存区域: 新生代,存放新创建对象的内存区域。

AI开发架构师 1031

JVM高频面试基本问题与知识点整理

JVM高频面试基本问题与知识点整理

曾经“等你生日那天”都遥远得像未来,如今却可欢愉的挥手说“下个十年见” 87万+

程序跑得慢,是你代码不行,还是 JVM 在拖后腿?——Java 性能调优全揭秘!

我代码写得明明很优雅,怎么跑起来比乌龟还慢?老板拍你肩膀说:调下性能呗。你内心咆哮:“我又不是李佳琦,调性能我说得快它就快吗?今天我们就来深扒一波 Java 的性能优化,从工具用法、JVM 调优、GC 选择、再到多线程并发,聊点“能真救命”的干货,不搞玄学、只谈实战!// 糟糕:无界队列 + 核心线程少并搭配监控工具如 Micrometer + Prometheus 实时观测线程池活跃情况。调优的核心不是“调几个参数”或者“疯狂加缓存”,而是要建立监控 → 诊断 → 分析 → 验证的闭环。

喵手的博客 649

Java虚拟机垃圾回收算法的优化与性能分析

Java的垃圾回收机制通过自动管理内存释放,避免了开发者手动管理内存的麻烦。JVM使用不同的垃圾回收算法来实现这一过程。Serial GC:单线程垃圾回收,适用于单核机器或内存较小的系统。:多线程垃圾回收,适用于多核机器,可以更好地利用计算资源。:并发标记-清除算法,减少了STW(Stop-The-World)时间,适用于对响应时间敏感的应用。G1 GC:Garbage-First回收器,能够同时优化堆的管理和GC暂停时间,是一种综合性强的垃圾回收器。

shrgegrb的博客 1077

Java面试题超详细讲解系列之四【Jvm篇】

Java面试题超详细讲解系列【jvm篇】,专栏持续更新

白大锅的博客,毕设WangLoveBai_999 7203

JVM虚拟机监控及性能调优实战!

哈喽,各位小伙伴们,你们好呀,我是喵手。运营社区:C站/掘金/腾讯云/阿里云/华为云/51CTO;欢迎大家常来逛逛

喵手的博客 1183

JVM 参数调优指南_优化 Java 应用性能

JVM 参数调优是指通过调整 Java 虚拟机的各种参数,以优化 Java 应用程序的性能和稳定性。

九天的专栏 1057

以LAN8720A为例的以太网硬件设计方案

输入时钟(XTAL1/CLKIN,XTAL2):推荐外加25MHz(性价比较高)晶振为PHY芯片提供时钟,PHY芯片内部PLL将其倍频为50MHz来使用,亦可使用直接使用50MHz晶振。三位MODE通过高低电平组合分别对应以上8种模式 ,包含10M半双工,10M全双工,100M半双工,100M全双工,是否启用自协商协议,CRS是否有效等。VDDCR:1.2V电源,可由芯片内部稳压电源提供,亦可由外部电源提供,由外部电源提供可降低芯片功耗。REF_CLK:参考时钟,由MAC或外部时钟晶振向PHY芯片提供。

weixin_46154042的博客 5882

USRP X410 MPM版本与主机UHD版本不匹配问题记录与解决

至此大功告成!之前安装软件的坑算是填起来了,再次记录一下,希望能帮到有同样问题的小伙伴~

yanzuwu233的博客 1433

dify案例-基于Dify打造智能合同审查助手:零代码搭建工作流全指南

Dify的工作流(Workflow)功能是一个可视化流程编排工具,允许用户通过拖拽节点的方式构建复杂的AI应用。与简单的问答应用不同,工作流支持多步骤任务处理、条件分支、并行执行等高级功能,非常适合合同审查这类结构化任务。可视化编排:无需编写代码,通过拖拽连接节点即可构建复杂流程多模型协作:可在不同节点使用最适合的AI模型灵活集成:支持知识库检索、条件判断、API调用等多种节点类型迭代优化:可随时测试和调整单个节点,不影响整体流程可视化搭建:无需编码经验,拖拽式构建复杂审查流程灵活扩展。

weixin_44245188的博客 1939

保姆级教程:用Python spatialdata框架搞定10x Xenium空间转录组数据(从下机到高级分析)

本教程详细介绍了如何使用Python spatialdata框架处理10x Xenium空间转录组数据,从数据获取到高级分析的全流程。涵盖环境配置、数据读取、质量控制、降维聚类、细胞注释及空间共定位分析等关键步骤,特别适合生物信息学研究者快速掌握Xenium数据分析技术。

weixin_30300225的博客 480

ESD放电路径分析

当金属外壳接地情况下,大部分外部干扰信号将会通过外壳,外壳到接地点,再由接地点回到干扰信号的地,实现干扰信号的回流,这点不仅仅适用于​ESD,对于其他的RI类干扰,也同样适合。发现内部金属板跟外壳的搭接处存在较多的缝隙点,该缝隙点对于频率较高的信号能够实现较为理想的回流,但是对于频率没有那么高的信号,则较难以实现回流,我们尝试将这些缝隙用铜箔包裹住,充分降低该金属板跟外壳的接触阻抗​。我们分析,路径3其实是不期望的路径,我们最期望的路径是1,或者2的内部金属部件跟外壳良好接触情况下的路径。

domen_pan的博客 2226

RobotFramework二次开发——实时日志

背景基于RobotFramework的二次开发,少不了要打印实时日志出来,比如广泛应用的工具ride中,在执行用例时会把执行过程中的log全部打印出来,如果二次开发的时候,执行用例只能静默等待执行完毕,那只能算是一个半成品。结果在最后,不想看过程的可以直接跳到最后思路RobotFramework的日志有好几种,一个是执行后的log文件,这个文件可以作为数据留存,但是没办法实时获取,因为文件是在执行完

点点寒彬的博客 1万+

APP签名验证全栈破解:Frida Hook绕过+算法逆向+Python一键调用(附可运行脚本)

做过APP逆向和爬虫的同学,肯定都被签名验证折磨过:改了一行代码重新打包,APP直接闪退;抓包看到接口有个sign参数,翻遍JS找不到加密逻辑;好不容易找到加密函数,一调用就崩溃。客户端APK签名校验服务端接口签名验证。前者防止你篡改APP,后者防止你伪造请求。很多人卡在第一步,改完APK就闪退,根本没机会碰接口。本文基于真实项目实战,分享一套通用的签名验证破解方案。从客户端APK签名校验的Frida Hook绕过,到服务端sign算法的逆向还原,最后用Python实现一键调用。

专注于Python爬虫开发,分享爬虫技巧、项目实战与反爬经验,使用Scrapy、BeautifulSoup等工具,解决数据抓取难题。 962

2、欧洲期权的赫斯顿模型

本文详细介绍了赫斯顿随机波动率模型在欧洲期权定价中的应用。模型通过引入随机方差过程,克服了布莱克-斯科尔斯模型中波动率恒定的局限性,更贴近市场实际。文章阐述了模型的动态结构、风险中性转换、期权定价公式及其半封闭解的计算方法,并提供了基于VBA的数值实现方案。通过梯形法则与高斯积分等数值方法对比,分析了不同积分策略的精度与效率。同时验证了当波动率为零时,赫斯顿模型退化为布莱克-斯科尔斯模型的一致性。最后讨论了模型的优势、挑战及实际应用建议,强调了数值积分稳定性和参数估计的重要性。

tequila的博客 348

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

STM32F407中文手册

STM32f407中文手册 本参考手册面向应用开发人员,提供有关使用 STM32F405xx/07xx、STM32F415xx/17xx、 STM32F42xxx 和 STM32F43xxx 微控制器存储器与外设的完整信息。STM32F405xx/07xx、STM32F415xx/17xx、STM32F42xxx 和 STM32F43xxx 构成一个微 控制器系列,各产品具有不同的存储器大小、封装和外设。有关订购信息以及器件的机械与电气特性,请参见数据手册。有关 ARM Cortex™-M4F 内核的信息,请参见《Cortex™-M4F 技术参考手册》。

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

上一篇: JVM性能分析—— 一文带你读懂 G1 垃圾收集器收集流程
下一篇: Linux 命令 —— ps命令(快照查看进程信息)
ShareBeHappy_Qin
博客等级 码龄9年 2321粉丝 137原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值