- 博客(153)
- 资源 (22)
- 收藏
- 关注
RSS订阅原创 JWT与OAuth 2.0的区别及关系解析
JWT和OAuth2.0是两种互补的技术：JWT是一种自包含的令牌格式，用于安全传输身份信息；OAuth2.0则是授权框架，管理第三方访问权限。二者常结合使用，OAuth2.0处理授权流程，JWT作为令牌格式提供高效验证。JWT的优势在于自包含和无状态验证，而OAuth2.0支持权限管理。典型应用场景如微信授权登录三方应用，OAuth2.0完成授权后颁发JWT格式令牌。两者既可独立使用，也能协同工作，共同构建现代安全的认证授权体系。
2026-01-31 00:53:23
460
原创 JWT概念及工作原理详解
JWT是一种开放标准的网络身份验证方案，通过JSON格式传输信息，包含头部、载荷和签名三部分。它具有体积小、自包含、安全性高等特点，支持数字签名和加密。JWT工作流程包括登录认证、令牌存储、API访问和验证阶段，适用于身份认证、信息交换和单点登录等场景。相比传统Session方式，JWT具有无状态、跨域友好等优势，但需注意安全存储和密钥管理。JWT已成为现代Web开发的主流身份验证方案，尤其适合RESTful API和分布式系统。
2026-01-19 08:30:00
581
原创 服务无状态化设计原则与实践
摘要： 服务无状态化通过将状态信息（会话、业务数据等）剥离到外部存储（如Redis、数据库），使服务实例不保存客户端状态，实现请求的任意路由。其核心原则包括无本地状态、请求自包含和状态外置。优势在于提升可扩展性（随意扩容）、高可用性（故障无缝转移）和负载均衡。典型实践包括用JWT替代Session、业务状态存库、文件直传对象存储等，需权衡外部存储延迟与一致性。关键检查点包括消除本地Session、请求信息完整性及共享存储配置等，但需根据业务场景灵活权衡，避免过度设计。
2026-01-17 08:30:00
543
原创 分布式事务一致性方案介绍
摘要：分布式事务是在跨多个数据库或服务的业务操作中保证数据一致性的关键技术。本文介绍了5种主流实现方案：1）2PC通过协调者实现强一致但性能较差；2）TCC采用预留-确认-取消三阶段，适合高并发核心业务；3）本地消息表通过事务表+异步消息实现最终一致；4）Saga模式拆分长事务配合补偿机制；5）基于消息队列的可靠消息方案。对比各方案在一致性、性能和复杂度上的差异，提出实际选型建议：TCC适合复杂业务，本地消息表适合简单场景，Saga适合长流程。最佳实践包括缩小事务范围、优先最终一致、完善补偿机制等。
2026-01-16 23:13:43
365
原创 RocketMQ延迟消息实现原理解析
RocketMQ延迟消息采用预置延迟等级和定时扫描机制实现。消息发送时设置延迟级别（共18个固定等级，如1s、5s等），Broker会将消息存入对应延迟队列（SCHEDULE_TOPIC_XXXX），通过定时任务扫描到期消息后恢复原主题投递。该方案存在固定延迟级别、秒级精度等限制，5.0版本引入时间轮优化，支持任意延迟和毫秒级精度。典型应用场景包括订单超时处理（如设置30分钟延迟），需根据业务需求选择合适的延迟等级。
2026-01-15 17:24:33
800
原创 Agent与流程引擎异同对比分析
摘要： AIAgent（智能体）与传统流程引擎（如BPMN）在自动化任务中各有侧重：流程引擎基于预设规则执行结构化流程，强调效率与合规，适合高吞吐量场景（如订单处理）；而AIAgent通过自主推理处理非结构化任务（如市场分析），灵活应对不确定性。两者互补性强，未来趋势是融合方案——流程引擎作为“骨架”确保可靠性，AIAgent作为“关节”提供智能决策，形成“超级自动化”架构（如智能客服中流程引导与Agent应答结合）。选择依据取决于任务是否需要确定性（选引擎）或动态适应性（选Agent）。
2026-01-15 09:00:00
1604
原创 详细梳理JDK 21 相比 JDK 8 的主要新特性
Java从JDK8到JDK21经历了重大变革，主要新特性包括：语言方面新增模块系统、var类型推断、文本块、记录类、模式匹配和密封类；并发方面引入革命性的虚拟线程；API增强包括集合工厂方法、Stream改进、HTTP Client等；性能方面G1GC成为默认垃圾收集器，新增ZGC和Shenandoah；开发工具增加了jshell和jpackage。JDK21版本在并发编程、语法简洁性和性能方面带来突破性改进，是现代Java开发的推荐起点。建议新项目直接采用JDK21，生产系统至少升级到JDK17。
2026-01-13 15:15:22
942
原创 MySQL主从异步复制的风险及对策
MySQL主从异步复制通过多种机制降低数据丢失风险：1)强制"双一策略"(sync_binlog=1和innodb_flush_log_at_trx_commit=1)确保数据持久化；2)半同步复制(Semi-Sync)在性能和安全性间取得平衡；3)GTID机制保障数据一致性；4)完善的监控告警体系。生产环境建议结合双一策略、增强型半同步(AFTER_SYNC)和GTID使用，并建立多从库、延迟复制等容灾方案，在保证性能的同时将数据丢失风险降至最低。
2026-01-13 09:15:00
570
原创 MySQL主从复制原理详解
MySQL主从复制是一种通过日志同步实现数据实时复制的技术，核心流程包括主库记录二进制日志、从库拉取日志和重放日志三个步骤。它支持异步、半同步和组复制三种模式，可用于读写分离、数据备份和高可用场景。配置时需要设置主从库的server_id和日志参数，常见问题包括数据延迟和不一致，可通过多线程复制、GTID等技术优化。该技术通过日志同步与重放机制，在性能与可靠性之间实现平衡。
2026-01-12 23:52:21
916
原创 Distro与Raft协议对比分析
本文对比了Nacos中的Distro协议与Raft协议的核心差异。Distro是专为服务发现优化的AP协议，采用对等节点架构和异步数据同步，保证高可用和最终一致性，适合临时性数据场景。Raft是通用CP共识算法，通过Leader选举和日志复制实现强一致性，适用于持久化关键数据存储。Nacos创新地混合使用两种协议：Distro处理临时实例数据，Raft管理持久化配置，展现了根据数据类型选择合适协议的架构智慧。关键区别在于Distro优先保证可用性，Raft优先保证一致性，二者在分布式系统中各有适用场景。
2026-01-11 23:54:36
866
原创 Nacos服务与配置管理平台介绍
Nacos是阿里巴巴开源的动态服务发现与配置管理平台，主要解决微服务架构中的服务注册发现和动态配置管理两大核心问题。它提供一站式解决方案，支持高可用集群、多环境隔离、健康检查等功能，兼容Spring Cloud和Dubbo框架。Nacos采用客户端-服务端架构，通过Distro和Raft协议实现数据一致性，具备完善的服务注册发现流程和配置推送机制。相比Eureka、Consul等同类产品，Nacos集服务与配置管理于一体，适合中等规模或希望简化技术栈的团队，是微服务架构中重要的基础设施组件。
2026-01-10 23:32:19
1016
原创 MyBatis框架原理与核心特性详解
MyBatis是一个半自动ORM框架，核心思想是SQL与代码分离，开发者需手动编写SQL但拥有更大控制权。其架构包括配置加载、SQL映射、动态代理和执行流程四大环节，通过Executor等核心对象实现数据库操作。关键特性包含一/二级缓存、动态SQL生成和插件机制，相比Hibernate具有更高的SQL控制灵活性和更优性能。适用于需要复杂SQL优化、对性能要求高的项目，在保持ORM便利性的同时提供完全的SQL控制能力。
2026-01-09 09:00:00
601
原创 分布式系统CAP与BASE理论详解
摘要：CAP定理和BASE理论是分布式系统设计的核心理论。CAP定理指出在网络分区时，系统只能在一致性(C)和可用性(A)之间二选一，而分区容错性(P)必须保证。BASE理论则是对AP系统的实践指导，提出基本可用(BA)、软状态(S)和最终一致性(E)的设计原则，通过牺牲强一致性来换取高可用性和可扩展性。两者共同构成了现代分布式系统设计的理论基础，CAP定理定义系统局限，BASE理论提供具体实现方案。
2026-01-08 00:50:26
590
原创 开源分布式ID生成方案接入介绍
本文对比分析了五种主流分布式ID生成方案：美团Leaf（支持号段/Snowflake模式）、滴滴Tinyid（Leaf增强版）、IdGenerator（解决时钟回拨）、百度uid-generator（高性能）和Hutool轻量方案。详细介绍了各方案的部署方式、核心特点及Java接入代码示例，如Leaf的数据库配置、IdGenerator的多语言支持等。针对不同场景给出选型建议：中小项目推荐Hutool，微服务架构建议Leaf/Tinyid，时钟回拨敏感场景或多语言环境选择IdGenerator。
2026-01-07 12:25:01
1556
原创 分布式ID生成方法详解
摘要：分布式ID生成是分布式系统的关键技术，需满足全局唯一、趋势递增、高性能等要求。主流方案包括：UUID（简单但无序）、数据库自增ID（单机性能差，集群扩展难）、Snowflake算法（高效但依赖时钟）、Redis原子操作（需维护缓存）、ZooKeeper（强一致但性能低）和发号器服务（可控但引入网络延迟）。建议根据业务规模选择：初创项目用UUID或单机数据库，中等并发用数据库号段模式，高并发用改进版Snowflake。号段模式和Snowflake变种是生产环境最主流的选择。
2026-01-07 02:10:51
1187
原创 限流算法：令牌桶与漏桶详解
限流算法用于控制系统请求速率，防止过载。令牌桶算法以固定速率生成令牌，允许突发流量处理（取决于桶容量），适用于需要弹性应对突发的场景。漏桶算法强制恒定处理速率，严格平滑流量，适合要求稳定输出的场景。两者核心区别在于：令牌桶控制平均流入速率并允许突发，漏桶确保绝对匀速输出。实际应用中，令牌桶更常见（如API限流），漏桶用于特殊需求（如流量整形）。分布式环境下可通过Redis等实现限流，并建议结合监控和多级策略进行动态调整。选择算法需根据业务对突发流量和输出稳定性的需求权衡。
2026-01-06 14:03:20
660
原创 线性数据结构关系与实现解析
本文深入分析了四种基础线性数据结构：数组、链表、栈和队列。数组和链表是物理存储结构，前者连续存储支持随机访问，后者链式存储仅支持顺序访问。栈和队列则是抽象数据类型(ADT)，分别遵循LIFO和FIFO规则，它们可以基于数组或链表实现。核心区别在于：数组/链表关注存储方式，栈/队列关注操作规则。这四种结构形成层级关系，基础存储结构（数组/链表）可实现高级抽象结构（栈/队列）。理解这种"容器与规则"的关系对掌握数据结构至关重要。
2026-01-05 17:14:32
475
原创 RocketMQ有序消息实现原理
RocketMQ通过顺序消息机制实现消息有序性，分为全局有序（单队列）和分区有序（多队列）两种类型。核心实现包括：发送端通过业务ID哈希选择队列，Broker端顺序存储消息，消费端通过队列锁定和顺序监听器保证处理顺序。关键技术包含队列锁定、消费重试机制，并仅保证同一队列内的顺序性。生产配置需注意合理设计分区键，平衡顺序需求与吞吐量。常见问题包括性能优化和消息阻塞处理，推荐优先采用分区有序模式。
2026-01-05 01:23:36
813
原创 PostgreSQL与MySQL选型对比
PostgreSQL与MySQL对比摘要：PostgreSQL适合复杂查询、高一致性及GIS应用，支持丰富数据类型和扩展功能；MySQL则在简单读写、云服务集成和主从复制上表现优异。选型关键因素包括：查询复杂度、数据模型、事务要求、团队经验和云服务需求。复杂业务推荐PostgreSQL，简单OLTP场景可选MySQL。混合架构可结合两者优势，最终应通过实际测试验证性能。建议不确定场景优先考虑PostgreSQL的功能超集特性。
2026-01-04 00:36:12
911
原创 PostgreSQL数据库详细介绍
PostgreSQL是一款功能强大的开源关系型数据库，具备完整的ACID特性、多版本并发控制(MVCC)和丰富的数据类型支持。其核心优势包括：支持JSON/JSONB、表分区、物化视图等高级功能；提供多种索引类型和细粒度权限控制；具有强大的扩展性，可通过PostGIS等扩展增强功能。它采用基于成本的查询优化器，支持并行查询和多种复制方案，适用于复杂业务系统、GIS应用和数据分析等场景。通过合理的配置调优和索引策略，可显著提升性能。PostgreSQL以其SQL标准兼容性、可靠性和持续创新在数据库领域保持领先
2026-01-03 23:51:49
1093
原创 Redis BitMap介绍及使用场景示例
Redis的BitMap是一种高效存储二进制位的数据结构，主要用于布尔值标记和统计场景。典型应用包括用户行为记录（登录/签到）、活跃用户统计（DAU/MAU）、布隆过滤器实现、设备状态监控等。相比Set结构，BitMap可大幅节省内存（10亿用户签到仅需约120MB）。其核心优势在于支持位运算（AND/OR/XOR）和快速统计（BITCOUNT），但需注意稀疏数据可能浪费内存，且偏移量上限为42亿。常用命令包括SETBIT、GETBIT、BITOP等，特别适合海量布尔值的高性能存储需求。
2026-01-02 23:50:31
359
原创 Redis集群扩容数据迁移方案分析
Redis集群从3节点扩容到4节点时，需要迁移约25%的数据以重新平衡槽位分布。迁移方案包括：1.准备工作（环境检查、新节点配置）；2.添加新节点并计算槽位迁移计划（每个原节点迁移1365个槽）；3.执行迁移（支持自动或手动方式）；4.迁移后验证（集群状态、数据一致性检查）。关键点：使用CRC16算法将数据均匀分布在16384个槽位中，迁移过程需监控性能并准备回滚方案。该方案确保扩容后各节点负载均衡，同时最小化对业务的影响。
2026-01-01 23:51:14
601
原创 阿里开源搜索引擎Havenask与OpenSearch的关系
阿里开源的Havenask与阿里云OpenSearch共享同一核心技术，但定位不同：Havenask是开源搜索引擎内核，需自主部署运维；OpenSearch则是基于该内核的商业化云服务，提供全托管解决方案。两者形成"开源+商业"双轨模式，Havenask面向技术团队深度定制，OpenSearch服务企业级用户。这种模式既建立技术生态又实现商业价值，用户可根据需求选择自建或托管方案。
2025-12-31 01:00:00
471
原创 ThreadLocal内存泄漏机制解析
ThreadLocal内存泄漏机制源于其设计权衡：Entry的key为弱引用（防止ThreadLocal对象无法回收），value为强引用（保证数据可靠性）。当ThreadLocal对象被回收后，key为null的Entry会导致value无法自动释放。虽然get/set/remove操作会触发清理，但最佳实践是显式调用remove()，尤其在线程池场景中。这种设计通过弱引用key减轻泄漏范围，但核心问题仍是未及时清理的强引用value。开发者应养成remove习惯，避免内存泄漏。
2025-12-30 23:11:51
957
原创 Redis热key与大key的危害及解决方案
Redis热Key与大Key问题解决方案 热Key和大Key是Redis常见性能瓶颈。热Key指高频访问的Key，易导致单点过载和缓存击穿，可通过本地缓存、Key拆分、读写分离分散压力。大Key指体积过大的Key，会引发内存不均和阻塞操作，需采用数据结构拆分、异步删除和优化访问命令。通用建议包括：监控预警（使用redis-cli--bigkeys等工具）、规范开发（限制Key大小）、架构优化（多级缓存）。通过组合这些方案，可有效提升Redis稳定性和性能。
2025-12-30 00:30:00
1031
原创 Redis键值设计原则与最佳实践
Redis键值设计核心原则：Key应保持可读性（冒号分隔层级）、简洁性（避免过长）和稳定性；Value需选择合适数据结构（String/Hash/List等），控制大小（建议<10KB）并优化序列化策略。设计时采用分片策略、设置TTL，避免大Key/热Key等陷阱。实战中应充分利用Redis的原子操作和丰富数据结构，根据访问模式而非简单数据库映射来设计。定期监控大Key/热Key，优化内存使用和集群设计是关键。
2025-12-29 00:15:00
410
原创 Redis Key过期删除策略详解
Redis采用双重Key过期删除策略：惰性删除在访问时检查并删除过期Key，节省CPU但可能内存泄露；定期删除每秒随机扫描部分Key，平衡内存和CPU消耗。当内存不足时，根据配置策略（如LRU/LFU）淘汰数据。优化建议包括调整扫描频率、避免批量Key同时过期。这种组合策略在内存效率与CPU开销间取得平衡，确保Redis高效处理大量带过期时间的Key。
2025-12-28 00:30:00
834
原创 消息中间件推送机制详解
消息中间件推送机制涉及Broker主动推送或Consumer主动拉取两种模式。推模式（如RocketMQ）通过长连接实时推送，包含负载均衡、ACK确认和重试机制；拉模式（如Kafka）采用轮询优化实现准实时效果。两种模式在实时性、负载均衡和复杂度等方面各有优劣，现代系统常结合使用并辅以批量推送、顺序保证等优化策略。主流中间件如RocketMQ、Kafka等在实现上存在差异，选择取决于对实时性和可控性的需求平衡。
2025-12-27 01:45:22
1027
原创 最终一致性系统中的消息可靠性保障策略
本文阐述了确保最终一致性系统消息可靠性的关键策略。从生产端、消息中间件、消费端三个环节提出保障措施：生产端通过持久化、事务消息确保可靠投递；中间件采用高可用集群、多副本同步实现数据冗余；消费端依靠手动ACK、重试队列和幂等处理保证可靠消费。此外，建议建立端到端监控、对账补偿机制及容灾备份方案。技术选型上，RocketMQ适合强一致场景，Kafka适用于高吞吐需求。最终一致性系统的核心是通过"四重保障"（可靠投递、集群化、幂等重试和监控补偿）实现故障场景下的最终可达，而非追求实时可靠。
2025-12-26 01:24:02
826
原创 QLExpress介绍以及与其他规则引擎对比分析
QLExpress是阿里开源的轻量级Java规则引擎，支持动态规则执行。其名称QLExpress代表"查询语言快速执行"，具有高性能、线程安全、支持自定义函数等特性。相比Drools等引擎，QLExpress更轻量、易集成，支持中文关键字，适合业务规则频繁变更的场景。通过简单的API即可实现表达式计算、变量上下文和条件判断等功能。核心优势在于平衡性能与易用性，特别适合需要快速响应业务变化的Java项目。
2025-12-25 00:48:20
875
原创 Spring Boot自动装配原理解析
SpringBoot自动装配是其核心特性，通过约定大于配置原则自动配置所需Bean。核心注解@SpringBootApplication包含@EnableAutoConfiguration，利用AutoConfigurationImportSelector加载META-INF/spring.factories或AutoConfiguration.imports中的配置类，并基于@Conditional系列注解进行条件过滤。自动装配流程包括加载候选配置、去重、条件排除和过滤，最终注册符合条件的Bean.
2025-12-24 09:00:00
879
原创 系统启动频繁Full GC问题排查与优化
摘要：Java应用启动时频繁FullGC常见原因包括堆内存过小、大对象/内存泄漏、元空间配置不当及GC参数不合理。排查步骤：1)获取并分析GC日志；2)使用jstat/VisualVM等工具监控；3)分析堆内存dump；4)审查启动代码。解决方案需调整JVM参数、优化代码和延迟初始化。系统可能勉强启动但存在严重性能风险，建议立即解决以避免生产环境故障。关键要增大堆内存、定位问题代码并优化内存使用。
2025-12-23 00:32:44
718
原创 Redis缓存一致性与常见问题解决方案
Redis缓存一致性及常见问题解决方案 摘要：本文介绍了Redis缓存一致性的概念及四种常见解决方案（Cache-Aside、先删缓存后更新、延时双删和Binlog订阅）。针对缓存三大问题（穿透、击穿、雪崩）提出了具体解决措施：穿透通过布隆过滤器/空值缓存；击穿采用互斥锁/逻辑过期；雪崩通过随机过期/多级缓存。同时给出了Java生态中的实践建议，包括Spring Cache抽象、监控告警、异常处理等。最后强调应根据业务场景选择合适的工具组合，确保缓存系统的高可用性和数据一致性。
2025-12-22 09:15:00
1655
原创 RocketMQ事务消息实现原理解析
RocketMQ事务消息通过两阶段提交（2PC）和事务状态回查机制解决分布式事务问题。生产者先发送半消息到Broker，执行本地事务后提交确认，Broker根据结果决定投递或删除消息。若生产者未响应，Broker会主动回查事务状态（最多15次）。消费者端通过ACK确认、16级重试机制和死信队列确保消息可靠消费，同时要求业务实现幂等性处理。该方案将分布式事务拆分为本地事务+消息投递，在保证最终一致性的同时提高了系统吞吐量，适用于订单、转账等需要事务保障的场景。
2025-12-21 09:30:00
835
原创 云原生与DevOps关系解析
云原生是一套基于云计算环境的技术体系与架构范式，强调利用容器、微服务、编排等技术构建弹性、可扩展的应用。DevOps则是一种聚焦协作与自动化的文化与流程方法论，旨在通过CI/CD、自动化工具等打破部门壁垒，实现高效软件交付。两者本质不同但协同共生：云原生为DevOps提供理想的技术载体，而DevOps的文化与实践是管理和发挥云原生复杂架构的关键。它们共同推动业务敏捷性，形成“魂与体”的结合——云原生是技术实现的“体”，DevOps是流程与协作的“魂”。只有两者深度融合，才能充分发挥现代软件交付的潜力。
2025-12-20 09:45:00
784
原创 云原生概念与技术详解
云原生是一种基于云计算特性的应用构建方法，强调弹性、可扩展和高效。其核心理念是从设计之初就为云环境构建应用，而非简单迁移。关键技术包括容器化、Kubernetes编排、微服务架构等，实现自动化部署和动态扩展。云原生通过声明式API、服务网格等技术提升系统韧性和可观测性，支持快速迭代。相比传统云托管，云原生能最大化发挥云平台优势，已成为现代数字基础设施的基石。企业可通过渐进式路径实现云原生转型，从降低成本走向业务创新。
2025-12-19 09:15:00
1157
原创 Java反射的作用与应用场景
Java反射机制允许程序在运行时动态操作类和对象，实现动态加载类、访问私有成员、调用方法等功能。其核心应用包括框架开发（如Spring依赖注入）、动态代理、序列化、测试框架等场景。反射虽提供高度灵活性，但存在性能开销大、安全隐患等问题。最佳实践建议缓存反射结果、优化访问权限，并遵循"非必要不使用"原则。现代开发中，部分反射功能已被注解处理器等替代技术实现。反射是Java高级编程的重要特性，需权衡利弊谨慎使用。
2025-12-18 09:00:00
358
原创 Redis单线程高并发原理解析
Redis采用单线程模型实现高并发，核心原理在于：1）内存操作速度快，CPU非瓶颈；2）基于多路复用技术处理网络I/O，避免阻塞；3）消除线程切换和锁竞争开销。单线程优势包括原子性保证、性能可预测和代码简洁性。针对CPU密集型操作等局限性，可通过集群分片、异步命令和Redis 6.0的多线程I/O优化。典型场景下QPS可达10万+，延迟低于1ms。虽然引入多线程I/O，但核心数据操作仍保持单线程，平衡了性能与一致性。
2025-12-17 09:30:00
450
原创 Java内存模型（JMM）详解
摘要：JMM(Java内存模型)是规范多线程环境下共享变量访问规则的一套抽象规范，主要解决可见性、原子性和有序性问题。JMM通过synchronized保证原子性和有序性，强制主内存与工作内存同步；通过volatile保证可见性，防止指令重排序；配合Happens-Before原则确保操作顺序。这些机制使开发者无需了解底层硬件细节，就能编写线程安全的代码。JMM不同于JVM内存结构，是专门针对多线程并发问题的解决方案。
2025-12-16 09:30:00
1767
原创 JVM内存结构与Java内存模型的区别
摘要：JVM内存模型实际上包含两个不同概念：Java内存模型(JMM)和JVM内存结构。JMM是并发编程规范，定义了线程间共享变量的可见性、原子性和有序性，涉及volatile、synchronized等关键字。JVM内存结构则是运行时数据区的划分，包括堆、栈、方法区等内存区域。前者解决多线程并发问题，后者处理内存分配和回收。日常讨论中"JVM内存模型"多指后者，但在并发场景下应明确区分这两个概念。
2025-12-15 09:15:00
846
企业工资管理系统的设计与实现ASP+SQL
2010-06-26
s2sh整合demo源码
2014-06-18
s2sh注解方式整合demo源码
2014-06-23
FindBugs插件及安装使用说明
2014-08-29
很强大的java代码混淆工具 Jocky
2014-09-30
httpd-2.4.39及依赖包.zip
2019-06-05
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人