xiaocai

本例和上例的执行结果完全相同。

现在我也仍然在学习.Net 和java。在工作上使用的是.Net ，回来看的视频教程是Java，我想通过java来更深入的了解一些底层一点的机制，学习更新的技术。也是因为java的教程确实比.Net更加丰富，生态会更好一点，不可否认！但我依然喜爱这C#这门十分优雅的语言，喜欢它无处不在的语法糖！在工作上也仍然会继续深入研究它！不要纠结于语言，主要是编程思想和学习方法。

使用 Hash 是有代价的，底层如果是 hashtable 实现的话，会多用 25% 内存空间，毕竟空间换时间嘛key 最好不用原始的字符串，更有胜者，长短不一，导致内存碎片，占用空间情况更加严重部分开发者喜欢原始字符串加 MD5 后得到 32 位字符，解决了内存碎片问题，但是相比于编码是 int 类型，emstr 更占用空间，毕竟前者只需固定 8 个字节如上value。

一个小小的正则表达式竟然能够把 CPU 拖垮，也是很神奇了。这也给平时写程序的我们一个警醒，遇到正则表达式的时候要注意贪婪模式和回溯问题，否则我们每写的一个表达式都是一个雷。

事实证明，读过Linux内核源码确实有很大的好处，尤其在处理问题的时刻。当你看到报错的那一瞬间，就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔者读过一些Linux TCP协议栈的源码，就在解决下面这个问题的时候有一种非常流畅的感觉。应用再强大也还是承载在内核之上，始终逃不出Linux内核的樊笼。所以对于Linux内核本身参数的调优还是非常有意义的。如果读过一些内核源码，无疑对我们排查线上问题有着很大的助力，同时也能指导我们避过一些坑！

好久不见，我叫阿Q，是CPU一号车间的员工。我所在的CPU有8个车间，也就是8个核心，咱们每个核心都可以同时执行两个线程，就是8核16线程，那速度杠杠滴。我所在的一号车间，除了负责执行指令的我，还有负责读取指令的小A，负责指令译码的小胖和负责结果回写的老K，我们几个各司其职，一起完成执行程序的工作。

每次启动SpringBoot项目时，总是能看到控制台打印了一串字符，隐约能辨认出是“Spring”，不知大家是否也好奇过是怎么实现的，是直接打印固定的字符串，还是根据什么算法去生成的？于是闲暇无事，探究一番。只想修改banner可以跳到文末查看。

1，对于抓包分析，还是疏忽了，加上包限制大小，能很好的防止tcpdump抓包时丢包的情况。2，对于任何第三方的说法要有自己的判断力，像这次如果中途去将磁盘扩容显然是不能解决问题的。3，性能问题分析真是像一个侦探破案的过程，不断列出证据，不断排除掉干扰因素，不断论证的过程也是性能分析的魅力所在吧，就像这次看到cpu的确比较高了，但是究竟是不是客户端问题呢？我又抓包论证了的确是客户端问题，那究竟是不是协程调度问题呢？我又列出协程调度延迟。

PCL包含点云滤波、特征估计、三维重建、点云配准、模型拟合、目标识别和分割等算法。我这里下载到的路径是：（通过 ⌘command + ⇧shift + . 打开隐藏软件视图）/usr/local/Cellar 下（这在后面的配置中很重要）添加对应路径：（我们只需要添加最后两个即可，eigen 是用于解决 #include 的路径问题。因为 PCL 是新下载的，如果我们不把路径告诉 VS Code 的话，就会在 include 的位置，出现特别折磨的红色波浪线。

在刚刚，我们使用Mockito的时候，是没有依赖Spring环境的，对象都是Mock出来的，速度杠杠的，非常快。比如，我在写service层的单元测试，我认为dao层的代码是正常的，但是service是需要dao的对象访问数据库的，这时候我Mock出dao的模拟对象，去调用方法。单元测试是我自己写的，我Mock出来模拟对象再Stub，整个过程中我都是认为我写的代码是正确的。对于我这种不怎么写单元测试的，也不爱写单元测试的，在我的嘴里自然就编不出要写单元测试的理由了，倒是不写单元测试的理由是一堆堆的。

