lfeishumomol的博客

本文摘要：ThreadLocal是Java线程本地存储机制，通过为每个线程维护变量副本实现线程安全的数据共享。文章结合消息中心项目，展示了ThreadLocal在管理用户登录信息和第三方应用凭证等场景的应用实践，重点分析了其核心原理、典型实现模式（如SecurityContextHolder）及生命周期管理策略。特别强调了使用规范，包括必须及时remove()防止内存泄漏，以及异步场景下ThreadLocal的局限性（需使用InheritableThreadLocal）。通过拦截器机制确保线程上下文的安全创

摘要：本文通过实战案例分析了MySQL中IN查询的性能差异及优化方案。当IN查询条件命中复合索引的最左前缀时（如report_date），查询速度较快（0.8s）；而跳过最左列直接查询staff_id会导致全表扫描（3.015s）。优化建议包括：为高频字段单独建索引（提升120倍）、控制IN列表长度（<1000）、使用覆盖索引减少回表操作，以及通过EXPLAIN监控执行计划。关键结论是：IN查询性能取决于索引设计，需遵循最左前缀原则，避免超长IN列表触发优化器改用全表扫描。

Apache JMeter是一款开源性能测试工具，主要用于测试Web应用、FTP服务器、数据库等服务的性能表现。文章以JMeter5.5为例，介绍了其四步使用方法：1)创建测试计划；2)添加线程组；3)配置取样器参数；4)查看测试结果。重点讲解了参数化测试的实现方法，包括创建CSV测试数据文件、配置CSV数据文件设置以及在测试中引用参数值。此外还介绍了接口测试用例的编写要点，包括业务功能验证、参数边界测试、异常场景测试等，并列举了JMeter的常用功能模块如响应断言、HTTP请求、聚合报告等。

MyBatis-Plus的MetaObjectHandler可自动处理公共字段赋值问题，如创建时间、更新时间、创建人等。通过实现该接口，系统能在插入或更新时自动填充这些字段，无需手动设置。自定义处理器会检查字段是否存在且为空，再自动填充默认值（如ID、逻辑删除标志等）。这有效减少代码冗余，提高规范性，但对于需要提前获取ID的业务场景（如订单关联），仍需手动赋值。该方案平衡了自动化与灵活性，使系统更健壮。

本文介绍了如何通过MyBatis实现商品属性分组与属性项的关联查询，重点演示了如何利用resultMap和autoMapping="true"简化XML配置。文章首先展示了需求场景和BO对象设计（包含嵌套类），然后对比了传统手动映射字段和优化后的自动映射方案。通过autoMapping特性，MyBatis能自动将下划线命名的数据库字段映射到驼峰命名的Java属性，显著减少了重复配置，提高了开发效率和代码可维护性。该方法特别适用于字段名遵循下划线转驼峰命名规则的场景。

《MyBatis-Plus分页设计的性能陷阱与优化实践》摘要： 文章揭示了MyBatis-Plus分页查询的两大痛点：1）默认强制COUNT查询导致性能浪费；2）参数Map设计造成前后端协作困难。作者通过实践提出优化方案：采用类型安全的Query对象替代Map参数提升可维护性，并通过PageResult封装实现逻辑隔离。尽管受限于框架无法完全避免COUNT查询，但建议通过职责分离（独立list/count方法）和减少分页插件使用来优化性能。核心观点指出：框架的便利性可能违背设计原则（如迪米特法则），高并发场

大数量级场景下，深度分页查询面临性能瓶颈。本文针对电商订单表等大数据量场景，分析传统分页方式（如LIMIT 19980,20）导致的I/O资源浪费和查询效率问题，提出四种优化方案：1）游标分页（基于有序字段避免OFFSET扫描）；2）延迟关联（通过子查询减少回表）；3）覆盖索引优化（创建包含查询字段的联合索引）；4）数据预取与缓存。这些方案可显著提升查询性能，特别适用于高频查询场景。同时建议将列表查询与详情查询分离，对大量ID查询采用分批处理或缓存优化。

P6Spy是一个无侵入式的JDBC代理框架，能够实时拦截并记录数据库操作，帮助开发者快速定位SQL问题。它通过伪装成JDBC驱动，在不修改业务代码的情况下捕获完整SQL语句和执行时间。集成步骤简单：添加依赖、修改数据源配置、创建spy.properties文件即可使用，支持自定义日志格式。特别适合开发测试环境调试MyBatis/Hibernate等ORM框架的SQL执行，但生产环境需谨慎使用以避免性能损耗。该工具是Java开发者排查数据库问题的利器，能有效替代传统打印日志的调试方式。

Spring MVC 提供了接口，允许我们在控制器方法执行后、响应写出前，对返回值进行拦截和处理。我们可以利用它来自动包装返回结果。

在现代 Web 应用中，用户上传图片、视频等文件已成为标配功能。如果所有文件都经过后端中转，不仅增加服务器带宽压力，还可能导致性能瓶颈。阿里云 OSS（Object Storage Service）提供了强大的对象存储能力，支持，真正做到“上传不走后端”。本文将带你深入实践使用实现前端直传，并对比STS Token模式，分析其优劣。同时，我们将展示如何通过 Nacos 动态配置管理 OSS 参数。

摘要： 阿里云OSS前端直传方案相比传统后端中转上传，在性能、成本、扩展性方面优势显著。通过PostPolicy签名或STS临时凭证，可实现安全上传，避免AK/SK泄露风险。Policy策略严格限制上传路径、大小等条件，配合上传回调机制，确保业务可控。高阶玩法如生命周期规则可自动清理未完成文件，结合日志记录提升安全性。前端直传OSS已成为行业标配，尤其适合高并发、大文件场景，开发者需掌握其安全机制以充分发挥优势。技术演进中，拒绝进步才是最大风险。

摘要：MyBatis-Plus的updateById方法使用需谨慎，特别是字段为null时的更新策略。默认FieldStrategy.NOT_NULL只更新非空字段，但若配置为ignored则会用null覆盖已有值。建议采用"先查后更"模式：先查询实体，再复制属性后更新，避免null值意外覆盖数据库原有数据。这种做法虽增加一次查询，但能有效保护数据完整性，是更安全的更新方式。

本文探讨了拖拽排序功能的两种后端实现方案。方案一采用数组结构，通过sort字段排序，实现简单但可能引发大量数据更新；方案二采用链表结构，通过prev_id和sibling_id字段构建关系，适合频繁操作但查询效率较低。文章建议根据数据量和操作频率选择方案：小数据量选择数组结构，大规模数据选择链表结构。两种方案各有优劣，需结合实际业务需求进行选择。

本文探讨了数据库删除操作的两种方式：逻辑删除和物理删除。逻辑删除通过标记数据为"已删除"状态保留数据，适用于需保留历史、关联性强或审计要求的场景；物理删除则彻底移除数据，适用于临时数据清理。重点介绍了MyBatis-Plus中实现逻辑删除的正确方法：使用@TableLogic注解配置删除标记字段，并推荐进行全局配置。文章强调删除前必须校验参数合法性、数据存在性，并根据业务场景选择合适的删除方式，核心原则是"能不删就不删，能逻辑删就不物理删"。