qq_48772498的博客

特性volatile 能否保证说明可见性✅ 能保证一个线程修改后，其他线程立即看到最新值有序性✅ 能禁止指令重排序，保证操作顺序原子性❌ 不能无法保证复合操作（如 i++）的原子性关键要点volatile 解决了可见性和有序性问题volatile不能解决原子性问题对于需要原子性的操作，应使用 synchronized 或原子类正确使用 volatile 可以避免不必要的同步开销，提高程序性能。

通过 CAS + synchronized 保证同一时刻只有一个线程能修改同一个桶。利用 volatile 的内存可见性，保证读线程能看到写线程的最新修改。迭代器创建时会捕获当前数组的快照，迭代过程中不反映后续的修改，但也不会抛出 ConcurrentModificationException。扩容时采用多线程协助迁移（helpTransfer），每个线程负责迁移一部分桶，迁移完成后再允许新操作。

分层排查：遇到连接数瓶颈时，按“应用程序配置 → 系统参数 → 硬件资源”的顺序进行排查。监控指标：关注ss -s显示的 TCP 连接数、内存使用率、CPU 负载、网络流量等关键指标。参数调优：根据业务场景，合理调整文件描述符数量、TCP 内核参数（如）、应用程序最大连接数等。架构升级：对于百万级并发场景，考虑采用分布式架构、负载均衡、连接池等技术来分散单点压力。通过综合优化上述因素，可以显著提升服务器的连接处理能力，支撑更高的并发用户访问。

安全没有银弹。选择前端存储与认证方案时，需在用户体验、开发复杂度、系统性能与安全强度之间做出权衡。对于大多数需要强安全管控的系统，Session ID 方案仍是经过时间考验的可靠选择。若追求无状态架构且可接受一定的管理复杂度，JWT + Redis 黑名单是一个不错的折中方案。务必避免将敏感信息直接存入 localStorage，并对所有用户输入进行严格的过滤与转义，从根本上杜绝 XSS 漏洞。

通过上述“规则引擎 + 实时计算 + 图谱分析”的组合，以及“同步拦截 + 异步审核”的分层决策机制，可以构建一个既高效又精准的智能风控系统。现代风控系统通常采用多层次、立体化的防御策略，结合实时计算与离线分析，以应对复杂的业务场景和攻击手段。规则拦截是风控系统的第一道防线，通过预定义的业务规则对请求进行快速判断和拦截。知识图谱用于挖掘深层次的关联关系和复杂模式，是应对高级、隐蔽攻击的关键。对于需要基于时间窗口进行统计和判断的复杂场景，需要引入实时计算框架。

状态机模型为复杂业务逻辑提供了清晰的结构化解决方案。通过合理设计 Guard 和 Action 机制，可以有效保证业务规则的执行。结合乐观锁处理并发问题，以及完善的日志记录解决责任追溯问题，可以构建出健壮、可维护的业务系统。

订单超时取消的核心是将定时扫描转化为异步事件处理。MQ延时方案在可靠性、并发控制和系统解耦方面优势明显，是生产环境推荐方案。具体选型需结合团队技术栈、业务规模和运维能力综合考虑。

Spring Boot 的启动流程通过高度的自动化和合理的默认配置，让开发者能够快速搭建和运行生产级应用。理解这一流程有助于我们更好地进行定制化配置、问题排查和性能优化。

MySQL 执行 DELETE 后磁盘空间未立即释放，是由于 InnoDB 的“逻辑删除+空间复用”机制。这有利于提升写入性能，但会导致数据文件不收缩。若需物理回收空间，可使用或重建表。建议结合业务场景和磁盘监控，合理安排空间优化操作。

冷热分离是一种数据库架构优化策略，其核心思想是根据数据的访问频率和重要性，将数据划分为“热数据”和“冷数据”，并将它们存储在不同性能、不同成本的存储介质或数据库中，以达到性能与成本的最佳平衡。热数据 (Hot Data)：通常指最近7到30天内被频繁访问的数据。这类数据占总体数据量的比例较小（例如10%-20%），但对访问性能要求极高，需要存储在高速、高成本的存储介质（如SSD、高性能数据库主库）上。冷数据 (Cold Data)：指超过30天基本无人访问的历史数据。