其中的技术总监，平时的工作时和客户去谈需求，然后把需求拆分成若干个模块让手下人开发，由于小公司的技术栈并不复杂，也就用到spring boot+数据库，外带些logback写日志等的组件，所以一些刚毕业的程序员，只要在大公司里呆个2，3年，都能达到这个程度。按21年22年的行情，我见过的不少小公司技术总监，年薪基本没有过40w的，一般也月入3w就不错了，毕竟小公司盈利能力有限，抗风险的能力也有限，一般给不了高薪，但如果去大公司，一个30岁的程序员要个月薪3w问题不大。

很遗憾，默认情况下，这是做不到的，任务一旦被注册和执行，用于注册的参数便被固定下来，这是不可变的部分。于是乎，我们的思路便是，在注册期间保留任务的关键信息，并通过另一个定时任务检查配置是否发生变化，如果有变化，就把“前任”干掉，取而代之。fixedRate(period)：固定频率执行，从任务启动之后，总是在固定的时刻执行，如果因为执行时间过长，造成错过某个时刻的执行（晚点），则任务会被立刻执行。fixedDelay(period)：固定间隔时间执行，无论任务执行长短，两次任务执行的间隔总是相同的。

然后在IDEA中创建一个新项目，依次点击“文件”（File），“项目结构”（Project Structure），“组件”（Modules），“依赖项”（Dependencies），再点击右方绿色“+”下的第一个选项“JAR文件或路径”（JARs or Directories），找到之前解压好的文件，并将其中的lib文件夹下的Spire.Doc.jar文件导入到项目中。如果您使用的是maven，可以直接通过添加以下代码到项目的 pom.xml 文件中，从而将 JAR 文件导入到应用程序中。

这里再说个可能会引发争议的观点，比如某程序员，学历可能是大专甚至更低，在一家小公司里做java后端，也干了5，6年，但如果技术层面只是做增删改查，可能这位程序员凭借对业务和产品的了解，在小组里甚至是公司里起到比较重要的作用，但从技术角度来说依然是初级开发，因为如果出去面试，很难展示比增删改查更值钱的技能。高级开发在公司里，可能未必能做到项目经理的级别，但在带人开发的时候，需要全面掌握项目测试部署的技能，而一些初级开发解决不了的问题，比如分布式组件方面的问题，高级开发能解决。大概是有3年Java开发经验。

这是一个细微的差异，仅会导致一年左右的变更问题，因此您的代码本可以一直正常运行，而仅在新的一年中引发问题。下面是源码Objects.equals()，其中a.equals(b)使用的是Long.equals()会判断对象类型，因为编译器已经认为常量是int类型，所以比较结果一定是false。因为使用了线程池，线程是可以复用的，所以在使用ThreadLocal获取用户信息的时候，很可能会误获取到别人的信息。在我们日常的开发中，经常需要对日期进行格式化，但是很多人使用的格式不对，导致出现意想不到的情况。

本文介绍在USGS网站批量下载Landsat系列遥感影像的方法。

然后在开始历史数据全量同步，当历史全量数据同步完成后，在开启消费 kafka 消息进行增量数据同步（提高全量同步效率减少积压也是关键的一环），这样来保证迁移数据过程中的数据一致。需要注意的是：业务中是否有使用数据库自增 ID 做为业务 ID 使用的，如果有需要业务先进行改造。首先将 [0-1023] 平均分为4个区段：[0-255]，[256-511]，[512-767]，[768-1023]，然后对字符串（或子串，由用户自定义）做 hash， hash 结果对 1024 取模，最终得出的结果。

在服务器的文件系统上有一个业务生成的BigTable.json文件，其可能包含的JSON字符串很大，同时里边的集合会包含很多的记录；我们使用以下的代码来反序列化，虽然使用了异步的ReadAllTextAsync来读取文件，但是还是需要将整个的文件内容都读取到内存中，这样会极大的占用服务器内存，同时分配太多对象或分配非常大的对象会导致垃圾收集减慢甚至停止应用程序；通过以上分析，我们可以直接使用二进制的文件流来读取文件，并将它传递给JsonTextReader，这样就可以实现小片段的读取并序列化；

