1.26的源多少补码和反码是多少
2.FREE SOLO - 自己动手实现Raft - 17 - leveldb源码分析与调试-3
3.全面升级！一套基于Spring Boot 3+JDK17的源码实战项目！
4.OpenJDK17-JVM 源码阅读 - ZGC - 并发标记 | 京东物流技术团队

26的补码和反码是多少

       -原码为：

       -原码为：

       --的源码为：

       以8位为例，源码的补码最高位为符号位，1代表负数。源多少

       反码是源码haiku 源码源码符号位不变，其他位取反。反码

       --的补码反码为：

       补码是在反码的基础上+1

       --的补码为：

FREE SOLO - 自己动手实现Raft - - leveldb源码分析与调试-3

       leveldb的数据流动路径是单向的，从内存中的源多少memtable流向不可变的memtable，最终写入到磁盘上的源码sorted table文件中。以下是反码几个关键状态的分析，来了解内存和磁盘上数据的补码分布。

       以下是源多少分析所涉及的状态：

       1. 数据全在内存中

       随机写入条数据，观察到数据全部存储在memtable中，源码此时还没有进行compaction操作。反码

       2. 数据全在磁盘中

       写入大量数据，xss脚本源码并等待数据完全落盘后重启leveldb。此时，数据全部存储在磁盘中，分布在不同的level中。在每个level的sstable文件中，可以看到key的最大值与最小值。

       3. 数据部分在内存中，部分在磁盘中

       随机写入条数据，发现内存中的memtable已满，触发compaction操作，数据开始写入到sstable文件。同时，继续写入的数据由于还未达到memtable上限，仍然保存在内存中。

       4. 总结

       通过观察不同数据写入量导致的滑动抽奖 源码软件数据在内存与磁盘间的流动，我们可以看到leveldb内部状态的转换。

       下篇文章将分析LRUCache数据状态的变化。敬请期待！

全面升级！一套基于Spring Boot 3+JDK的实战项目！

       最近对mall项目进行了全面升级，支持了Spring Boot 3和JDK。以下是mall项目的升级内容，包括依赖升级、框架用法升级以及运行部署的改动。Spring Boot 3版本的代码位于mall项目的dev-v3分支。

       mall项目简介：mall项目是一个基于SpringBoot、Vue和uni-app实现的电商系统（Github标星K），采用Docker容器化部署。项目包括前台商城项目和后台管理系统，汉源码头赛艇支持完整的订单流程，涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能。

       项目演示：

       升级版本：项目中的依赖已经升级到最新主流版本，具体版本可参考下表。

       升级用法：在mall项目升级Spring Boot 3的过程中，部分框架的用法发生了变化。例如，生成API文档的库已从SpringFox迁移到SpringDoc，Spring Data Elasticsearch和Spring Security的事件模型源码分析用法也有所不同。以下将重点讲解这些升级的新用法。

       从SpringFox迁移到SpringDoc：由于之前使用的Swagger库为SpringFox，目前已不支持Spring Boot 3，因此已迁移到SpringDoc。

       Spring Data Elasticsearch新用法：Spring Data ES中基于ElasticsearchRepository的简单查询用法保持不变，但对于复杂查询，由于ElasticsearchRestTemplate类已被移除，需要使用ElasticsearchTemplate类来实现。

       Spring Security新用法：升级Spring Boot 3版本后，Spring Security的用法也有所变化。例如，某些实现动态权限的类已被弃用，Security配置改用函数式编程的方式。

       其他运行部署：由于Spring Boot 3最低要求是JDK，在Windows下运行项目时需要配置好项目的JDK版本，其他操作与之前版本相同。

       Linux：在打包应用的Docker镜像时，需要配置项目使用openjdk:。这可以在项目根目录下的pom.xml中修改docker-maven-plugin插件配置完成。

       由于镜像使用了openjdk:，在打包镜像之前需要提前下载好openjdk的镜像。可以使用以下命令下载，其他操作与之前版本部署相同。

       总结：今天主要讲解了mall项目升级Spring Boot 3版本的一些注意点。项目源码地址：github.com/macrozheng/m...

OpenJDK-JVM 源码阅读 - ZGC - 并发标记 | 京东物流技术团队

       ZGC简介：

       ZGC是Java垃圾回收器的前沿技术，支持低延迟、大容量堆、染色指针、读屏障等特性，自JDK起作为试验特性，JDK起支持Windows，JDK正式投入生产使用。在JDK中已实现分代收集，预计不久将发布，性能将更优秀。

       ZGC特征：

       1. 低延迟

       2. 大容量堆

       3. 染色指针

       4. 读屏障

       并发标记过程：

       ZGC并发标记主要分为三个阶段：初始标记、并发标记/重映射、重分配。本篇主要分析并发标记/重映射部分源代码。

       入口与并发标记：

       整个ZGC源码入口是ZDriver::gc函数，其中concurrent()是一个宏定义。并发标记函数是concurrent_mark。

       并发标记流程：

       从ZHeap::heap()进入mark函数，使用任务框架执行任务逻辑在ZMarkTask里，具体执行函数是work。工作逻辑循环从标记条带中取出数据，直到取完或时间到。此循环即为ZGC三色标记主循环。之后进入drain函数，从栈中取出指针进行标记，直到栈排空。标记过程包括从栈取数据，标记和递归标记。

       标记与迭代：

       标记过程涉及对象迭代遍历。标记流程中，ZGC通过map存储对象地址的finalizable和inc_live信息。map大小约为堆中对象对齐大小的二分之一。接着通过oop_iterate函数对对象中的指针进行迭代，使用ZMarkBarrierOopClosure作为读屏障，实现了指针自愈和防止漏标。

       读屏障细节：

       ZMarkBarrierOopClosure函数在标记非静态成员变量的指针时触发读屏障。慢路径处理和指针自愈是核心逻辑，慢路径标记指针，快速路径通过cas操作修复坏指针，并重新标记。

       重映射过程：

       读屏障触发标记后，对象被推入栈中，下次标记循环时取出。ZGC并发标记流程至此结束。

       问题回顾：

       本文解答了ZGC如何标记指针、三色标记过程、如何防止漏标、指针自愈和并发重映射过程的问题。

       扩展思考：

       ZGC在指针上标记，当回收某个region时，如何得知对象是否存活？答案需要结合标记阶段和重分配阶段的代码。

       结束语：

       本文深入分析了ZGC并发标记的源码细节，对您有启发或帮助的话，请多多点赞支持。作者：京东物流 刘家存，来源：京东云开发者社区 自猿其说 Tech。转载请注明来源。