A：当框架隐藏式调用（如 set / cache / orm），且需要用业务属性进行判等时。这是为了遵守 Java 中。方法时，就必须同时重写。

App 端每 30 秒进行一次统计上报（用户离开页面时立即上报）→ 消息队列（MQ）异步削峰 → Redis 通过 ZADD 存储（数据量过大时可按用户 ID 进行分片）。

方法，该方法会加载 Spring 容器，并解析。当 Spring Boot 启动时，会执行。是一个复合注解，它包含。

SpingBean循环依赖如何解决。

存在联合索引 ABC，AB、BC、BAC、A or B 是否会走索引。

防刷是分层防御体系——网关限流拦流量、风控识别拦行为、通道熔断保稳定、定时清理降价值，多层叠加才能有效对抗。多维度组合限流效果更好，比如同一 IP 每分钟不超过 60 次，同一设备号每天不超过 10 次注册。存储请求时间戳，每次请求时清除窗口外的旧记录，统计窗口内的请求数，更精准但内存消耗略高。风控评分超过阈值后，可分级处置：低风险弹验证码、中风险要求短信验证、高风险直接拦截。实现简单，但存在窗口临界突刺问题（窗口切换瞬间可能放过双倍请求）。：可借助 Lua 脚本保证原子性，适合需要平滑限流的场景。

缓存过期后从库延迟通常也已追上，再走正常的读从库逻辑。：对一致性要求极高的读操作（如支付后立即查询订单）直接路由到主库，牺牲一定的主库压力换取强一致性。：主库在提交事务时，至少等待一个从库确认已接收 binlog 后才返回成功，从源头上减少数据丢失窗口，但会略微增加主库写入延迟，适合对数据安全性要求高的场景。串行回放，而主库是多线程并发写入，两者速度不匹配就会产生延迟。），允许从库多线程并行回放 binlog，大幅缩短延迟。主库并发写 → binlog → 从库单线程串行回放，速度跟不上，产生延迟。

Redis 同时开启惰性删除和定期删除，两者互补：定期删除负责周期性批量清理，惰性删除在访问时兜底检查。缺点：每个 key 都要维护一个定时器，当存在大量过期 key 时，定时器本身消耗大量 CPU 资源，影响服务性能。Redis 用"惰性 + 定期"双策略处理过期 key，再用"内存淘汰"作为最后一道防线，三者共同保障内存安全。原理：不主动删除，当客户端访问某个 key 时，Redis 先检查其是否过期，若已过期则删除并返回空。原理：为每个设置了过期时间的 key 创建一个定时器，到期时立即删除。

一句话总结：单例模式保证的是"一个类只有一个对象"，而 Spring 单例 Bean 保证的是"同一个 BeanName 只有一个对象"，两者维度不同，不能混为一谈。单例模式是一种设计模式，目的是保证一个类在整个应用中只有一个实例。为维度，无论在何处获取，返回的都是同一个对象（内存地址相同）。同一个类如果注册了多个不同名称的 Bean，容器中就会存在多个实例，因此它并不是严格意义上的单例模式。，不同的 ApplicationContext 容器即使 BeanName 相同，也会各自持有独立的实例。

容器会先扫描并解析所有 Bean 的配置信息，封装成 BeanDefinition 存入 BeanDefinitionMap，之后按需（或预加载）进行 Bean 的创建。实例化 → 依赖注入 → Aware 回调 → 后处理器前置 → 初始化 → 后处理器后置（AOP） → 使用 → 销毁。等接口，容器会在此阶段回调对应方法，让 Bean 感知到自身在容器中的信息。容器通过反射调用构造方法，创建 Bean 的原始对象（此时属性还未赋值）。等注解，将依赖的 Bean 或配置值注入到对应字段中。