跳表的时间复杂度与AVL树和红黑树相同，可以达到O(logN)，但是AVL树要维持高度的平衡，红黑树要维持高度的近似平衡，这都会导致插入或者删除节点时的一些时间开销，所以跳表相较于AVL树和红黑树来说，省去了维持高度的平衡的时间开销，但是相应的也付出了更多的空间来存储多个层的节点，所以跳表是用空间换时间的数据结构。每一个元素添加到跳表中时，首先需要随机指定这个元素在跳表中的层数，如果随机指定的层数大于了跳表的层数，则在将元素添加到跳表中之前，还需要扩大跳表的层数，而扩大跳表的层数就是将头尾节点的层数扩大。

这部分也就是其他技术贴没讲解的部分，因此这里我们来补充一下这个话题，背过八股们的小伙伴都知道Spring事务是居于AOP实现，从这个角度很容易会理解到这个问题，当我们将两个Service方法放在同一个Transactional下的时候，这个代理对象就是当前类，因此导致数据源对象也是当前类下的DataSource，导致就出现表不存在问题，当Transactional分别放在不同Service的时候没有这种情况。

线程池的运用在项目中已经成为一种常态，作为一个开发人员最重要的了解其背后的设计原理以及流程，更好地运用线程池，方便提升项目程序的性能以及排查错误。因为我们是在受不了有些人动不动就去创建一个线程，使用的多了以后，一旦报错就只有一个线程报错信息，还是线程的共用信息，再加上如果你将异常吃了(捕获后不做处理)的情况下，这个错误。其实就是一个容错机制，当你的需要执行的线程个数已经爆满并且超过的时候，提供了一个容错机制，可以保证在短期内多余的任务正常执行。当所有核心线程都正在工作时，将其放入阻塞队列，等待后续执行。

另外要注意的是，用来修饰 Job 类的特性DisallowConcurrentExecution，其实约束的是 JobDetail，即对于 JobDetail-A，同一时间，只能有一个 Job 使用它。上述代码中变量 job 的类型并非IJob，而是IJobDetail，也就是说，Quartz.Net 调度维持的是 IJobDetail 实例，而 Job 实例，是在每次任务执行的时间点实例化的，执行完就销毁，实例状态并不能延续，需要借助 IJobDetail 实例存取每次执行后更新的状态。

学术界的 SOTA 模型在落地部署到工业界应用到过程中，通常是要面临着低延迟（Latency）、高吞吐（Throughpout）、高效率（Efficiency）挑战的。而模型压缩算法可以将一个庞大而复杂的预训练模型转化为一个精简的小模型，从而减少对硬件的存储、带宽和计算需求，以达到加速模型推理和落地的目的。模型剪枝的原理是通过剔除模型中 “不重要” 的权重，使得模型减少参数量和计算量，同时尽量保证模型的精度不受影响。因为本质是通过委托来获取服务，所以我们可以通过配置来改变委托的行为，如下。

我们在嵌入式开发的过程中，经常可以碰到在一些宏定义或者是代码段中使用了do {...} while(0)的语句，从语义上理解，do {...} while(0)内的逻辑就只执行一次，并没有循环执行，粗略看来，似乎画蛇添足了，那么为什么还需要在只执行一次的逻辑外面加上一层do {...} while(0)语句呢？但是在编译的时候，这些空宏可能会给出warning，为了避免这样的warning，我们可以使用do{...}while(0)来定义空宏，这种情况不太常见，因为有很多编译器已经支持空宏。

通过以上的代码分析，我们看出sync.Map的这个机制，是一个想追求无锁读写的结构，它最好的运行方式是读永远都命中read，写只命中dirty，这用能不用任何锁机制就能做到map读写。首先，第一次判断read中是否有key的时候是没有加锁的，所以当第一次判断结束后，一旦明确read中没有key，要做后续的操作之前，先做一次加锁操作，做完加锁操作之后，又判断了一次key是否在read中。官方的map并不是线程安全的，如果我们在多线程中并发对一个map进行读写操作，是会引发panic的。

因为“修复bug”是一个技术性问题，这个对不同人的差异其实是很小的，因为程序员们每天在写的代码都是差不多的，非常同质化的，况且还有标准答案“文档”可以参考。但是外部环境在不断变化，新事物总会被动的需要去接纳（技术的更新越来越快，趋势不可逆），然而对新事物的接受能力又得不到锻炼，一旦遇到这种情况，在接触新事物的时候会产生更多的问题（欠下的债总要还的）。所以，Z哥想来带你好好分析一下这个事情，当你再遇到这个情况的时候，可以拿这些观点来反驳（不是做技术的也可以了解下程序员的难处，谁没个难处呢，多多包容）

