能对比测试为了直观地感受Disruptor有多快，设计了一个性能对比测试：Producer发布1亿次事件，从发布第一个事件开始计时，捕捉Consumer处理完所有事件的耗时。测试用例在Producer如何将事件通知到Consumer的实现方式上，设计了两种不同的实现：Producer的事件发布和Consumer的事件处理在不同的线程，通过ArrayBlockingQueue传递给Consumer进行处理；Producer的事件发布和Consumer的事件处理在不同的线程，通过Disruptor传递给Consumer进行处理；3.1代码实现3.1.1计算代码进行CAS累加运算publicclas
原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。简介最近，我们系统配置了GC耗时的监控，但配置上之后，系统会偶尔出现GC耗时大于1s的报警，排查花了一些力气，故在这里分享下。发现问题我们系统分多个环境部署，出现GC长耗时的是俄罗斯环境，其它环境没有这个问题，这里比较奇怪的是，俄罗斯环境是流量最低的一个环境，而且大多数GC长耗时发生在深夜。发现报警后，我立马查看了GC日志，如下： 日志中出现了to-spaceexhausted，经过一番了解，出现这个是由于g1在做gc时，都是先复制存活对象，再回收原region，当没有空闲空间复制存活对象时，就会出现to-space
原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。简介最近，我们系统配置了GC耗时的监控，但配置上之后，系统会偶尔出现GC耗时大于1s的报警，排查花了一些力气，故在这里分享下。发现问题我们系统分多个环境部署，出现GC长耗时的是俄罗斯环境，其它环境没有这个问题，这里比较奇怪的是，俄罗斯环境是流量最低的一个环境，而且大多数GC长耗时发生在深夜。发现报警后，我立马查看了GC日志，如下： 日志中出现了to-spaceexhausted，经过一番了解，出现这个是由于g1在做gc时，都是先复制存活对象，再回收原region，当没有空闲空间复制存活对象时，就会出现to-space
大家好，我是二哥呀！昨天，一位球友问我能不能给他解释一下@SpringBootApplication注解是什么意思，还有SpringBoot的运行原理，于是我就带着他扒拉了一下这个注解的源码，还有SpringApplication类的run()方法的源码，一下子他就明白了。你别说，看源码的过程还真的是挺有趣，这不，我就发现了一个有意思的点。publicConfigurableApplicationContextrun(String...args){ StopWatchstopWatch=newStopWatch(); stopWatch.start(); ...... stopWatch.st
大家好，我是二哥呀！昨天，一位球友问我能不能给他解释一下@SpringBootApplication注解是什么意思，还有SpringBoot的运行原理，于是我就带着他扒拉了一下这个注解的源码，还有SpringApplication类的run()方法的源码，一下子他就明白了。你别说，看源码的过程还真的是挺有趣，这不，我就发现了一个有意思的点。publicConfigurableApplicationContextrun(String...args){ StopWatchstopWatch=newStopWatch(); stopWatch.start(); ...... stopWatch.st
前言最近群里遇到获取Route名为空的问题，当时没在意。。。直到自己在监控页面启动耗时，需要确定当前页面是哪个从而方便标记它加载的耗时时，遇到同样route.settings.name为空问题，模拟场景如下：在main.dart页面中点击+按钮跳转到TestPage2页面。M
前言最近群里遇到获取Route名为空的问题，当时没在意。。。直到自己在监控页面启动耗时，需要确定当前页面是哪个从而方便标记它加载的耗时时，遇到同样route.settings.name为空问题，模拟场景如下：在main.dart页面中点击+按钮跳转到TestPage2页面。M
作者｜许斌斌背景经过长期的业务迭代，C端工程增量编译已经严重劣化，2021年12月前，C端平均增量编译长达3分钟以上，严重影响研发效率，急需优化！经过优化之后，增量编译时长降低到2分钟左右。分析幸福里app编译过程主要耗时分析全量编译：pod编译占用大部分时间，多达数百秒，CI打包需要20到30分钟。增量编译：link、资源处理占用大部分耗时（C端工程优化前该部分占用130s耗时）。方案LLVM编译优化LLVM编译过程.m文件编译从点.o文件依次经历以下阶段:预处理：去掉注释、替换宏定义、添加行号和文件标识词法分析：将代码切成一个个token语法分析：验证语法是否正确，生成语义节点生成AST：
作者｜许斌斌背景经过长期的业务迭代，C端工程增量编译已经严重劣化，2021年12月前，C端平均增量编译长达3分钟以上，严重影响研发效率，急需优化！经过优化之后，增量编译时长降低到2分钟左右。分析幸福里app编译过程主要耗时分析全量编译：pod编译占用大部分时间，多达数百秒，CI打包需要20到30分钟。增量编译：link、资源处理占用大部分耗时（C端工程优化前该部分占用130s耗时）。方案LLVM编译优化LLVM编译过程.m文件编译从点.o文件依次经历以下阶段:预处理：去掉注释、替换宏定义、添加行号和文件标识词法分析：将代码切成一个个token语法分析：验证语法是否正确，生成语义节点生成AST：
大家好，欢迎来到Crossin的编程教室~几天不见，Crossin又去做什么游戏去了呢？这次我做的不是游戏，而是游戏机！而且是体感游戏机。说到体感游戏，现在大家可能最多想到的是switch上的健身环大冒险。 但往前几年，其实还有另一个非常火的体感游戏设备，就是xbox上的kinect。和switch用带有传感器的手柄来识别玩家动作不同，kinect使用的是一组摄像头，通过图像来识别玩家的动作。我这次做的demo，就是一个使用摄像头的动作识别系统。理论上来说，这个识别系统只需要普通的电脑和普通的摄像头就可以运行。不过我最近正好拿到一样好东西，它可以让我这次的开发效率和运行效率都大大提高。这就是我
