摘要：进程是操作系统资源分配的最小单位，拥有独立的内存空间；线程则是CPU调度的最小单位，属于同一进程的线程共享内存和资源。两者主要区别在于资源隔离程度，进程间相互独立，而线程间共享进程资源。

摘要 本文介绍了Java反射机制在注解处理方面的应用。通过反射技术，开发者能够在类和字段上添加自定义注解，并利用这些注解来定义各种映射关系。这种方法为框架设计、ORM实现等场景提供了灵活的元数据编程能力，使程序能够动态读取和处理类结构信息。反射与注解的结合极大增强了Java的元编程能力，是许多现代框架的核心技术基础。

摘要 使用可变对象作为HashMap的key存在严重风险：若修改影响hashCode计算的字段，会导致该条目无法被查找或删除，因为hashCode变化后搜索会转向新槽位，而数据仍留在原槽位，最终造成内存泄漏。建议优先使用不可变对象（如String、Integer）作为key，自定义类作key时需格外谨慎。

本文总结了轻量级高性能分布式系统的关键需求：降低外部依赖、支持定制化。Zookeeper因其强一致性特点，特别适用于分布式锁和选举机制场景，能够满足这些核心要求。文章简明扼要地指出了Zookeeper在分布式系统中的典型应用场景和优势。

本文摘要： 轻量级高性能中间件选择依据是减少依赖和满足定制化需求，Zookeeper适合分布式锁场景。 RabbitMQ死信消息的三种产生方式：消费者主动拒绝（设置requeue=false）、消息TTL过期、队列容量超限时挤出的队头消息。 死信处理机制通过将特定条件的消息路由到死信交换机实现。（98字）

Kafka弃用Zookeeper主要出于架构简化考虑，通过自主管理元数据降低系统复杂度与运维成本，同时提升性能表现。这一改进使Kafka在元数据管理方面获得更大灵活性。

本文简要介绍了RabbitMQ中消息处理机制：当消息无法路由时，若设置mandatory=true会将消息返回生产者，false则直接丢弃；若配置备用交换机则转向该交换机；若设置了死信队列则转入死信队列。这为消息可靠性投递提供了不同级别的处理方案。

RocketMQ事务消息采用两阶段提交机制：首先发送半消息到Broker（对Consumer不可见），然后执行本地事务并根据结果向Broker提交或回滚。Broker会定时反查事务状态，最终决定将消息放入正常队列供消费或直接回滚。整个过程确保了分布式事务的可靠性，包括Producer本地事务执行、Broker状态确认和Consumer消费处理三个关键环节。

本文介绍了基于Redis的分布式锁实现方案： 加锁流程使用SET lock_key uuid EX 30 NX命令，确保原子性设置锁，包含30秒自动过期； 解锁通过Lua脚本保证原子性操作，验证锁持有者uuid后才删除锁； 提供了Java实现代码，包含tryLock()和unlock()方法； 方案解决了锁过期、误删锁等问题，通过uuid保证只有锁持有者才能解锁。

电商订单列表深度分页查询优化方案：传统的LIMIT offset,size在页码较大时性能急剧下降。本文提出三种优化方案：1)子查询+覆盖索引优化，减少回表但仍有扫描开销；2)基于ID或时间的游标分页，性能稳定但仅支持连续翻页；3)Elasticsearch的search_after适用于复杂搜索场景。核心思路都是减少数据库扫描数据量，需根据具体业务场景（是否需要跳页、排序条件等）选择合适方案，其