不过，在钉钉子之前，我们应该倾听一下他那痛苦的心声：接口返回的错误码实在是杂乱无章，光“用户不存在”的错误码就有八个，说不定未来还会增加。所以你可能在多个地方看到“卡余额不足”的错误，但每个的错误码都不同（可能是不同的人写的，也可能是同一个开发人员在不同时期写的，甚至是同一个人在同一天写的，写的时候完全看心情）。所以你可能在多个地方看到“卡余额不足”的错误，但每个的错误码都不同（可能是不同的人写的，也可能是同一个开发人员在不同时期写的，甚至是同一个人在同一天写的，写的时候完全看心情）。

之前项目中一直使用ConcurrentLinkedQueue做为缓冲队列（主要是单个项目内，单条改批量的场景，多个项目间使用的是rocketmq），虽然用着方便但是是纯内存的，SMQ使用时只有三个方法，向队列放入数据、从队列取出数据、获取队列大小（一般只在监控队列是否积压时使用，判断队列是否有数据，使用获取队列数据是否为null进行判断）。4、添加了内存队列，这个主要解决同一个机器创建了大量队列（上千）时，队列消息消费较快，因为使用了内存映射磁盘（每隔10ms就会调用force()同步磁盘），

也就是说我们可以在自己的 jar 中配置 spring.factories 文件，不会影响到其它地方的配置，也不会被别人的配置覆盖。以上内容是springboot获得这些类的方式，如果你想要实现自己的自动配置，就将你的类通过键值对的方式写在你的spring.factories即可，注意，值是你的自动配置类，键必须是org.springframework.boot.autoconfigure.EnableAutoConfiguration。这种扩展机制实际上是仿照Java中的SPI扩展机制来实现的。

注意，我是宕机，不可控力，断电了兄弟，通知不了的。比方说 A线程在锁方法中调用了 x()方法，而 x()方法中也有获取锁的逻辑，如果 A线程获取锁后，执行过程中，到 x()方法时，这把锁是要重入进去的，但是请注意，这把锁的超时时间如果小于第一次上锁的时间，比方说 A线程设置的超时时间是 1s，在 100ms的时候执行到 x()方法中，而 x()方法中设置的超时时间是 100ms，那么意味着 100ms之后锁就释放了，而这个时候我的 A线程的主方法还没有执行完呢！这个时候，我们的锁的数据结构就要改变一下了。

虽然基于MQ这个方式走不通了，但是这个项目中使用到Redis，所以我就想是否能够使用Redis来代替MQ实现延迟队列的功能，于是我就查了一下有没有现成可用的方案，别说，还真给我查到了两种方案，并且我还仔细研究对比了这两个方案，发现要想很好的实现延迟队列，并不简单。到这我终于明白了，上面的例子中即使我设置了5s的过期时间，但是当5s过去之后，只要两种清除策略都不满足，没人访问sanyou这个key，后台的定时清理的任务也没扫描到sanyou这个key，那么就不会发布key过期的事件，自然而然也就监听不到了。

ChatGPT：为了使根茎显示为立体的效果，我们可以通过在根茎上绘制一些额外的矩形来实现。运行这段代码可以看到一朵带有层次感的全红色的带有立体的绿色根茎的玫瑰花。运行这段代码可以看到一朵带有绿色根茎的红色玫瑰花，根茎和花瓣连在一起。我：运行起来看着是烟花了，麻烦打印出带根茎的玫瑰花，花颜色是红色的。运行这段代码可以看到一朵带有层次感的全红色的带有绿色根茎的玫瑰花。ChatGPT：对不起，这是我的错误。运行这段代码可以看到一朵全红色的带有绿色根茎的玫瑰花。运行这段代码可以看到一朵带有绿色根茎的红色玫瑰花。

本文主要介绍了DTM的Saga模式的应用，基于DTM 首创的子事务屏障技术，使得开发者基于DTM 提供的SDK能够轻松开发出更可靠的分布式应用，彻底将开发人员从网络异常的处理中解放出来，再也不用担心空补偿、防悬挂、幂等等分布式问题。TM-事务管理器接收到注册的全局事务和子事务后，负责调用RM-资源管理器来执行对应的事务分支，TM-事务管理器根据事务分支的执行结果决定是否提及或回滚事务。AP-应用程序：AP是一个应用服务，负责全局事务的编排，他会注册全局事务，注册子事务，调用RM接口。

使用 SpringBoot 提供 api 的时候，我更喜欢使用 jwt 的方式来做验证。网上有会多 Spring Security 整合 jwt 的，也有 Shiro 整合 jwt 的，感觉有点复杂。除了 SpringBoot 基本的依赖，需要一个生成 jwt 和序列化的包。生成 jwt 的包依赖很多，因为我项目里使用了 hutool 这个包，就只用用它了。定义jwt的验证拦截器，从请求头获取 token 解析并验证。在 WebMvc 配置中注册拦截器，并支持跨域请求。定义一个用于请求类和方法的注解。

Around("@annotation(com.pkslow.springboot.aop.PkslowLogTime) && execution(* *(..))")这个表达式很关键，如果不对，将无法正确识别；还有可能出现多次调用的情况。这篇文章讲解一下AOP与注解的整合，通过注解来使用AOP，会非常方便。为了简便，我们还是来实现一个计时的功能。通过注解可以实现很多功能，也非常方便。而且注解还可以添加参数，组合使用更完美了。这里使用了Spring的StopWatch来计时。

jcasbin简介：jcasbin 是一个用 Java 语言打造的轻量级开源访问控制框架是casbin的Java语言版本。目前在 GitHub 开源。jcasbin 采用了元模型的设计思想，支持多种经典的访问控制方案，如基于角色的访问控制 RBAC、基于属性的访问控制 ABAC 等。jcasbin 的主要特性包括：1.支持自定义请求的格式，默认的请求格式为{subject, object, action}；2.具有访问控制模型 model 和策略 policy 两个核心概念；

静态代理是编写、编译或加载时织入代码实现，而动态代理则在运行时实现。简单而言，静态代理是在运行前就已经存在，而动态代理则在运行时才存在的。JDK Proxy本质上使用的是反射的机制，而CGLib使用的是ASM，CGLib速度会更好。通过Proxy.newProxyInstance方法会生成一个代理的实例，执行这个实例的方法，而原有实例bird被代理了。JDK Proxy： JDK Proxy是JDK自带的，不需要引入外部库，通过实现接口进行代理；设置完成，再执行程序，就会生成代理类的.class文件。

就比如说，当你已经知道了OpenFeign最终会对每一个FeignClient接口生成动态代理对象，之后注入的对象都是代理对象，代理对象中实现了RPC的请求之后，那么当你在学习dubbo的时候，是不是就可以去猜测注入的dubbo接口最终也是一个动态代理对象，并且这个代理对象也实现了RPC的请求？当你带着这些目的，你读源码就有很强的目的性，读完印象会很深刻。比如说，现在我想要阅读一下RocketMQ生产者是如何发送消息的，整个过程是什么样的，那么我首先至少得写个发送消息的demo，看看代码是如何写的。

在使用Spring开发的时候，配置的方式主要有两种，一种是xml的方式，另外一种是 java config的方式。在使用的过程中java config，我们难免会与注解进行各种打交道，其中，我们使用最多的注解应该就是@Autowired注解了。从上面的实现逻辑不难发现，借助Java反射，我们可以直接获取一个类中的所有方法，然后获取方法上的注解。知道了上面的知识，我们就不难想到，上面的注解虽然简单，但是@Autowired和他最大的区别应该只是注解的实现逻辑，其他的如使用反射获取注解等步骤应该是相同的。

它们的切换通过一个参数控制的这个参数就是max_length_for_sort_data 它表示MySQL用于排序行数据的长度的一个参数，如果单行的长度超过这个值，MySQL 就认为。也就是说，这条SQL语句需要排序。如果要排序的数据小于sort_buffer_size，排序在sort_buffer 内存中完成，如果要排序的数据大于sort_buffer_size，则。：如果sort_buffer内存足够，那效率是最高的，但如果sort_buffer内存不够的话，就需要用到磁盘临时文件，排序的性能会很差。