From 02730bc4411310aca3ec6a3479c308c23603a3e8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=BC=A0=E4=B9=BE?= Date: Wed, 16 Oct 2024 00:20:59 +0800 Subject: [PATCH] first commit --- ...题排查分析下篇（案例实战）.md | 355 ++++++ ...情况问题排查与分析（上篇）.md | 388 +++++++ ...情况问题排查与分析（下篇）.md | 299 +++++ ...策帷帐之中，决胜于千里之外.md | 461 ++++++++ ...破浪会有时、直挂云帆济沧海.md | 464 ++++++++ ...业务代码真的会有这么多坑？.md | 101 ++ ...，线程安全就高枕无忧了吗？.md | 452 ++++++++ ...：不要让“锁”事成为烦心事.md | 352 ++++++ ...码最常用也最容易犯错的组件.md | 449 ++++++++ ...连接池：别让连接池帮了倒忙.md | 523 +++++++++ ...虑到超时、重试、并发了吗？.md | 533 +++++++++ ...明式事务，可能都没处理正确.md | 508 +++++++++ ...据库索引：索引并不是万能药.md | 371 ++++++ ...：程序里如何确定你就是你？.md | 676 +++++++++++ ...：注意精度、舍入和溢出问题.md | 340 ++++++ ...合类：坑满地的List列表操作.md | 538 +++++++++ ...不清楚的null和恼人的空指针.md | 478 ++++++++ ...自己在出问题的时候变为瞎子.md | 556 +++++++++ ...志记录真没你想象的那么简单.md | 657 +++++++++++ ...高效正确的文件读写并非易事.md | 425 +++++++ ...一来一回你还是原来的你吗？.md | 749 ++++++++++++ ...类，少踩一些“老三样”的坑.md | 526 +++++++++ ...为“自动挡”就不可能出现OOM.md | 439 ++++++++ ...泛型遇到OOP时，会有哪些坑？.md | 420 +++++++ ...ing框架：IoC和AOP是扩展的核心.md | 547 +++++++++ ...做了很多工作也带来了复杂度.md | 639 +++++++++++ ...复：搞定代码重复的三个绝招.md | 729 ++++++++++++ ...统间对话的语言，一定要统一.md | 896 +++++++++++++++ ...可以锦上添花也可以落井下石.md | 587 ++++++++++ ...写完，就意味着生产就绪了？.md | 946 ++++++++++++++++ ...步处理好用，但非常容易用错.md | 918 +++++++++++++++ ...BMS如何取长补短、相辅相成？.md | 897 +++++++++++++++ ...任何客户端的东西都不可信任.md | 532 +++++++++ ...，必须考虑防刷、限量和防重.md | 329 ++++++ ...数据就是数据，代码就是代码.md | 1000 +++++++++++++++++ ...何正确保存和传输敏感数据？.md | 877 +++++++++++++++ ...Java8的那些重要知识点（一）.md | 731 ++++++++++++ ...Java8的那些重要知识点（二）.md | 602 ++++++++++ ...位应用问题，排错套路很重要.md | 187 +++ ...，一定要用好这些工具（一）.md | 700 ++++++++++++ ...，一定要用好这些工具（二）.md | 314 ++++++ ...在工作中学习技术和英语的？.md | 163 +++ .../37加餐7：程序员成长28计.md | 245 ++++ ...拟机迁移到Kubernetes的一些坑.md | 139 +++ ...篇：代码篇思考题集锦（一）.md | 560 +++++++++ ...篇：代码篇思考题集锦（三）.md | 693 ++++++++++++ ...篇：代码篇思考题集锦（二）.md | 419 +++++++ ...疑篇：加餐篇思考题答案合集.md | 389 +++++++ ...疑篇：安全篇思考题答案合集.md | 169 +++ ...疑篇：设计篇思考题答案合集.md | 437 +++++++ ...时，如何才能尽量避免踩坑？.md | 95 ++ ...面，搭建你的Java并发知识网.md | 127 +++ ...说只有1种实现线程的方法？.md | 215 ++++ ...标记位的停止方法是错误的？.md | 412 +++++++ ...如何在6种状态之间转换的？.md | 129 +++ ...notifyAll方法的使用注意事项？.md | 160 +++ ...现生产者消费者模式的方法？.md | 0 ...06一共有哪3类线程安全问题？.md | 267 +++++ ...需要额外注意线程安全问题？.md | 107 ++ ...什么多线程会带来性能问题？.md | 37 + ...池比手动创建线程好在哪里？.md | 229 ++++ .../10线程池的各个参数的含义？.md | 60 + .../11线程池有哪4种拒绝策略？.md | 53 + ...池？什么是Java8的ForkJoinPool？.md | 248 ++++ ...程池常用的阻塞队列有哪些？.md | 46 + ...什么不应该自动创建线程池？.md | 74 ++ ...？CPU核心数和线程数的关系？.md | 42 + ...际需要，定制自己的线程池？.md | 55 + ...？shutdown和shutdownNow的区别？.md | 97 ++ ...池实现“线程复用”的原理？.md | 166 +++ ...哪几种锁？分别有什么特点？.md | 85 ++ ...观锁和乐观锁的本质是什么？.md | 114 ++ ...ynchronized背后的“monitor锁”？.md | 172 +++ ...ed和Lock孰优孰劣，如何选择？.md | 128 +++ ...个常用方法？分别有什么用？.md | 190 ++++ ...平锁，为什么要“非公平”？.md | 463 ++++++++ ...eadWriteLock获取锁有哪些规则？.md | 147 +++ ...吗？什么是读写锁的升降级？.md | 343 ++++++ ...自旋的好处和后果是什么呢？.md | 236 ++++ .../28JVM对锁进行了哪些优化？.md | 199 ++++ ...ashMap为什么是线程不安全的？.md | 144 +++ ...rrentHashMap在Java7和8有何不同？.md | 358 ++++++ ...ap桶中超过8个才转为红黑树？.md | 137 +++ ...ConcurrentHashMap和Hashtable的区别.md | 71 ++ ...3CopyOnWriteArrayList有什么特点？.md | 346 ++++++ .../34什么是阻塞队列？.md | 78 ++ ...add、offer、put等方法的区别？.md | 220 ++++ .../36有哪几种常见的阻塞队列？.md | 105 ++ ...队列的并发安全原理是什么？.md | 191 ++++ ...何选择适合自己的阻塞队列？.md | 101 ++ ...如何利用CAS保证线程安全的？.md | 340 ++++++ ...能不好，如何解决？为什么？.md | 198 ++++ ...1原子类和volatile有什么异同？.md | 73 ++ ...icInteger和synchronized的异同点？.md | 182 +++ ...Adder和Accumulator有什么区别？.md | 129 +++ ...用在哪些实际生产的场景中？.md | 604 ++++++++++ ...资源的多线程访问的问题吗？.md | 120 ++ ...的threadlocals里是怎么存储的？.md | 164 +++ ...完ThreadLocal都要调用remove()？.md | 112 ++ .../48Callable和Runnable的不同？.md | 123 ++ .../49Future的主要功能是什么？.md | 330 ++++++ ...点？Future产生新的线程了吗？.md | 149 +++ ...Future实现“旅游平台”问题？.md | 315 ++++++ ...号量能被FixedThreadPool替代吗？.md | 305 +++++ ...是如何安排线程执行顺序的？.md | 222 ++++ ...rier和CountdownLatch有什么异同？.md | 215 ++++ ...、object.wait()和notify()的关系？.md | 348 ++++++ ...56讲一讲什么是Java内存模型？.md | 91 ++ ...令重排序？为什么要重排序？.md | 55 + ...的原子操作有哪些注意事项？.md | 82 ++ ...什么是“内存可见性”问题？.md | 189 ++++ .../60主内存和工作内存的关系？.md | 49 + .../61什么是happens-before规则？.md | 101 ++ ...么？与synchronized有什么异同？.md | 220 ++++ ...锁模式为什么必须加volatile？.md | 125 +++ .../64你知道什么是CAS吗？.md | 193 ++++ ...的关系，什么时候会用到CAS？.md | 181 +++ .../66CAS有什么缺点？.md | 59 + ...如何写一个必然死锁的例子？.md | 204 ++++ ...生死锁必须满足哪4个条件？.md | 139 +++ ...何用命令行和代码定位死锁？.md | 304 +++++ ...有哪些解决死锁问题的策略？.md | 329 ++++++ ...讲一讲经典的哲学家就餐问题.md | 253 +++++ .../72final的三种用法是什么？.md | 416 +++++++ ...却依然无法拥有“不变性”？.md | 207 ++++ ...么String被设计为是不可变的？.md | 124 ++ ...？AQS的作用和重要性是什么？.md | 93 ++ .../76AQS的内部原理是什么样的？.md | 136 +++ ...tch等类中的应用原理是什么？.md | 311 +++++ ...78一份独家的Java并发工具图谱.md | 178 +++ ...多线程初阶：解谜多线程世界.md | 286 +++++ ...线程池掌故：管理并发的秘籍.md | 692 ++++++++++++ .../03锁的奥秘：synchronized的秘密.md | 451 ++++++++ .../04锁的奥秘：Lock接口的秘密.md | 764 +++++++++++++ ...制并发流程，并发的巧妙编织.md | 725 ++++++++++++ ...dLocal之珍宝：线程的隐秘宝库.md | 508 +++++++++ .../07CAS：比肩而立的原子魔法.md | 592 ++++++++++ ...容器的魔力：并发世界的宝库.md | 768 +++++++++++++ .../09结果如何？线程的秘密告白.md | 353 ++++++ ...证并发安全的终极奥秘（上）.md | 411 +++++++ ...证并发安全的终极奥秘（中）.md | 304 +++++ ...证并发安全的终极奥秘（下）.md | 398 +++++++ ...，是进阶高级架构师的炼金石.md | 77 ++ ...些衡量指标？需要注意什么？.md | 174 +++ ...有章可循，谈谈常用的切入点.md | 128 +++ ...：哪些资源，容易成为瓶颈？.md | 242 ++++ ...践：如何获取代码性能数据？.md | 243 ++++ ...准测试JMH，精确测量方法性能.md | 383 +++++++ ...分析：缓冲区如何让代码加速.md | 262 +++++ ...在的缓存，高并发系统的法宝.md | 270 +++++ ...分析：Redis如何助力秒杀业务.md | 259 +++++ ...例分析：池化对象的应用场景.md | 190 ++++ ...：大对象复用的目标和注意点.md | 244 ++++ ...析：如何用设计模式优化性能.md | 213 ++++ ...：并行计算让代码“飞”起来.md | 369 ++++++ .../13案例分析：多线程锁的优化.md | 499 ++++++++ .../14案例分析：乐观锁和无锁.md | 310 +++++ ...案例分析：从BIO到NIO，再到AIO.md | 388 +++++++ ...分析：常见Java代码优化法则.md | 489 ++++++++ ...进阶：JVM如何完成垃圾回收？.md | 244 ++++ ...进阶：JIT如何影响JVM的性能？.md | 294 +++++ .../19高级进阶：JVM常见优化参数.md | 223 ++++ .../20SpringBoot服务性能优化.md | 373 ++++++ ...化的过程方法与求职面经总结.md | 283 +++++ .../22结束语实践出真知.md | 25 + ...效提升你的Java内功-极客时间.md | 60 + .../01谈谈你对Java平台的理解？.md | 74 ++ ...和Error有什么区别？-极客时间.md | 162 +++ ...finalize有什么不同？-极客时间.md | 176 +++ ...引用有什么区别？-极客时间.md | 177 +++ ...gBuilder有什么区别？-极客时间.md | 176 +++ ...是基于什么原理？-极客时间.md | 163 +++ 172 files changed, 53542 insertions(+) create mode 100644 专栏/JVM核心技术32讲（完）/28JVM问题排查分析下篇（案例实战）.md create mode 100644 专栏/JVM核心技术32讲（完）/29GC疑难情况问题排查与分析（上篇）.md create mode 100644 专栏/JVM核心技术32讲（完）/30GC疑难情况问题排查与分析（下篇）.md create mode 100644 专栏/JVM核心技术32讲（完）/31JVM相关的常见面试问题汇总：运筹策帷帐之中，决胜于千里之外.md create mode 100644 专栏/JVM核心技术32讲（完）/32应对容器时代面临的挑战：长风破浪会有时、直挂云帆济沧海.md create mode 100644 专栏/Java业务开发常见错误100例/00开篇词业务代码真的会有这么多坑？.md create mode 100644 专栏/Java业务开发常见错误100例/01使用了并发工具类库，线程安全就高枕无忧了吗？.md create mode 100644 专栏/Java业务开发常见错误100例/02代码加锁：不要让“锁”事成为烦心事.md create mode 100644 专栏/Java业务开发常见错误100例/03线程池：业务代码最常用也最容易犯错的组件.md create mode 100644 专栏/Java业务开发常见错误100例/04连接池：别让连接池帮了倒忙.md create mode 100644 专栏/Java业务开发常见错误100例/05HTTP调用：你考虑到超时、重试、并发了吗？.md create mode 100644 专栏/Java业务开发常见错误100例/062成的业务代码的Spring声明式事务，可能都没处理正确.md create mode 100644 专栏/Java业务开发常见错误100例/07数据库索引：索引并不是万能药.md create mode 100644 专栏/Java业务开发常见错误100例/08判等问题：程序里如何确定你就是你？.md create mode 100644 专栏/Java业务开发常见错误100例/09数值计算：注意精度、舍入和溢出问题.md create mode 100644 专栏/Java业务开发常见错误100例/10集合类：坑满地的List列表操作.md create mode 100644 专栏/Java业务开发常见错误100例/11空值处理：分不清楚的null和恼人的空指针.md create mode 100644 专栏/Java业务开发常见错误100例/12异常处理：别让自己在出问题的时候变为瞎子.md create mode 100644 专栏/Java业务开发常见错误100例/13日志：日志记录真没你想象的那么简单.md create mode 100644 专栏/Java业务开发常见错误100例/14文件IO：实现高效正确的文件读写并非易事.md create mode 100644 专栏/Java业务开发常见错误100例/15序列化：一来一回你还是原来的你吗？.md create mode 100644 专栏/Java业务开发常见错误100例/16用好Java8的日期时间类，少踩一些“老三样”的坑.md create mode 100644 专栏/Java业务开发常见错误100例/17别以为“自动挡”就不可能出现OOM.md create mode 100644 专栏/Java业务开发常见错误100例/18当反射、注解和泛型遇到OOP时，会有哪些坑？.md create mode 100644 专栏/Java业务开发常见错误100例/19Spring框架：IoC和AOP是扩展的核心.md create mode 100644 专栏/Java业务开发常见错误100例/20Spring框架：框架帮我们做了很多工作也带来了复杂度.md create mode 100644 专栏/Java业务开发常见错误100例/21代码重复：搞定代码重复的三个绝招.md create mode 100644 专栏/Java业务开发常见错误100例/22接口设计：系统间对话的语言，一定要统一.md create mode 100644 专栏/Java业务开发常见错误100例/23缓存设计：缓存可以锦上添花也可以落井下石.md create mode 100644 专栏/Java业务开发常见错误100例/24业务代码写完，就意味着生产就绪了？.md create mode 100644 专栏/Java业务开发常见错误100例/25异步处理好用，但非常容易用错.md create mode 100644 专栏/Java业务开发常见错误100例/26数据存储：NoSQL与RDBMS如何取长补短、相辅相成？.md create mode 100644 专栏/Java业务开发常见错误100例/27数据源头：任何客户端的东西都不可信任.md create mode 100644 专栏/Java业务开发常见错误100例/28安全兜底：涉及钱时，必须考虑防刷、限量和防重.md create mode 100644 专栏/Java业务开发常见错误100例/29数据和代码：数据就是数据，代码就是代码.md create mode 100644 专栏/Java业务开发常见错误100例/30如何正确保存和传输敏感数据？.md create mode 100644 专栏/Java业务开发常见错误100例/31加餐1：带你吃透课程中Java8的那些重要知识点（一）.md create mode 100644 专栏/Java业务开发常见错误100例/32加餐2：带你吃透课程中Java8的那些重要知识点（二）.md create mode 100644 专栏/Java业务开发常见错误100例/33加餐3：定位应用问题，排错套路很重要.md create mode 100644 专栏/Java业务开发常见错误100例/34加餐4：分析定位Java问题，一定要用好这些工具（一）.md create mode 100644 专栏/Java业务开发常见错误100例/35加餐5：分析定位Java问题，一定要用好这些工具（二）.md create mode 100644 专栏/Java业务开发常见错误100例/36加餐6：这15年来，我是如何在工作中学习技术和英语的？.md create mode 100644 专栏/Java业务开发常见错误100例/37加餐7：程序员成长28计.md create mode 100644 专栏/Java业务开发常见错误100例/38加餐8：Java程序从虚拟机迁移到Kubernetes的一些坑.md create mode 100644 专栏/Java业务开发常见错误100例/答疑篇：代码篇思考题集锦（一）.md create mode 100644 专栏/Java业务开发常见错误100例/答疑篇：代码篇思考题集锦（三）.md create mode 100644 专栏/Java业务开发常见错误100例/答疑篇：代码篇思考题集锦（二）.md create mode 100644 专栏/Java业务开发常见错误100例/答疑篇：加餐篇思考题答案合集.md create mode 100644 专栏/Java业务开发常见错误100例/答疑篇：安全篇思考题答案合集.md create mode 100644 专栏/Java业务开发常见错误100例/答疑篇：设计篇思考题答案合集.md create mode 100644 专栏/Java业务开发常见错误100例/结束语写代码时，如何才能尽量避免踩坑？.md create mode 100644 专栏/Java并发编程78讲-完/00由点及面，搭建你的Java并发知识网.md create mode 100644 专栏/Java并发编程78讲-完/01为何说只有1种实现线程的方法？.md create mode 100644 专栏/Java并发编程78讲-完/02如何正确停止线程？为什么volatile标记位的停止方法是错误的？.md create mode 100644 专栏/Java并发编程78讲-完/03线程是如何在6种状态之间转换的？.md create mode 100644 专栏/Java并发编程78讲-完/04waitnotifynotifyAll方法的使用注意事项？.md create mode 100644 专栏/Java并发编程78讲-完/05有哪几种实现生产者消费者模式的方法？.md create mode 100644 专栏/Java并发编程78讲-完/06一共有哪3类线程安全问题？.md create mode 100644 专栏/Java并发编程78讲-完/07哪些场景需要额外注意线程安全问题？.md create mode 100644 专栏/Java并发编程78讲-完/08为什么多线程会带来性能问题？.md create mode 100644 专栏/Java并发编程78讲-完/09使用线程池比手动创建线程好在哪里？.md create mode 100644 专栏/Java并发编程78讲-完/10线程池的各个参数的含义？.md create mode 100644 专栏/Java并发编程78讲-完/11线程池有哪4种拒绝策略？.md create mode 100644 专栏/Java并发编程78讲-完/12有哪6种常见的线程池？什么是Java8的ForkJoinPool？.md create mode 100644 专栏/Java并发编程78讲-完/13线程池常用的阻塞队列有哪些？.md create mode 100644 专栏/Java并发编程78讲-完/14为什么不应该自动创建线程池？.md create mode 100644 专栏/Java并发编程78讲-完/15合适的线程数量是多少？CPU核心数和线程数的关系？.md create mode 100644 专栏/Java并发编程78讲-完/16如何根据实际需要，定制自己的线程池？.md create mode 100644 专栏/Java并发编程78讲-完/17如何正确关闭线程池？shutdown和shutdownNow的区别？.md create mode 100644 专栏/Java并发编程78讲-完/18线程池实现“线程复用”的原理？.md create mode 100644 专栏/Java并发编程78讲-完/19你知道哪几种锁？分别有什么特点？.md create mode 100644 专栏/Java并发编程78讲-完/20悲观锁和乐观锁的本质是什么？.md create mode 100644 专栏/Java并发编程78讲-完/21如何看到synchronized背后的“monitor锁”？.md create mode 100644 专栏/Java并发编程78讲-完/22synchronized和Lock孰优孰劣，如何选择？.md create mode 100644 专栏/Java并发编程78讲-完/23Lock有哪几个常用方法？分别有什么用？.md create mode 100644 专栏/Java并发编程78讲-完/24讲一讲公平锁和非公平锁，为什么要“非公平”？.md create mode 100644 专栏/Java并发编程78讲-完/25读写锁ReadWriteLock获取锁有哪些规则？.md create mode 100644 专栏/Java并发编程78讲-完/26读锁应该插队吗？什么是读写锁的升降级？.md create mode 100644 专栏/Java并发编程78讲-完/27什么是自旋锁？自旋的好处和后果是什么呢？.md create mode 100644 专栏/Java并发编程78讲-完/28JVM对锁进行了哪些优化？.md create mode 100644 专栏/Java并发编程78讲-完/29HashMap为什么是线程不安全的？.md create mode 100644 专栏/Java并发编程78讲-完/30ConcurrentHashMap在Java7和8有何不同？.md create mode 100644 专栏/Java并发编程78讲-完/31为什么Map桶中超过8个才转为红黑树？.md create mode 100644 专栏/Java并发编程78讲-完/32同样是线程安全，ConcurrentHashMap和Hashtable的区别.md create mode 100644 专栏/Java并发编程78讲-完/33CopyOnWriteArrayList有什么特点？.md create mode 100644 专栏/Java并发编程78讲-完/34什么是阻塞队列？.md create mode 100644 专栏/Java并发编程78讲-完/35阻塞队列包含哪些常用的方法？add、offer、put等方法的区别？.md create mode 100644 专栏/Java并发编程78讲-完/36有哪几种常见的阻塞队列？.md create mode 100644 专栏/Java并发编程78讲-完/37阻塞和非阻塞队列的并发安全原理是什么？.md create mode 100644 专栏/Java并发编程78讲-完/38如何选择适合自己的阻塞队列？.md create mode 100644 专栏/Java并发编程78讲-完/39原子类是如何利用CAS保证线程安全的？.md create mode 100644 专栏/Java并发编程78讲-完/40AtomicInteger在高并发下性能不好，如何解决？为什么？.md create mode 100644 专栏/Java并发编程78讲-完/41原子类和volatile有什么异同？.md create mode 100644 专栏/Java并发编程78讲-完/42AtomicInteger和synchronized的异同点？.md create mode 100644 专栏/Java并发编程78讲-完/43Java8中Adder和Accumulator有什么区别？.md create mode 100644 专栏/Java并发编程78讲-完/44ThreadLocal适合用在哪些实际生产的场景中？.md create mode 100644 专栏/Java并发编程78讲-完/45ThreadLocal是用来解决共享资源的多线程访问的问题吗？.md create mode 100644 专栏/Java并发编程78讲-完/46多个ThreadLocal在Thread中的threadlocals里是怎么存储的？.md create mode 100644 专栏/Java并发编程78讲-完/47内存泄漏——为何每次用完ThreadLocal都要调用remove()？.md create mode 100644 专栏/Java并发编程78讲-完/48Callable和Runnable的不同？.md create mode 100644 专栏/Java并发编程78讲-完/49Future的主要功能是什么？.md create mode 100644 专栏/Java并发编程78讲-完/50使用Future有哪些注意点？Future产生新的线程了吗？.md create mode 100644 专栏/Java并发编程78讲-完/51如何利用CompletableFuture实现“旅游平台”问题？.md create mode 100644 专栏/Java并发编程78讲-完/52信号量能被FixedThreadPool替代吗？.md create mode 100644 专栏/Java并发编程78讲-完/53CountDownLatch是如何安排线程执行顺序的？.md create mode 100644 专栏/Java并发编程78讲-完/54CyclicBarrier和CountdownLatch有什么异同？.md create mode 100644 专栏/Java并发编程78讲-完/55Condition、object.wait()和notify()的关系？.md create mode 100644 专栏/Java并发编程78讲-完/56讲一讲什么是Java内存模型？.md create mode 100644 专栏/Java并发编程78讲-完/57什么是指令重排序？为什么要重排序？.md create mode 100644 专栏/Java并发编程78讲-完/58Java中的原子操作有哪些注意事项？.md create mode 100644 专栏/Java并发编程78讲-完/59什么是“内存可见性”问题？.md create mode 100644 专栏/Java并发编程78讲-完/60主内存和工作内存的关系？.md create mode 100644 专栏/Java并发编程78讲-完/61什么是happens-before规则？.md create mode 100644 专栏/Java并发编程78讲-完/62volatile的作用是什么？与synchronized有什么异同？.md create mode 100644 专栏/Java并发编程78讲-完/63单例模式的双重检查锁模式为什么必须加volatile？.md create mode 100644 专栏/Java并发编程78讲-完/64你知道什么是CAS吗？.md create mode 100644 专栏/Java并发编程78讲-完/65CAS和乐观锁的关系，什么时候会用到CAS？.md create mode 100644 专栏/Java并发编程78讲-完/66CAS有什么缺点？.md create mode 100644 专栏/Java并发编程78讲-完/67如何写一个必然死锁的例子？.md create mode 100644 专栏/Java并发编程78讲-完/68发生死锁必须满足哪4个条件？.md create mode 100644 专栏/Java并发编程78讲-完/69如何用命令行和代码定位死锁？.md create mode 100644 专栏/Java并发编程78讲-完/70有哪些解决死锁问题的策略？.md create mode 100644 专栏/Java并发编程78讲-完/71讲一讲经典的哲学家就餐问题.md create mode 100644 专栏/Java并发编程78讲-完/72final的三种用法是什么？.md create mode 100644 专栏/Java并发编程78讲-完/73为什么加了final却依然无法拥有“不变性”？.md create mode 100644 专栏/Java并发编程78讲-完/74为什么String被设计为是不可变的？.md create mode 100644 专栏/Java并发编程78讲-完/75为什么需要AQS？AQS的作用和重要性是什么？.md create mode 100644 专栏/Java并发编程78讲-完/76AQS的内部原理是什么样的？.md create mode 100644 专栏/Java并发编程78讲-完/77AQS在CountDownLatch等类中的应用原理是什么？.md create mode 100644 专栏/Java并发编程78讲-完/78一份独家的Java并发工具图谱.md create mode 100644 专栏/Java并发：JUC入门与进阶/01多线程初阶：解谜多线程世界.md create mode 100644 专栏/Java并发：JUC入门与进阶/02线程池掌故：管理并发的秘籍.md create mode 100644 专栏/Java并发：JUC入门与进阶/03锁的奥秘：synchronized的秘密.md create mode 100644 专栏/Java并发：JUC入门与进阶/04锁的奥秘：Lock接口的秘密.md create mode 100644 专栏/Java并发：JUC入门与进阶/05控制并发流程，并发的巧妙编织.md create mode 100644 专栏/Java并发：JUC入门与进阶/06ThreadLocal之珍宝：线程的隐秘宝库.md create mode 100644 专栏/Java并发：JUC入门与进阶/07CAS：比肩而立的原子魔法.md create mode 100644 专栏/Java并发：JUC入门与进阶/08容器的魔力：并发世界的宝库.md create mode 100644 专栏/Java并发：JUC入门与进阶/09结果如何？线程的秘密告白.md create mode 100644 专栏/Java并发：JUC入门与进阶/10AQS：保证并发安全的终极奥秘（上）.md create mode 100644 专栏/Java并发：JUC入门与进阶/11AQS：保证并发安全的终极奥秘（中）.md create mode 100644 专栏/Java并发：JUC入门与进阶/12AQS：保证并发安全的终极奥秘（下）.md create mode 100644 专栏/Java性能优化实战-完/00Java性能优化，是进阶高级架构师的炼金石.md create mode 100644 专栏/Java性能优化实战-完/01理论分析：性能优化，有哪些衡量指标？需要注意什么？.md create mode 100644 专栏/Java性能优化实战-完/02理论分析：性能优化有章可循，谈谈常用的切入点.md create mode 100644 专栏/Java性能优化实战-完/03深入剖析：哪些资源，容易成为瓶颈？.md create mode 100644 专栏/Java性能优化实战-完/04工具实践：如何获取代码性能数据？.md create mode 100644 专栏/Java性能优化实战-完/05工具实践：基准测试JMH，精确测量方法性能.md create mode 100644 专栏/Java性能优化实战-完/06案例分析：缓冲区如何让代码加速.md create mode 100644 专栏/Java性能优化实战-完/07案例分析：无处不在的缓存，高并发系统的法宝.md create mode 100644 专栏/Java性能优化实战-完/08案例分析：Redis如何助力秒杀业务.md create mode 100644 专栏/Java性能优化实战-完/09案例分析：池化对象的应用场景.md create mode 100644 专栏/Java性能优化实战-完/10案例分析：大对象复用的目标和注意点.md create mode 100644 专栏/Java性能优化实战-完/11案例分析：如何用设计模式优化性能.md create mode 100644 专栏/Java性能优化实战-完/12案例分析：并行计算让代码“飞”起来.md create mode 100644 专栏/Java性能优化实战-完/13案例分析：多线程锁的优化.md create mode 100644 专栏/Java性能优化实战-完/14案例分析：乐观锁和无锁.md create mode 100644 专栏/Java性能优化实战-完/15案例分析：从BIO到NIO，再到AIO.md create mode 100644 专栏/Java性能优化实战-完/16案例分析：常见Java代码优化法则.md create mode 100644 专栏/Java性能优化实战-完/17高级进阶：JVM如何完成垃圾回收？.md create mode 100644 专栏/Java性能优化实战-完/18高级进阶：JIT如何影响JVM的性能？.md create mode 100644 专栏/Java性能优化实战-完/19高级进阶：JVM常见优化参数.md create mode 100644 专栏/Java性能优化实战-完/20SpringBoot服务性能优化.md create mode 100644 专栏/Java性能优化实战-完/21性能优化的过程方法与求职面经总结.md create mode 100644 专栏/Java性能优化实战-完/22结束语实践出真知.md create mode 100644 专栏/Java核心技术面试精讲/00开篇词以面试题为切入点，有效提升你的Java内功-极客时间.md create mode 100644 专栏/Java核心技术面试精讲/01谈谈你对Java平台的理解？.md create mode 100644 专栏/Java核心技术面试精讲/02Exception和Error有什么区别？-极客时间.md create mode 100644 专栏/Java核心技术面试精讲/03谈谈final、finally、finalize有什么不同？-极客时间.md create mode 100644 专栏/Java核心技术面试精讲/04强引用、软引用、弱引用、幻象引用有什么区别？-极客时间.md create mode 100644 专栏/Java核心技术面试精讲/05String、StringBuffer、StringBuilder有什么区别？-极客时间.md create mode 100644 专栏/Java核心技术面试精讲/06动态代理是基于什么原理？-极客时间.md diff --git a/专栏/JVM核心技术32讲（完）/28JVM问题排查分析下篇（案例实战）.md b/专栏/JVM核心技术32讲（完）/28JVM问题排查分析下篇（案例实战）.md new file mode 100644 index 0000000..6160a7c --- /dev/null +++ b/专栏/JVM核心技术32讲（完）/28JVM问题排查分析下篇（案例实战）.md @@ -0,0 +1,355 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 28 JVM 问题排查分析下篇（案例实战） + GC 问题排查实战案例 + +这一部分，我们来看一个实际的案例。 + +假设我们有一个提供高并发请求的服务，系统使用 Spring Boot 框架，指标采集使用 MicroMeter，监控数据上报给 Datadog 服务。 + +当然，Micrometer支 持将数据上报给各种监控系统，例如：AppOptics、Atlas、Datadog、Dynatrace、Elastic、Ganglia、Graphite、Humio、Influx、Instana、JMX、KairosDB、New Relic、Prometh eus、SignalFx、Stackdriver、StatsD、Wavefront 等等。 + +有关MicroMeter的信息可参考： + + +https://micrometer.io/docs + + +问题现象描述 + +最近一段时间，通过监控指标发现，有一个服务节点的最大 GC 暂停时间经常会达到 400ms 以上。 + +如下图所示： + + + +从图中可以看到，GC 暂停时间的峰值达到了 546ms，这里展示的时间点是 2020 年 02 月 04 日 09:20:00 左右。 + +客户表示这种情况必须解决，因为服务调用的超时时间为 1s，要求最大 GC 暂停时间不超过 200ms，平均暂停时间达到 100ms 以内，对客户的交易策略产生了极大的影响。 + +CPU 负载 + +CPU 的使用情况如下图所示： + + + +从图中可以看到：系统负载为 4.92，CPU使用率 7% 左右，其实这个图中隐含了一些重要的线索，但我们此时并没有发现什么问题。 + +GC 内存使用情况 + +然后我们排查了这段时间的内存使用情况： + + + +从图中可以看到，大约 09:25 左右 old_gen 使用量大幅下跌，确实是发生了 FullGC。 + +但 09:20 前后，老年代空间的使用量在缓慢上升，并没有下降，也就是说引发最大暂停时间的这个点并没有发生 FullGC。 + +当然，这些是事后复盘分析得出的结论。当时对监控所反馈的信息并不是特别信任，怀疑就是触发了 FullGC 导致的长时间 GC 暂停。 + + +为什么有怀疑呢，因为 Datadog 这个监控系统，默认 10s 上报一次数据。有可能在这 10s 内发生些什么事情但是被漏报了（当然，这是不可能的，如果上报失败会在日志系统中打印相关的错误）。 + + +再分析上面这个图，可以看到老年代对应的内存池是 “ps_old_gen”，通过前面的学习，我们知道，ps 代表的是 ParallelGC 垃圾收集器。 + +JVM 启动参数 + +查看 JVM 的启动参数，发现是这样的： + +-Xmx4g -Xms4g + + + +我们使用的是 JDK 8，启动参数中没有指定 GC，确定这个服务使用了默认的并行垃圾收集器。 + +于是怀疑问题出在这款垃圾收集器上面，因为很多情况下 ParallelGC 为了最大的系统处理能力，即吞吐量，而牺牲掉了单次的暂停时间，导致暂停时间会比较长。 + +使用 G1 垃圾收集器 + +怎么办呢？准备换成 G1，毕竟现在新版本的 JDK 8 中 G1 很稳定，而且性能不错。 + +然后换成了下面的启动参数： + +# 这个参数有问题，启动失败 +-Xmx4g -Xms4g -XX:+UseG1GC -XX:MaxGCPauseMills=50ms + + + +结果启动失败，忙中出错，参数名和参数值都写错了。 + +修正如下： + +-Xmx4g -Xms4g -XX:+UseG1GC -XX:MaxGCPauseMillis=50 + + + +接着服务启动成功，等待健康检测自动切换为新的服务节点，继续查看指标。 + + + +看看暂停时间，每个节点的 GC 暂停时间都降下来了，基本上在 50ms 以内，比较符合我们的预期。 + +嗯！事情到此结束了？远远没有。 + +“彩蛋”惊喜 + +过了一段时间，我们发现了个下面这个惊喜（也许是惊吓），如下图所示： + + + +中奖了，运行一段时间后，最大 GC 暂停时间达到了 1300ms。 + +情况似乎更恶劣了。 + +继续观察，发现不是个别现象： + + + +内心是懵的，觉得可能是指标算错了，比如把 10s 内的暂停时间全部加到了一起。 + +注册 GC 事件监听 + +于是想了个办法，通过 JMX 注册 GC 事件监听，把相关的信息直接打印出来。 + +关键代码如下所示： + +// 每个内存池都注册监听 +for (GarbageCollectorMXBean mbean + : ManagementFactory.getGarbageCollectorMXBeans()) { + if (!(mbean instanceof NotificationEmitter)) { + continue; // 假如不支持监听... + } + final NotificationEmitter emitter = (NotificationEmitter) mbean; + // 添加监听 + final NotificationListener listener = getNewListener(mbean); + emitter.addNotificationListener(listener, null, null); +} + + + +通过这种方式，我们可以在程序中监听 GC 事件，并将相关信息汇总或者输出到日志。 具体的实现代码在后面的章节《应对容器时代面临的挑战》中给出。 + +再启动一次，运行一段时间后，看到下面这样的日志信息： + +{ +"duration":1869, +"maxPauseMillis":1869, +"promotedBytes":"139MB", +"gcCause":"G1 Evacuation Pause", +"collectionTime":27281, +"gcAction":"end of minor GC", +"afterUsage": + { + "G1 Old Gen":"1745MB", + "Code Cache":"53MB", + "G1 Survivor Space":"254MB", + "Compressed Class Space":"9MB", + "Metaspace":"81MB", + "G1 Eden Space":"0" + }, +"gcId":326, +"collectionCount":326, +"gcName":"G1 Young Generation", +"type":"jvm.gc.pause" +} + + + +情况确实有点不妙。 + +这次实锤了，不是 FullGC，而是年轻代 GC，而且暂停时间达到了 1869ms。 一点道理都不讲，我认为这种情况不合理，而且观察 CPU 使用量也不高。 + +找了一大堆资料，试图证明这个 1869ms 不是暂停时间，而只是 GC 事件的结束时间减去开始时间。 + +打印 GC 日志 + +既然这些手段不靠谱，那就只有祭出我们的终极手段：打印 GC 日志。 + +修改启动参数如下： + +-Xmx4g -Xms4g -XX:+UseG1GC -XX:MaxGCPauseMillis=50 +-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps + + + +重新启动，希望这次能排查出问题的原因。 + + + +运行一段时间，又发现了超长的暂停时间。 + +分析 GC 日志 + +因为不涉及敏感数据，那么我们把 GC 日志下载到本地进行分析。 + +定位到这次暂停时间超长的 GC 事件，关键的信息如下所示： + +Java HotSpot(TM) 64-Bit Server VM (25.162-b12) for linux-amd64 JRE (1.8.0_162-b12), + built on Dec 19 2017 21:15:48 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) +Memory: 4k page, physical 144145548k(58207948k free), swap 0k(0k free) +CommandLine flags: + -XX:InitialHeapSize=4294967296 -XX:MaxGCPauseMillis=50 -XX:MaxHeapSize=4294967296 + -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps + -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC + +2020-02-24T18:02:31.853+0800: 2411.124: [GC pause (G1 Evacuation Pause) (young), 1.8683418 secs] + [Parallel Time: 1861.0 ms, GC Workers: 48] + [GC Worker Start (ms): Min: 2411124.3, Avg: 2411125.4, Max: 2411126.2, Diff: 1.9] + [Ext Root Scanning (ms): Min: 0.0, Avg: 0.3, Max: 2.7, Diff: 2.7, Sum: 16.8] + [Update RS (ms): Min: 0.0, Avg: 3.6, Max: 6.8, Diff: 6.8, Sum: 172.9] + [Processed Buffers: Min: 0, Avg: 2.3, Max: 8, Diff: 8, Sum: 111] + [Scan RS (ms): Min: 0.0, Avg: 0.2, Max: 0.5, Diff: 0.5, Sum: 7.7] + [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.3] + [Object Copy (ms): Min: 1851.6, Avg: 1854.6, Max: 1857.4, Diff: 5.8, Sum: 89020.4] + [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.6] + [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 48] + [GC Worker Other (ms): Min: 0.0, Avg: 0.3, Max: 0.7, Diff: 0.6, Sum: 14.7] + [GC Worker Total (ms): Min: 1858.0, Avg: 1859.0, Max: 1860.3, Diff: 2.3, Sum: 89233.3] + [GC Worker End (ms): Min: 2412984.1, Avg: 2412984.4, Max: 2412984.6, Diff: 0.5] + [Code Root Fixup: 0.0 ms] + [Code Root Purge: 0.0 ms] + [Clear CT: 1.5 ms] + [Other: 5.8 ms] + [Choose CSet: 0.0 ms] + [Ref Proc: 1.7 ms] + [Ref Enq: 0.0 ms] + [Redirty Cards: 1.1 ms] + [Humongous Register: 0.1 ms] + [Humongous Reclaim: 0.0 ms] + [Free CSet: 2.3 ms] + [Eden: 2024.0M(2024.0M)->0.0B(2048.0K) + Survivors: 2048.0K->254.0M + Heap: 3633.6M(4096.0M)->1999.3M(4096.0M)] + [Times: user=1.67 sys=14.00, real=1.87 secs] + + + +前后的 GC 事件都很正常，也没发现 FullGC 或者并发标记周期，但找到了几个可疑的点。 + + +physical 144145548k(58207948k free)：JVM 启动时，物理内存 137GB，空闲内存 55GB。 +[Parallel Time: 1861.0 ms, GC Workers: 48]：垃圾收集器工作线程 48 个。 + + +我们前面的课程中学习了怎样分析 GC 日志，一起来回顾一下。 + + +user=1.67：用户线程耗时 1.67s； +sys=14.00：系统调用和系统等待时间 14s； +real=1.87 secs：实际暂停时间 1.87s； +GC 之前，年轻代使用量 2GB，堆内存使用量 3.6GB，存活区 2MB，可推断出老年代使用量 1.6GB； +GC 之后，年轻代使用量为 0，堆内存使用量 2GB，存活区 254MB，那么老年代大约 1.8GB，那么“内存提升量为 200MB 左右”。 + + +这样分析之后，可以得出结论： + + +年轻代转移暂停，复制了 400MB 左右的对象，却消耗了 1.8s，系统调用和系统等待的时间达到了 14s。 +JVM 看到的物理内存 137GB。 +推算出 JVM 看到的 CPU 内核数量 72个，因为 GC 工作线程 72* 5/8 ~= 48 个。 + + +看到这么多的 GC 工作线程我就开始警惕了，毕竟堆内存才指定了 4GB。 + +按照一般的 CPU 和内存资源配比，常见的比例差不多是 4 核 4GB、4 核 8GB 这样的。 + +看看对应的 CPU 负载监控信息： + + + +通过和运维同学的沟通，得到这个节点的配置被限制为 4 核 8GB。 + +这样一来，GC 暂停时间过长的原因就定位到了： + + +K8S 的资源隔离和 JVM 未协调好，导致 JVM 看见了 72 个 CPU 内核，默认的并行 GC 线程设置为 72* 5/8 ~= 48 个，但是 K8S 限制了这个 Pod 只能使用 4 个 CPU 内核的计算量，致使 GC 发生时，48 个线程在 4 个 CPU 核心上发生资源竞争，导致大量的上下文切换。 + + +处置措施为： + + +限制 GC 的并行线程数量 + + +事实证明，打印 GC 日志确实是一个很有用的排查分析方法。 + +限制 GC 的并行线程数量 + +下面是新的启动参数配置： + + -Xmx4g -Xms4g + -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:ParallelGCThreads=4 + -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps + + + +这里指定了 -XX:ParallelGCThreads=4，为什么这么配呢？我们看看这个参数的说明。 + +-XX:ParallelGCThreads=n + + + +设置 STW 阶段的并行 worker 线程数量。 如果逻辑处理器小于等于 8 个，则默认值 n 等于逻辑处理器的数量。 + +如果逻辑处理器大于 8 个，则默认值 n 大约等于处理器数量的 5/8。在大多数情况下都是个比较合理的值。如果是高配置的 SPARC 系统，则默认值 n 大约等于逻辑处理器数量的 5/16。 + +-XX:ConcGCThreads=n + + + +设置并发标记的 GC 线程数量。默认值大约是 ParallelGCThreads 的四分之一。 + +一般来说不用指定并发标记的 GC 线程数量，只用指定并行的即可。 + +重新启动之后，看看 GC 暂停时间指标： + + + +红色箭头所指示的点就是重启的时间点，可以发现，暂停时间基本上都处于 50ms 范围内。 + +后续的监控发现，这个参数确实解决了问题。 + +那么还有没有其他的办法呢？请关注后续的章节《应对容器时代面临的挑战》。 + +小结 + +通过这个案例，我们可以看到，JVM 问题排查和性能调优主要基于监控数据来进行。 + +还是那句话：没有量化，就没有改进。 + +简单汇总一下这里使用到的手段： + + +指标监控 +指定 JVM 启动内存 +指定垃圾收集器 +打印和分析 GC 日志 + + +GC 和内存是最常见的 JVM 调优场景，还记得课程开始时我们介绍的 GC 的性能维度吗？ + + +延迟，GC 中影响延迟的主要因素就是暂停时间。 +吞吐量，主要看业务线程消耗的 CPU 资源百分比，GC 占用的部分包括：GC 暂停时间，以及高负载情况下并发 GC 消耗的 CPU 资源。 +系统容量，主要说的是硬件配置，以及服务能力。 + + +只要这些方面的指标都能够满足，各种资源占用也保持在合理范围内，就达成了我们的预期。 + +参考 + + +Native Memory Tracking（NMT，Native 内存跟踪）排查文档 +生产环境 GC 参数调优 +https://plumbr.io/blog/monitoring/why-is-troubleshooting-so-hard +Linux 的性能调优的思路 +Linux 工具快速教程 + + + + + \ No newline at end of file diff --git a/专栏/JVM核心技术32讲（完）/29GC疑难情况问题排查与分析（上篇）.md b/专栏/JVM核心技术32讲（完）/29GC疑难情况问题排查与分析（上篇）.md new file mode 100644 index 0000000..eebe5bb --- /dev/null +++ b/专栏/JVM核心技术32讲（完）/29GC疑难情况问题排查与分析（上篇）.md @@ -0,0 +1,388 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 29 GC 疑难情况问题排查与分析（上篇） + 本章介绍导致 GC 性能问题的典型情况。相关示例都来源于生产环境，为演示需要做了一定程度的精简。 + + +名词说明：Allocation Rate，翻译为“分配速率”，而不是分配率。因为不是百分比，而是单位时间内分配的量。同理，Promotion Rate 翻译为“提升速率”。 + + +高分配速率（High Allocation Rate） + +分配速率（Allocation Rate）表示单位时间内分配的内存量。通常使用 MB/sec 作为单位，也可以使用 PB/year 等。分配速率过高就会严重影响程序的性能，在 JVM 中可能会导致巨大的 GC 开销。 + +如何测量分配速率？ + +通过指定 JVM 参数：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，通过 GC 日志来计算分配速率。GC 日志如下所示： + + 0.291: [GC (Allocation Failure) + [PSYoungGen: 33280K->5088K(38400K)] + 33280K->24360K(125952K), 0.0365286 secs] + [Times: user=0.11 sys=0.02, real=0.04 secs] + 0.446: [GC (Allocation Failure) + [PSYoungGen: 38368K->5120K(71680K)] + 57640K->46240K(159232K), 0.0456796 secs] + [Times: user=0.15 sys=0.02, real=0.04 secs] + 0.829: [GC (Allocation Failure) + [PSYoungGen: 71680K->5120K(71680K)] + 112800K->81912K(159232K), 0.0861795 secs] + [Times: user=0.23 sys=0.03, real=0.09 secs] + + + +具体就是计算上一次垃圾收集之后，与下一次 GC 开始之前的年轻代使用量，两者的差值除以时间，就是分配速率。通过上面的日志，可以计算出以下信息： + + +JVM 启动之后 291ms，共创建了 33280KB 的对象。第一次 Minor GC（小型 GC）完成后，年轻代中还有 5088KB 的对象存活。 +在启动之后 446ms，年轻代的使用量增加到 38368KB，触发第二次 GC，完成后年轻代的使用量减少到 5120KB。 +在启动之后 829ms，年轻代的使用量为 71680KB，GC 后变为 5120KB。 + + +可以通过年轻代的使用量来计算分配速率，如下表所示： + + + + +Event +Time +Young before +Young after +Allocated during +Allocation rate + + + + + +1st GC +291ms +33,280KB +5,088KB +33,280KB +114MB/sec + + + +2nd GC +446ms +38,368KB +5,120KB +33,280KB +215MB/sec + + + +3rd GC +829ms +71,680KB +5,120KB +66,560KB +174MB/sec + + + +Total +829ms +N/A +N/A +133,120KB +161MB/sec + + + +通过这些信息可以知道，在此期间，该程序的内存分配速率为 16MB/sec。 + +分配速率的意义 + +分配速率的变化，会增加或降低 GC 暂停的频率，从而影响吞吐量。但只有年轻代的 Minor GC 受分配速率的影响，老年代 GC 的频率和持续时间一般不受 分配速率（Allocation Rate）的直接影响（想想为什么？），而是受到 提升速率（Promotion Rate）的影响，请参见下文。 + +现在我们只关心 Minor GC 暂停，查看年轻代的 3 个内存池。因为对象在 Eden 区分配，所以我们一起来看 Eden 区的大小和分配速率的关系。看看增加 Eden 区的容量，能不能减少 Minor GC 暂停次数，从而使程序能够维持更高的分配速率。 + +经过我们的实验，通过参数 -XX:NewSize、-XX:MaxNewSize 以及 -XX:SurvivorRatio 设置不同的 Eden 空间，运行同一程序时，可以发现： + + +Eden 空间为 100MB 时，分配速率低于 100MB/秒。 +将 Eden 区增大为 1GB，分配速率也随之增长，大约等于 200MB/秒。 + + +为什么会这样？ + +因为减少 GC 暂停，就等价于减少了任务线程的停顿，就可以做更多工作，也就创建了更多对象，所以对同一应用来说，分配速率越高越好。 + +在得出“Eden 区越大越好”这个结论前，我们注意到：分配速率可能会、也可能不会影响程序的实际吞吐量。 + +总而言之，吞吐量和分配速率有一定关系，因为分配速率会影响 Minor GC 暂停，但对于总体吞吐量的影响，还要考虑 Major GC 暂停等。 + +示例 + +参考 Demo 程序。假设系统连接了一个外部的数字传感器。应用通过专有线程，不断地获取传感器的值（此处使用随机数模拟），其他线程会调用 processSensorValue() 方法，传入传感器的值来执行某些操作。 + + public class BoxingFailure { + private static volatile Double sensorValue; + + private static void readSensor() { + while(true) sensorValue = Math.random(); + } + + private static void processSensorValue(Double value) { + if(value != null) { + //... + } + } + } + + + +如同类名所示，这个 Demo 是模拟 boxing 的。为了 null 值判断，使用的是包装类型 Double。程序基于传感器的最新值进行计算，但从传感器取值是一个耗时的操作，所以采用了异步方式：一个线程不断获取新值，计算线程则直接使用暂存的最新值，从而避免同步等待。 + +Demo 程序在运行的过程中，由于分配速率太大而受到 GC 的影响。下面将确认问题，并给出解决办法。 + +高分配速率对 JVM 的影响 + +首先，我们应该检查程序的吞吐量是否降低。如果创建了过多的临时对象，Minor GC 的次数就会增加。如果并发较大，则 GC 可能会严重影响吞吐量。 + +遇到这种情况时，GC 日志将会像下面这样，当然这是上面的示例程序 产生的 GC 日志。 + +JVM 启动参数为：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmx32m。 + + 2.808: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0003076 secs] + 2.819: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0003079 secs] + 2.830: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0002968 secs] + 2.842: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0003374 secs] + 2.853: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0004672 secs] + 2.864: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0003371 secs] + 2.875: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0003214 secs] + 2.886: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0003374 secs] + 2.896: [GC (Allocation Failure) + [PSYoungGen: 9760K->32K(10240K)], 0.0003588 secs] + + + +很显然 Minor GC 的频率太高了。这说明创建了大量的对象。另外，年轻代在 GC 之后的使用量又很低，也没有 Full GC 发生。种种迹象表明，GC 对吞吐量造成了严重的影响。 + +解决方案 + +在某些情况下，只要增加年轻代的大小，即可降低分配速率过高所造成的影响。增加年轻代空间并不会降低分配速率，但是会减少 GC 的频率。如果每次 GC 后只有少量对象存活，Minor GC 的暂停时间就不会明显增加。 + +运行 示例程序 时，增加堆内存大小（同时也就增大了年轻代的大小），使用的 JVM 参数为：-Xmx64m。 + + 2.808: [GC (Allocation Failure) + [PSYoungGen: 20512K->32K(20992K)], 0.0003748 secs] + 2.831: [GC (Allocation Failure) + [PSYoungGen: 20512K->32K(20992K)], 0.0004538 secs] + 2.855: [GC (Allocation Failure) + [PSYoungGen: 20512K->32K(20992K)], 0.0003355 secs] + 2.879: [GC (Allocation Failure) + [PSYoungGen: 20512K->32K(20992K)], 0.0005592 secs] + + + +但有时候增加堆内存的大小，并不能解决问题。 + +通过前面学到的知识，我们可以通过分配分析器找出大部分垃圾产生的位置。实际上，在此示例中 99% 的对象属于 Double 包装类，在readSensor 方法中创建。 + +最简单的优化，将创建的 Double 对象替换为原生类型 double，而针对 null 值的检测，可以使用 Double.NaN 来进行。 + +由于原生类型不算是对象，也就不会产生垃圾，导致 GC 事件。 + +优化之后，不在堆中分配新对象，而是直接覆盖一个属性域即可。对示例程序进行简单的改造（查看 diff）后，GC 暂停基本上完全消除。 + +有时候 JVM 也很智能，会使用逃逸分析技术（Escape Analysis Technique）来避免过度分配。 + +简单来说，JIT 编译器可以通过分析得知，方法创建的某些对象永远都不会“逃出”此方法的作用域。这时候就不需要在堆上分配这些对象，也就不会产生垃圾，所以 JIT 编译器的一种优化手段就是：消除堆上内存分配（请参考基准测试）。 + +过早提升（Premature Promotion） + +提升速率（Promotion Rate）用于衡量单位时间内从年轻代提升到老年代的数据量。一般使用 MB/sec 作为单位，和“分配速率”类似。 + +JVM 会将长时间存活的对象从年轻代提升到老年代。根据分代假设，可能存在一种情况，老年代中不仅有存活时间长的对象，也可能有存活时间短的对象。这就是过早提升：对象存活时间还不够长的时候就被提升到了老年代。 + +Major GC 不是为频繁回收而设计的，但 Major GC 现在也要清理这些生命短暂的对象，就会导致 GC 暂停时间过长。这会严重影响系统的吞吐量。 + +如何测量提升速率 + +可以指定 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，通过 GC 日志来测量提升速率。JVM 记录的 GC 暂停信息如下所示： + + 0.291: [GC (Allocation Failure) + [PSYoungGen: 33280K->5088K(38400K)] + 33280K->24360K(125952K), 0.0365286 secs] + [Times: user=0.11 sys=0.02, real=0.04 secs] + 0.446: [GC (Allocation Failure) + [PSYoungGen: 38368K->5120K(71680K)] + 57640K->46240K(159232K), 0.0456796 secs] + [Times: user=0.15 sys=0.02, real=0.04 secs] + 0.829: [GC (Allocation Failure) + [PSYoungGen: 71680K->5120K(71680K)] + 112800K->81912K(159232K), 0.0861795 secs] + [Times: user=0.23 sys=0.03, real=0.09 secs] + + + +从上面的日志可以得知：GC 之前和之后的年轻代使用量以及堆内存使用量。这样就可以通过差值算出老年代的使用量。GC 日志中的信息可以表述为： + + + + +Event +Time +Young decreased +Total decreased +Promoted +Promotion rate + + + + + +（事件） +（耗时） +（年轻代减少） +（整个堆内存减少） +（提升量） +（提升速率） + + + +1st GC +291ms +28192K +8920K +19272K +66.2 MB/sec + + + +2nd GC +446ms +33248K +11400K +21848K +140.95 MB/sec + + + +3rd GC +829ms +66560K +30888K +35672K +93.14 MB/sec + + + +Total +829ms + + +76792K +92.63 MB/sec + + + +根据这些信息，就可以计算出观测周期内的提升速率：平均提升速率为 92MB/秒，峰值为 140.95MB/秒。 + +请注意，只能根据 Minor GC 计算提升速率。Full GC 的日志不能用于计算提升速率，因为 Major GC 会清理掉老年代中的一部分对象。 + +提升速率的意义 + +和分配速率一样，提升速率也会影响 GC 暂停的频率。但分配速率主要影响 minor GC，而提升速率则影响 major GC 的频率。有大量的对象提升，自然很快将老年代填满。老年代填充的越快，则 Major GC 事件的频率就会越高。 + + + +前面章节提到过，Full GC 通常需要更多的时间，因为需要处理更多的对象，还要执行碎片整理等额外的复杂过程。 + +示例 + +让我们看一个过早提升的示例。这个程序创建/获取大量的对象/数据，并暂存到集合之中，达到一定数量后进行批处理： + + public class PrematurePromotion { + + private static final Collection accumulatedChunks + = new ArrayList<>(); + + private static void onNewChunk(byte[] bytes) { + accumulatedChunks.add(bytes); + + if(accumulatedChunks.size() > MAX_CHUNKS) { + processBatch(accumulatedChunks); + accumulatedChunks.clear(); + } + } + } + + + +此 Demo 程序 受到过早提升的影响。下面将进行验证并给出解决办法。 + +过早提升的影响 + +一般来说过早提升的症状表现为以下形式： + + +短时间内频繁地执行 Full GC +每次 Full GC 后老年代的使用率都很低，在 10~20% 或以下 +提升速率接近于分配速率 + + +要演示这种情况稍微有点麻烦，所以我们使用特殊手段，让对象提升到老年代的年龄比默认情况小很多。指定 GC 参数 -Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1，运行程序之后，可以看到下面的 GC 日志： + + 2.176: [Full GC (Ergonomics) + [PSYoungGen: 9216K->0K(10752K)] + [ParOldGen: 10020K->9042K(12288K)] + 19236K->9042K(23040K), 0.0036840 secs] + 2.394: [Full GC (Ergonomics) + [PSYoungGen: 9216K->0K(10752K)] + [ParOldGen: 9042K->8064K(12288K)] + 18258K->8064K(23040K), 0.0032855 secs] + 2.611: [Full GC (Ergonomics) + [PSYoungGen: 9216K->0K(10752K)] + [ParOldGen: 8064K->7085K(12288K)] + 17280K->7085K(23040K), 0.0031675 secs] + 2.817: [Full GC (Ergonomics) + [PSYoungGen: 9216K->0K(10752K)] + [ParOldGen: 7085K->6107K(12288K)] + 16301K->6107K(23040K), 0.0030652 secs] + + + +乍一看似乎不是过早提升的问题，每次 GC 之后老年代的使用率似乎在减少。但反过来想，要是没有对象提升或者提升率很小，也就不会看到这么多的 Full GC 了。 + +简单解释一下这里的 GC 行为：有很多对象提升到老年代，同时老年代中也有很多对象被回收了，这就造成了老年代使用量减少的假象。但事实是大量的对象不断地被提升到老年代，并触发 Full GC。 + +解决方案 + +简单来说，要解决这类问题，需要让年轻代存放得下暂存的数据。有两种简单的方法： + +一是增加年轻代的大小，设置 JVM 启动参数，类似这样：-Xmx64m -XX:NewSize=32m，程序在执行时，Full GC 的次数自然会减少很多，只会对 Minor GC 的持续时间产生影响： + + 2.251: [GC (Allocation Failure) + [PSYoungGen: 28672K->3872K(28672K)] + 37126K->12358K(61440K), 0.0008543 secs] + 2.776: [GC (Allocation Failure) + [PSYoungGen: 28448K->4096K(28672K)] + 36934K->16974K(61440K), 0.0033022 secs] + + + +二是减少每次批处理的数量，也能得到类似的结果。 + +至于选用哪个方案，要根据业务需求决定。 + +在某些情况下，业务逻辑不允许减少批处理的数量，那就只能增加堆内存，或者重新指定年轻代的大小。 + +如果都不可行，就只能优化数据结构，减少内存消耗。但总体目标依然是一致的——让临时数据能够在年轻代存放得下。 + + + + \ No newline at end of file diff --git a/专栏/JVM核心技术32讲（完）/30GC疑难情况问题排查与分析（下篇）.md b/专栏/JVM核心技术32讲（完）/30GC疑难情况问题排查与分析（下篇）.md new file mode 100644 index 0000000..66153b0 --- /dev/null +++ b/专栏/JVM核心技术32讲（完）/30GC疑难情况问题排查与分析（下篇）.md @@ -0,0 +1,299 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 30 GC 疑难情况问题排查与分析（下篇） + Weak、Soft 及 Phantom 引用 + +另一类影响 GC 的问题是程序中的 non-strong 引用。虽然这类引用在很多情况下可以避免出现 OutOfMemoryError，但过量使用也会对 GC 造成严重的影响，反而降低系统性能。 + +弱引用的缺点 + +首先，弱引用（weak reference）是可以被 GC 强制回收的。当垃圾收集器发现一个弱可达对象（weakly reachable，即指向该对象的引用只剩下弱引用）时，就会将其置入相应的 ReferenceQueue 中，变成可终结的对象。之后可能会遍历这个 reference queue，并执行相应的清理。典型的示例是清除缓存中不再引用的 KEY。 + +当然，在这个时候我们还可以将该对象赋值给新的强引用，在最后终结和回收前，GC 会再次确认该对象是否可以安全回收。因此，弱引用对象的回收过程是横跨多个 GC 周期的。 + +实际上弱引用使用的很多。大部分缓存框架都是基于弱引用实现的，所以虽然业务代码中没有直接使用弱引用，但程序中依然会大量存在。 + +其次，软引用（soft reference）比弱引用更难被垃圾收集器回收。回收软引用没有确切的时间点，由 JVM 自己决定。一般只会在即将耗尽可用内存时，才会回收软引用，以作最后手段。这意味着可能会有更频繁的 Full GC，暂停时间也比预期更长，因为老年代中的存活对象会很多。 + +最后，使用虚引用（phantom reference）时，必须手动进行内存管理，以标识这些对象是否可以安全地回收。表面上看起来很正常，但实际上并不是这样。javadoc 中写道： + + +In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The get method of a phantom reference always returns null. + +为了防止可回收对象的残留，虚引用对象不应该被获取：phantom reference 的 get 方法返回值永远是 null。 + + +令人惊讶的是，很多开发者忽略了下一段内容（这才是重点）： + + +Unlike soft and weak references，phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable. + +与软引用和弱引用不同，虚引用不会被 GC 自动清除，因为他们被存放到队列中。通过虚引用可达的对象会继续留在内存中，直到调用此引用的 clear 方法，或者引用自身变为不可达。 + + +也就是说，我们必须手动调用 clear() 来清除虚引用，否则可能会造成 OutOfMemoryError 而导致 JVM 挂掉。使用虚引用的理由是，对于用编程手段来跟踪某个对象何时变为不可达对象，这是唯一的常规手段。和软引用/弱引用不同的是，我们不能“复活”虚可达（phantom-reachable）对象。 + +示例 + +让我们看一个弱引用示例，其中创建了大量的对象，并在 Minor GC 中完成回收。和前面一样，修改提升阀值。可以使用下列 JVM 参数： + +-Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1 + + + +此时 GC 日志如下所示： + + 2.330: [GC (Allocation Failure) 20933K->8229K(22528K), 0.0033848 secs] + 2.335: [GC (Allocation Failure) 20517K->7813K(22528K), 0.0022426 secs] + 2.339: [GC (Allocation Failure) 20101K->7429K(22528K), 0.0010920 secs] + 2.341: [GC (Allocation Failure) 19717K->9157K(22528K), 0.0056285 secs] + 2.348: [GC (Allocation Failure) 21445K->8997K(22528K), 0.0041313 secs] + 2.354: [GC (Allocation Failure) 21285K->8581K(22528K), 0.0033737 secs] + 2.359: [GC (Allocation Failure) 20869K->8197K(22528K), 0.0023407 secs] + 2.362: [GC (Allocation Failure) 20485K->7845K(22528K), 0.0011553 secs] + 2.365: [GC (Allocation Failure) 20133K->9501K(22528K), 0.0060705 secs] + 2.371: [Full GC (Ergonomics) 9501K->2987K(22528K), 0.0171452 secs] + + + +可以看到，Full GC 的次数很少。但如果使用弱引用来指向创建的对象，使用 JVM 参数 -Dweak.refs=true，则情况会发生明显变化。使用弱引用的原因很多，比如在 weak hash map 中将对象作为 Key 的情况。在任何情况下，使用弱引用都可能会导致以下情形： + + 2.059: [Full GC (Ergonomics) 20365K->19611K(22528K), 0.0654090 secs] + 2.125: [Full GC (Ergonomics) 20365K->19711K(22528K), 0.0707499 secs] + 2.196: [Full GC (Ergonomics) 20365K->19798K(22528K), 0.0717052 secs] + 2.268: [Full GC (Ergonomics) 20365K->19873K(22528K), 0.0686290 secs] + 2.337: [Full GC (Ergonomics) 20365K->19939K(22528K), 0.0702009 secs] + 2.407: [Full GC (Ergonomics) 20365K->19995K(22528K), 0.0694095 secs] + + + +可以看到，发生了多次 Full GC，比起前一节的示例，GC 时间增加了一个数量级！ + +这是过早提升的另一个例子，但这次情况更加棘手：问题的根源在于弱引用。这些临死的对象，在添加弱引用之后，被提升到了老年代。但是，他们现在陷入另一次 GC 循环之中，所以需要对其做一些适当的清理。 + +像之前一样，最简单的办法是增加年轻代的大小，例如指定 JVM 参数 -Xmx64m -XX:NewSize=32m： + + 2.328: [GC (Allocation Failure) 38940K->13596K(61440K)，0.0012818 secs] + 2.332: [GC (Allocation Failure) 38172K->14812K(61440K)，0.0060333 secs] + 2.341: [GC (Allocation Failure) 39388K->13948K(61440K)，0.0029427 secs] + 2.347: [GC (Allocation Failure) 38524K->15228K(61440K)，0.0101199 secs] + 2.361: [GC (Allocation Failure) 39804K->14428K(61440K)，0.0040940 secs] + 2.368: [GC (Allocation Failure) 39004K->13532K(61440K)，0.0012451 secs] + + + +这时候，对象在 Minor GC 中就被回收了。 + +更坏的情况是使用软引用，例如这个软引用示例程序。如果程序不是即将发生 OutOfMemoryError，软引用对象就不会被回收。在示例程序中，用软引用替代弱引用，立即出现了更多的 Full GC 事件： + + 2.162: [Full GC (Ergonomics) 31561K->12865K(61440K)，0.0181392 secs] + 2.184: [GC (Allocation Failure) 37441K->17585K(61440K)，0.0024479 secs] + 2.189: [GC (Allocation Failure) 42161K->27033K(61440K)，0.0061485 secs] + 2.195: [Full GC (Ergonomics) 27033K->14385K(61440K)，0.0228773 secs] + 2.221: [GC (Allocation Failure) 38961K->20633K(61440K)，0.0030729 secs] + 2.227: [GC (Allocation Failure) 45209K->31609K(61440K)，0.0069772 secs] + 2.234: [Full GC (Ergonomics) 31609K->15905K(61440K)，0.0257689 secs] + + + +最有趣的是虚引用示例中的虚引用，使用同样的 JVM 参数启动，其结果和弱引用示例非常相似。实际上，Full GC 暂停的次数会小得多，原因前面说过，他们有不同的终结方式。 + +如果禁用虚引用清理，增加 JVM 启动参数（-Dno.ref.clearing=true），则可以看到： + + 4.180: [Full GC (Ergonomics) 57343K->57087K(61440K)，0.0879851 secs] + 4.269: [Full GC (Ergonomics) 57089K->57088K(61440K)，0.0973912 secs] + 4.366: [Full GC (Ergonomics) 57091K->57089K(61440K)，0.0948099 secs] + + + +主线程中很快抛出异常： + +java.lang.OutOfMemoryError: Java heap space + + + +使用虚引用时要小心谨慎，并及时清理虚可达对象。如果不清理，很可能会发生 OutOfMemoryError。 + +请相信我们的经验教训：处理 reference queue 的线程中如果没 catch 住异常，系统很快就会被整挂了。 + +使用非强引用的影响 + +建议使用 JVM 参数 -XX:+PrintReferenceGC 来看看各种引用对 GC 的影响。如果将此参数用于启动弱引用示例，将会看到： + + 2.173: [Full GC (Ergonomics) + 2.234: [SoftReference，0 refs，0.0000151 secs] + 2.234: [WeakReference，2648 refs，0.0001714 secs] + 2.234: [FinalReference，1 refs，0.0000037 secs] + 2.234: [PhantomReference，0 refs，0 refs，0.0000039 secs] + 2.234: [JNI Weak Reference，0.0000027 secs] + [PSYoungGen: 9216K->8676K(10752K)] + [ParOldGen: 12115K->12115K(12288K)] + 21331K->20792K(23040K), + [Metaspace: 3725K->3725K(1056768K)], + 0.0766685 secs] + [Times: user=0.49 sys=0.01，real=0.08 secs] + 2.250: [Full GC (Ergonomics) + 2.307: [SoftReference，0 refs，0.0000173 secs] + 2.307: [WeakReference，2298 refs，0.0001535 secs] + 2.307: [FinalReference，3 refs，0.0000043 secs] + 2.307: [PhantomReference，0 refs，0 refs，0.0000042 secs] + 2.307: [JNI Weak Reference，0.0000029 secs] + [PSYoungGen: 9215K->8747K(10752K)] + [ParOldGen: 12115K->12115K(12288K)] + 21331K->20863K(23040K), + [Metaspace: 3725K->3725K(1056768K)], + 0.0734832 secs] + [Times: user=0.52 sys=0.01，real=0.07 secs] + 2.323: [Full GC (Ergonomics) + 2.383: [SoftReference，0 refs，0.0000161 secs] + 2.383: [WeakReference，1981 refs，0.0001292 secs] + 2.383: [FinalReference，16 refs，0.0000049 secs] + 2.383: [PhantomReference，0 refs，0 refs，0.0000040 secs] + 2.383: [JNI Weak Reference，0.0000027 secs] + [PSYoungGen: 9216K->8809K(10752K)] + [ParOldGen: 12115K->12115K(12288K)] + 21331K->20925K(23040K), + [Metaspace: 3725K->3725K(1056768K)], + 0.0738414 secs] + [Times: user=0.52 sys=0.01，real=0.08 secs] + + + +只有确定 GC 对应用的吞吐量和延迟造成影响之后，才应该花心思来分析这些信息，审查这部分日志。通常情况下，每次 GC 清理的引用数量都是很少的，大部分情况下为 0。 + +如果 GC 花了较多时间来清理这类引用，或者清除了很多的此类引用，就需要进一步观察和分析了。 + +解决方案 + +如果程序确实碰到了 mis-、ab- 等问题或者滥用 weak/soft/phantom 引用，一般都要修改程序的实现逻辑。每个系统不一样，因此很难提供通用的指导建议，但有一些常用的经验办法： + + +弱引用（Weak references）：如果某个内存池的使用量增大，造成了性能问题，那么增加这个内存池的大小（可能也要增加堆内存的最大容量）。如同示例中所看到的，增加堆内存的大小，以及年轻代的大小，可以减轻症状。 +软引用（Soft references）：如果确定问题的根源是软引用，唯一的解决办法是修改程序源码，改变内部实现逻辑。 +虚引用（Phantom references）：请确保在程序中调用了虚引用的 clear 方法。编程中很容易忽略某些虚引用，或者清理的速度跟不上生产的速度，又或者清除引用队列的线程挂了，就会对 GC 造成很大压力，最终可能引起 OutOfMemoryError。 + + +其他性能问题的案例 + +前面介绍了最常见的 GC 性能问题，本节介绍一些不常见、但也可能会导致系统故障的问题。 + +RMI 与 GC + +如果系统提供或者消费 RMI 服务，则 JVM 会定期执行 Full GC 来确保本地未使用的对象在另一端也不占用空间。即使你的代码中没有发布 RMI 服务，但第三方或者工具库也可能会打开 RMI 终端。最常见的元凶是 JMX，如果通过 JMX 连接到远端，底层则会使用 RMI 发布数据。 + +问题是有很多不必要的周期性 Full GC。查看老年代的使用情况，一般是没有内存压力，其中还存在大量的空闲区域，但 Full GC 就是被触发了，也就会暂停所有的应用线程。 + +这种周期性调用 System.gc() 删除远程引用的行为，是在 sun.rmi.transport.ObjectTable 类中，通过 sun.misc.GC.requestLatency(long gcInterval) 调用的。 + +对许多应用来说，根本没必要，甚至对性能有害。禁止这种周期性的 GC 行为，可以使用以下 JVM 参数： + + java -Dsun.rmi.dgc.server.gcInterval=9223372036854775807L + -Dsun.rmi.dgc.client.gcInterval=9223372036854775807L + com.yourcompany.YourApplication + + + +这让 Long.MAX_VALUE 毫秒之后，才调用 System.gc()，实际运行的系统可能永远都不会触发。 + + // ObjectTable.class + private static final long gcInterval = + ((Long)AccessController.doPrivileged( + new GetLongAction("sun.rmi.dgc.server.gcInterval"，3600000L) + )).longValue(); + + + +可以看到，默认值为 3600000L，也就是 1 小时触发一次 Full GC。 + +另一种方式是指定 JVM 参数 -XX:+DisableExplicitGC，禁止显式地调用 System.gc()。但我们强烈反对这种方式，因为我们不清楚这么做是否埋有地雷，例如第三方库里需要显式调研。 + +JVMTI tagging 与 GC + +如果在程序启动时指定了 Java Agent（-javaagent），Agent 就可以使用 JVMTI tagging 标记堆中的对象。如果 tagging 标记了大量的对象，很可能会引起 GC 性能问题，导致延迟增加，以及吞吐量降低。 + +问题发生在 native 代码中，JvmtiTagMap::do_weak_oops 在每次 GC 时，都会遍历所有标标记（tag），并执行一些比较耗时的操作。更坑的是，这种操作是串行执行的。 + +如果存在大量的标记，就意味着 GC 时有很大一部分工作是单线程执行的，GC 暂停时间可能会增加一个数量级。 + +检查是否因为 Java Agent 增加了 GC 暂停时间，可以使用诊断参数 –XX:+TraceJVMTIObjectTagging。 + +启用跟踪之后，可以估算出内存中 的标记映射了多少 native 内存，以及遍历所消耗的时间。 + +如果你不是 需要使用的这个 agent 的作者，那一般是搞不定这类问题的。除了提 Bug 之外你什么都做不了。如果发生了这种情况，请建议厂商清理不必要的标记。（以前我们就在生产环境里发现 APM 厂商的 Agent 偶尔会导致 JVM OOM 崩溃。） + +巨无霸对象的分配（Humongous Allocations） + +如果使用 G1 垃圾收集算法，会产生一种巨无霸对象引起的 GC 性能问题。 + + +说明：在 G1 中，巨无霸对象是指所占空间超过一个小堆区（region）50% 的对象。 + + +频繁地创建巨无霸对象，无疑会造成 GC 的性能问题，看看 G1 的处理方式： + + +如果某个 region 中含有巨无霸对象，则巨无霸对象后面的空间将不会被分配。如果所有巨无霸对象都超过某个比例，则未使用的空间就会引发内存碎片问题。 +G1 没有对巨无霸对象进行优化。这在 JDK 8 以前是个特别棘手的问题——在 Java 1.8u40 之前的版本中，巨无霸对象所在 region 的回收只能在 Full GC 中进行。最新版本的 Hotspot JVM，在 marking 阶段之后的 cleanup 阶段中释放巨无霸区间，所以这个问题在新版本 JVM 中的影响已大大降低。 + + +要监控是否存在巨无霸对象，可以打开 GC 日志，使用的命令如下： + + java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps + -XX:+PrintReferenceGC -XX:+UseG1GC + -XX:+PrintAdaptiveSizePolicy -Xmx128m + MyClass + + + +GC 日志中可能会发现这样的部分： + + 0.106: [G1Ergonomics (Concurrent Cycles) + request concurrent cycle initiation, + reason: occupancy higher than threshold, + occupancy: 60817408 bytes, + allocation request: 1048592 bytes, + threshold: 60397965 bytes (45.00 %), + source: concurrent humongous allocation] + 0.106: [G1Ergonomics (Concurrent Cycles) + request concurrent cycle initiation, + reason: requested by GC cause, + GC cause: G1 Humongous Allocation] + 0.106: [G1Ergonomics (Concurrent Cycles) + initiate concurrent cycle, + reason: concurrent cycle initiation requested] + 0.106: [GC pause (G1 Humongous Allocation) + (young) (initial-mark) + 0.106: [G1Ergonomics (CSet Construction) + start choosing CSet, + _pending_cards: 0, + predicted base + time: 10.00 ms, + remaining time: 190.00 ms, + target pause time: 200.00 ms] + + + +这样的日志就是证据，表明程序中确实创建了巨无霸对象。可以看到 G1 Humongous Allocation 是 GC 暂停的原因。再看前面一点的 allocation request: 1048592 bytes，可以发现程序试图分配一个 1048592 字节的对象，这要比巨无霸区域（2MB）的 50% 多出 16 个字节。 + +第一种解决方式，是修改 region size，以使得大多数的对象不超过 50%，也就不进行巨无霸对象区域的分配。G1 的 region 大小默认值在启动时根据堆内存的大小算出。但也可以指定参数来覆盖默认设置，-XX:G1HeapRegionSize=XX。指定的 region size 必须在 1~32MB 之间，还必须是 2 的幂（2^10=1024=1KB，2^20=1MB，所以 region size 只能是下列值之一：1m、2m、4m、8m、16m、32m）。 + +这种方式也有副作用，增加 region 的大小也就变相地减少了 region 的数量，所以需要谨慎使用，最好进行一些测试，看看是否改善了吞吐量和延迟。 + +更好的使用方式是，在程序中限制对象的大小，我们可以在运行时使用内存分析工具，展示出巨无霸对象的信息，以及分配时所在的堆栈跟踪信息。 + +总结 + +Java 作为一个通用平台，运行在 JVM 上的应用程序多种多样，其启动参数也有上百个，其中有很多会影响到 GC 和性能，所以调优 GC 性能的方法也有很多种。 + +但是我们也要时刻提醒自己：没有真正的银弹，能满足所有的性能调优指标。 + +我们需要做的，就是了解这些可能会出现问题的各个要点，掌握常见的排查分析方法和工具。 + +在碰到类似问题时知道是知其然知其所以然，深入理解 JVM/GC 的工作原理，熟练应用各种手段，观察各种现象，收集各种有用的指标数据，进行定性和定量的分析，找到瓶颈，制定解决方案，进行调优和改进，提高应用系统的性能和稳定性。 + + + + \ No newline at end of file diff --git a/专栏/JVM核心技术32讲（完）/31JVM相关的常见面试问题汇总：运筹策帷帐之中，决胜于千里之外.md b/专栏/JVM核心技术32讲（完）/31JVM相关的常见面试问题汇总：运筹策帷帐之中，决胜于千里之外.md new file mode 100644 index 0000000..c7098b1 --- /dev/null +++ b/专栏/JVM核心技术32讲（完）/31JVM相关的常见面试问题汇总：运筹策帷帐之中，决胜于千里之外.md @@ -0,0 +1,461 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 31 JVM 相关的常见面试问题汇总：运筹策帷帐之中，决胜于千里之外 + 面试和笔试的要点其实差不多，基础知识和实战经验都是最重要的关注点（当然，面试时的态度和眼缘也很重要）。 + +实际面试时，因为时间有限，不可能所有问题都问一遍，一般是根据简历上涉及的内容，抽一部分话题来聊一聊。看看面试者的经验、态度，以及面对一层层深入问题时的处理思路。借此了解面试者的技术水平，对深度、广度，以及思考和解决问题的能力。 + +常见的面试套路是什么呢？ + + +XXX 是什么？ +实现原理是什么？ +为什么这样实现？ +如果让你实现你会怎么做？ +分析下你的实现有什么优缺点？ +有哪些需要改进的地方? + + +下面总结一些比较常见的面试题，供大家参考。针对这些问题，大家可以给自己打一个分。 + + +0 分：不清楚相关知识。 +30 分：有一点印象，知道一些名词。 +60 分：知道一些概念以及含义，了解功能和常见用途。 +80 分：能在参考答案的基础上进行补充。 +100 分：发现参考答案的问题。 + + +下面我们来看看 JVM 相关面试问题。 + +1. 什么是 JVM？ + +JVM 全称是 Java Virtual Machine，中文称为 Java 虚拟机。 + +JVM 是 Java 程序运行的底层平台，与 Java 支持库一起构成了 Java 程序的执行环境。 + +分为 JVM 规范和 JVM 实现两个部分。简单来说，Java 虚拟机就是指能执行标准 Java 字节码的虚拟计算机。 + +1.1 请问 JDK 与 JVM 有什么区别？ + +现在的 JDK、JRE 和 JVM 一般是整套出现的。 + + +JDK = JRE + 开发调试诊断工具 +JRE = JVM + Java 标准库 + + +1.2 你认识哪些 JVM 厂商？ + +常见的 JDK 厂商包括： + + +Oracle 公司，包括 Hotspot 虚拟机、GraalVM，分为 OpenJDK 和 OracleJDK 两种版本 +IBM 公司，J9 虚拟机，用在 IBM 的产品套件中 +Azul Systems 公司，高性能的 Zing 和开源的 Zulu +阿里巴巴，Dragonwell 是阿里开发的 OpenJDK 定制版 +亚马逊，Corretto OpenJDK +Red Hat 公司的 OpenJDK +Adopt OpenJDK +此外，还有一些开源和试验性质的 JVM 实现，比如 Go.JVM + + +1.3 OracleJDK 与 OpenJDK 有什么区别？ + +各种版本的 JDK 一般来说都会符合 Java 虚拟机规范。 两者的区别一般来说包括： + + +两种 JDK 提供的工具套件略有差别，比如 jmc 等有版权的工具。 +某些协议或配置不一样，比如美国限制出口的加密算法。 +其他细微差别，比如 JRE 中某些私有的 API 不一样。 + + +1.4 开发中使用哪个版本的 JDK？生产环境呢？为什么这么选？ + +有一说一，选择哪个版本需要考虑研发团队的具体情况：比如机器的操作系统、团队成员的掌握情况、兼顾遗留项目等等。 + +当前 Java 最受欢迎的长期维护版本是 Java 8 和 Java 11。 + + +Java 8 是经典 LTS 版本，性能优秀，系统稳定，良好支持各种 CPU 架构和操作系统平台。 +Java 11 是新的长期支持版，性能更强，支持更多新特性，而且经过几年的维护已经很稳定。 + + +有的企业在开发环境使用 OracleJDK，在生产环境使用 OpenJDK。也有的企业恰好相反，在开发环境使用 OpenJDK，在生产环境使用 OracleJDK。也有的公司使用同样的打包版本。开发和部署时只要进行过测试就没问题。一般来说，测试环境、预上线环境的 JDK 配置需要和生产环境一致。 + +2. 什么是 Java 字节码？ + +Java 中的字节码，是值 Java 源代码编译后的中间代码格式，一般称为字节码文件。 + +2.1 字节码文件中包含哪些内容？ + +字节码文件中，一般包含以下部分： + + +版本号信息 +静态常量池（符号常量） +类相关的信息 +字段相关的信息 +方法相关的信息 +调试相关的信息 + + +可以说，大部分信息都是通过常量池中的符号常量来表述的。 + +2.2 什么是常量？ + +常量是指不变的量，字母 ‘K’ 或者数字 1024 在 UTF-8 编码中对应到对应的二进制格式都是不变的。同样地，字符串在 Java 中的二进制表示也是不变的, 比如 “KK”。 + +在 Java 中需要注意的是，final 关键字修饰的字段和变量，表示最终变量，只能赋值 1 次，不允许再次修改，由编译器和执行引擎共同保证。 + +2.3 你怎么理解常量池？ + +在 Java 中，常量池包括两层含义： + + +静态常量池，class 文件中的一个部分，里面保存的是类相关的各种符号常量。 +运行时常量池，其内容主要由静态常量池解析得到，但也可以由程序添加。 + + +3. JVM 的运行时数据区有哪些？ + +根据 JVM 规范，标准的 JVM 运行时数据区包括以下部分： + + +程序计数器 +Java 虚拟机栈 +堆内存 +方法区 +运行时常量池 +本地方法栈 + + +具体的 JVM 实现可根据实际情况进行优化或者合并，满足规范的要求即可。 + +3.1 什么是堆内存？ + +堆内存是指由程序代码自由分配的内存，与栈内存作区分。 + +在 Java 中，堆内存主要用于分配对象的存储空间，只要拿到对象引用，所有线程都可以访问堆内存。 + +3.2 堆内存包括哪些部分？ + +以 Hotspot 为例，堆内存（HEAP）主要由 GC 模块进行分配和管理，可分为以下部分： + + +新生代 +存活区 +老年代 + + +其中，新生代和存活区一般称为年轻代。 + +3.3 什么是非堆内存？ + +除堆内存之外，JVM 的内存池还包括非堆（NON_HEAP），对应于 JVM 规范中的方法区，常量池等部分： + + +MetaSpace +CodeCache +Compressed Class Space + + +4. 什么是内存溢出？ + +内存溢出（OOM）是指可用内存不足。 + +程序运行需要使用的内存超出最大可用值，如果不进行处理就会影响到其他进程，所以现在操作系统的处理办法是：只要超出立即报错，比如抛出“内存溢出错误”。 + +就像杯子装不下，满了要溢出来一样，比如一个杯子只有 500ml 的容量，却倒进去 600ml，于是水就溢出造成破坏。 + +4.1 什么是内存泄漏？ + +内存泄漏（Memory Leak）是指本来无用的对象却继续占用内存，没有再恰当的时机释放占用的内存。 + +不使用的内存，却没有被释放，称为“内存泄漏”。也就是该释放的没释放，该回收的没回收。 + +比较典型的场景是：每一个请求进来，或者每一次操作处理，都分配了内存，却有一部分不能回收（或未释放），那么随着处理的请求越来越多，内存泄漏也就越来越严重。 + +在 Java 中一般是指无用的对象却因为错误的引用关系，不能被 GC 回收清理。 + +4.2 两者有什么关系？ + +如果存在严重的内存泄漏问题，随着时间的推移，则必然会引起内存溢出。 + +内存泄漏一般是资源管理问题和程序 Bug，内存溢出则是内存空间不足和内存泄漏的最终结果。 + +5. 给定一个具体的类，请分析对象的内存占用 + +public class MyOrder{ + private long orderId; + private long userId; + private byte state; + private long createMillis; +} + + + +一般来说，MyOrder 类的每个对象会占用 40 个字节。 + +5.1 怎么计算出来的？ + +计算方式为： + + +对象头占用 12 字节。 +每个 long 类型的字段占用 8 字节，3 个 long 字段占用 24 字节。 +byte 字段占用 1 个字节。 +以上合计 37 字节，加上以 8 字节对齐，则实际占用 40 个字节。 + + +5.2 对象头中包含哪些部分？ + +对象头中一般包含两个部分： + + +标记字，占用一个机器字，也就是 8 字节。 +类型指针，占用一个机器字，也就是 8 个字节。 +如果堆内存小于 32GB，JVM 默认会开启指针压缩，则只占用 4 个字节。 + + +所以前面的计算中，对象头占用 12 字节。如果是数组，对象头中还会多出一个部分： + + +数组长度，int 值，占用 4 字节。 + + +6. 常用的 JVM 启动参数有哪些？ + +截止目前（2020 年 3 月），JVM 可配置参数已经达到 1000 多个，其中 GC 和内存配置相关的 JVM 参数就有 600 多个。但在绝大部分业务场景下，常用的 JVM 配置参数也就 10 来个。 + +例如： + +# JVM 启动参数不换行 +# 设置堆内存 +-Xmx4g -Xms4g +# 指定 GC 算法 +-XX:+UseG1GC -XX:MaxGCPauseMillis=50 +# 指定 GC 并行线程数 +-XX:ParallelGCThreads=4 +# 打印 GC 日志 +-XX:+PrintGCDetails -XX:+PrintGCDateStamps +# 指定 GC 日志文件 +-Xloggc:gc.log +# 指定 Meta 区的最大值 +-XX:MaxMetaspaceSize=2g +# 设置单个线程栈的大小 +-Xss1m +# 指定堆内存溢出时自动进行 Dump +-XX:+HeapDumpOnOutOfMemoryError +-XX:HeapDumpPath=/usr/local/ + + + +此外，还有一些常用的属性配置： + +# 指定默认的连接超时时间 +-Dsun.net.client.defaultConnectTimeout=2000 +-Dsun.net.client.defaultReadTimeout=2000 +# 指定时区 +-Duser.timezone=GMT+08 +# 设置默认的文件编码为 UTF-8 +-Dfile.encoding=UTF-8 +# 指定随机数熵源(Entropy Source) +-Djava.security.egd=file:/dev/./urandom + + + +6.1 设置堆内存 XMX 应该考虑哪些因素？ + +需要根据系统的配置来确定，要给操作系统和 JVM 本身留下一定的剩余空间。推荐配置系统或容器里可用内存的 70~80% 最好。 + +6.2 假设物理内存是 8G，设置多大堆内存比较合适？ + +比如说系统有 8G 物理内存，系统自己可能会用掉一点，大概还有 7.5G 可以用，那么建议配置 -Xmx6g。 + +说明：7.5G*0.8=6G，如果知道系统里有明确使用堆外内存的地方，还需要进一步降低这个值。 + +6.3 -Xmx 设置的值与 JVM 进程所占用的内存有什么关系？ + +JVM 总内存 = 栈 + 堆 + 非堆 + 堆外 + Native + +6.4 怎样开启 GC 日志？ + +一般来说，JDK 8 及以下版本通过以下参数来开启 GC 日志： + +-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log + + + +如果是在 JDK 9 及以上的版本，则格式略有不同： + +-Xlog:gc*=info:file=gc.log:time:filecount=0 + + + +6.5 请指定使用 G1 垃圾收集器来启动 Hello 程序 + +java -XX:+UseG1GC +-Xms4g +-Xmx4g +-Xloggc:gc.log +-XX:+PrintGCDetails +-XX:+PrintGCDateStamps +Hello + + + +7. Java 8 默认使用的垃圾收集器是什么？ + +Java 8 版本的 Hotspot JVM，默认情况下使用的是并行垃圾收集器（Parallel GC）。其他厂商提供的 JDK 8 基本上也默认使用并行垃圾收集器。 + +7.1 Java11 的默认垃圾收集器是什么？ + +Java 9 之后，官方 JDK 默认使用的垃圾收集器是 G1。 + +7.2 常见的垃圾收集器有哪些？ + +常见的垃圾收集器包括： + + +串行垃圾收集器：-XX:+UseSerialGC +并行垃圾收集器：-XX:+UseParallelGC +CMS 垃圾收集器：-XX:+UseConcMarkSweepGC +G1 垃圾收集器：-XX:+UseG1GC + + +7.3 什么是串行垃圾收集？ + +就是只有单个 worker 线程来执行 GC 工作。 + +7.4 什么是并行垃圾收集？ + +并行垃圾收集，是指使用多个 GC worker 线程并行地执行垃圾收集，能充分利用多核 CPU 的能力，缩短垃圾收集的暂停时间。 + +除了单线程的 GC，其他的垃圾收集器，比如 PS、CMS、G1 等新的垃圾收集器都使用了多个线程来并行执行 GC 工作。 + +7.5 什么是并发垃圾收集器？ + +并发垃圾收集器，是指在应用程序在正常执行时，有一部分 GC 任务，由 GC 线程在应用线程一起并发执行。 例如 CMS/G1 的各种并发阶段。 + +7.6 什么是增量式垃圾收集？ + +首先，G1 的堆内存不再单纯划分为年轻代和老年代，而是划分为多个（通常是 2048 个）可以存放对象的小块堆区域（smaller heap regions）。 + +每个小块，可能一会被定义成 Eden 区，一会被指定为 Survivor 区或者 Old 区。 + +这样划分之后，使得 G1 不必每次都去回收整个堆空间，而是以增量的方式来进行处理：每次只处理一部分内存块，称为此次 GC 的回收集（collection set）。 + +下一次 GC 时在本次的基础上，再选定一定的区域来进行回收。增量式垃圾收集的好处是大大降低了单次 GC 暂停的时间。 + +7.7 什么是年轻代？ + +年轻代是分来垃圾收集算法中的一个概念，相对于老年代而言，年轻代一般包括： + + +新生代，Eden 区。 +存活区，执行年轻代 GC 时，用存活区来保存活下来的对象。存活区也是年轻代的一部分，但一般有 2 个存活区，所以可以来回倒腾。 + + +7.8 什么是 GC 停顿（GC pause）？ + +因为 GC 过程中，有一部分操作需要等所有应用线程都到达安全点，暂停之后才能执行，这时候就叫做 GC 停顿，或者叫做 GC 暂停。 + +7.9 GC 停顿与 STW 停顿有什么区别？ + +这两者一般可以认为就是同一个意思。 + +8. 如果 CPU 使用率突然飙升，你会怎么排查？ + +缺乏经验的话，针对当前问题，往往需要使用不同的工具来收集信息，例如： + + +收集不同的指标（CPU、内存、磁盘 IO、网络等等） +分析应用日志 +分析 GC 日志 +获取线程转储并分析 +获取堆转储来进行分析 + + +8.1 如果系统响应变慢，你会怎么排查？ + +一般根据 APM 监控来排查应用系统本身的问题，有时候也可以使用 Chrome 浏览器等工具来排查外部原因，比如网络问题。 + +8.2 系统性能一般怎么衡量？ + +可量化的 3 个性能指标： + + +系统容量：比如硬件配置，设计容量； +吞吐量：最直观的指标是 TPS； +响应时间：也就是系统延迟，包括服务端延时和网络延迟。 + + +这些指标。可以具体拓展到单机并发、总体并发、数据量、用户数、预算成本等等。 + +9. 使用过哪些 JVM 相关的工具？ + +这个问题请根据实际情况回答，比如 Linux 命令，或者 JDK 提供的工具等。 + +9.1 查看 JVM 进程号的命令是什么？ + +可以使用 ps -ef 和 jps -v 等等。 + +9.2 怎么查看剩余内存？ + +比如：free -m、free -h、top 命令等等。 + +9.3 查看线程栈的工具是什么？ + +一般先使用 jps 命令，再使用 jstack -l。 + +9.4 用什么工具来获取堆内存转储？ + +一般使用 jmap 工具来获取堆内存快照。 + +9.5 内存 Dump 时有哪些注意事项？ + +根据实际情况来看，获取内存快照可能会让系统暂停或阻塞一段时间，根据内存量决定。 + +使用 jmap 时，如果指定 live 参数，则会触发一次 Full GC，需要注意。 + +9.6 使用 JMAP 转储堆内存大致的参数怎么处理？ + +示例： + +jmap -dump:format=b,file=3826.hprof 3826 + + + +9.7 为什么转储文件以 .hprof 结尾？ + +JVM 有一个内置的分析器叫做 HPROF，堆内存转储文件的格式，最早就是这款工具定义的。 + +9.8 内存 Dump 完成之后，用什么工具来分析？ + +一般使用 Eclipse MAT 工具，或者 jhat 工具来处理。 + +9.9 如果忘记了使用什么参数你一般怎么处理？ + +上网搜索是比较笨的办法，但也是一种办法。 + +另外就是，各种 JDK 工具都支持 -h 选项来查看帮助信息，只要用得比较熟练，即使忘记了也很容易根据提示进行操作。 + +10. 开发性问题：你碰到过哪些 JVM 问题？ + +比如 GC 问题、内存泄漏问题、或者其他疑难杂症等等。然后可能还有一些后续的问题。例如： + + +你遇到过的印象最深的 JVM 问题是什么？ +这个问题是怎么分析和解决的？ +这个过程中有哪些值得分享的经验? + + +此问题为开放性问题，请根据自身情况进行回答，可以把自己思考的答案发到本专栏的微信群里，我们会逐个进行分析点评。 + + + + \ No newline at end of file diff --git a/专栏/JVM核心技术32讲（完）/32应对容器时代面临的挑战：长风破浪会有时、直挂云帆济沧海.md b/专栏/JVM核心技术32讲（完）/32应对容器时代面临的挑战：长风破浪会有时、直挂云帆济沧海.md new file mode 100644 index 0000000..bd16bdf --- /dev/null +++ b/专栏/JVM核心技术32讲（完）/32应对容器时代面临的挑战：长风破浪会有时、直挂云帆济沧海.md @@ -0,0 +1,464 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 32 应对容器时代面临的挑战：长风破浪会有时、直挂云帆济沧海 + 当今的时代，容器的使用越来越普及，Cgroups、Docker、Kubernetes 等项目和技术越来越成熟，成为很多大规模集群的基石。 + +容器是一种沙盒技术，可以对资源进行调度分配和限制配额、对不同应用进行环境隔离。 + +容器时代不仅给我们带来的机遇，也带来了很多挑战。跨得过去就是机会，跳不过去就是坑。 + +在容器环境下，要直接进行调试并不容易，我们更多地是进行应用性能指标的采集和监控，并构建预警机制。而这需要架构师、开发、测试、运维人员的协作。 + +但监控领域的工具又多又杂，而且在持续发展和不断迭代。最早期的监控，只在系统发布时检查服务器相关的参数，并将这些参数用作系统运行状况的指标。监控服务器的健康状况，与用户体验之间紧密相关，悲剧在于监控的不完善，导致发生的问题比实际检测到的要多很多。 + +随着时间推移，日志管理、预警、遥测以及系统报告领域持续发力。其中有很多有效的措施，诸如安全事件、有效警报、记录资源使用量等等。但前提是我们需要有一个清晰的策略和对应工具，进行用户访问链路跟踪，比如 Zabbix、Nagios 以及 Prometheus 等工具在生产环境中被广泛使用。 + +性能问题的关键是人，也就是我们的用户。但已有的这些工具并没有实现真正的用户体验监控。仅仅使用这些软件也不能缓解性能问题，我们还需要采取各种措施，在勇敢和专注下不懈地努力。 + +一方面，Web 系统的问题诊断和性能调优，是一件意义重大的事情。需要严格把控，也需要付出很多精力。 + +当然，成功实施这些工作对企业的回报也是巨大的！ + +另一方面，拿 Java 领域事实上的标准 Spring 来说，SpringBoot 提供了一款应用指标收集器——Micrometer，官方文档连接：https://micrometer.io/docs。 + + +支持直接将数据上报给 Elasticsearch、Datadog、InfluxData 等各种流行的监控系统。 +自动采集最大延迟、平均延迟、95% 线、吞吐量、内存使用量等指标。 + + +此外，在小规模集群中，我们还可以使用 Pinpoint、Skywalking 等开源 APM 工具。 + +容器环境的资源隔离性 + +容器毕竟是一种轻量级的实现方式，所以其封闭性不如虚拟机技术。 + +举个例子： + + +物理机/宿主机有 96 个 CPU 内核、256GB 物理内存，容器限制的资源是 4 核 8G，那么容器内部的 JVM 进程看到的内核数和内存数是多少呢？ + +目前来说，JVM 看到的内核数是 96，内存值是 256G。 + + +这会造成一些问题，基于 CPU 内核数 availableProcessors 的各种算法都会受到影响，比如默认 GC 线程数：假如啥都不配置，JVM 看见 96 个内核，设置 GC 并行线程数为 96*5/8~=60，但容器限制了只能使用 4 个内核资源，于是 60 个并行 GC 线程来争抢 4 个机器内核，造成严重的 GC 性能问题。 + +同样的道理，很多线程池的实现，根据内核数量来设置并发线程数，也会造成剧烈的资源争抢。如果容器不限制资源的使用也会造成一些困扰，比如下面介绍的坏邻居效应。基于物理内存 totalPhysicalMemorySize 和空闲内存 freePhysicalMemorySize 等配置信息的算法也会产生一些奇怪的 Bug。 + +最新版的 JDK 加入了一些修正手段。 + +JDK 对容器的支持和限制 + +新版 JDK 支持 Docker 容器的 CPU 和内存限制： + + +https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits + + +可以增加 JVM 启动参数来读取 Cgroups 对 CPU 的限制： + + +https://www.oracle.com/technetwork/java/javase/8u191-relnotes-5032181.html#JDK-8146115 + + +Hotspot 是一个规范的开源项目，关于 JDK 的新特性，可以阅读官方的邮件订阅，例如： + + +https://mail.openjdk.java.net/pipermail/jdk8u-dev/ + + +其他版本的 JDK 特性，也可以按照类似的命名规范，从官网的 Mailing Lists 中找到： + + +https://mail.openjdk.java.net/mailman/listinfo + + +关于这个问题的排查和分析，请参考前面的章节[《JVM 问题排查分析调优经验》]。 + +坏邻居效应 + +有共享资源的地方，就会有资源争用。在计算机领域，共享的资源主要包括： + + +网络 +磁盘 +CPU +内存 + + +在多租户的公有云环境中，会存在一种严重的问题，称为“坏邻居效应”（noisy neighbor phenomenon）。当一个或多个客户过度使用了某种公共资源时，就会明显损害到其他客户的系统性能。（就像是小区宽带一样） + +吵闹的坏邻居（noisy neighbor），用于描述云计算领域中，用来描述抢占共有带宽，磁盘 I/O、CPU 以及其他资源的行为。 + +坏邻居效应，对同一环境下的其他虚拟机/应用的性能会造成影响或抖动。一般来说，会对其他用户的性能和体验造成恶劣的影响。 + +云，是一种多租户环境，同一台物理机，会共享给多个客户来运行程序/存储数据。 + +坏邻居效应产生的原因，是某个虚拟机/应用霸占了大部分资源，进而影响到其他客户的性能。 + +带宽不足是造成网络性能问题的主要原因。在网络中传输数据严重依赖带宽的大小，如果某个应用或实例占用太多的网络资源，很可能对其他用户造成延迟/缓慢。坏邻居会影响虚拟机、数据库、网络、存储以及其他云服务。 + +有一种避免坏邻居效应的方法，是使用裸机云（bare-metal cloud）。裸机云在硬件上直接运行一个应用，相当于创建了一个单租户环境，所以能消除坏邻居。虽然单租户环境避免了坏邻居效应，但并没有解决根本问题。超卖（over-commitment）或者共享给太多的租户，都会限制整个云环境的性能。 + +另一种避免坏邻居效应的方法，是通过在物理机之间进行动态迁移，以保障每个客户获得必要的资源。此外，还可以通过 存储服务质量保障（QoS，quality of service）控制每个虚拟机的 IOPS，来限制坏邻居效应。通过 IOPS 来限制每个虚拟机使用的资源量，就不会造成某个客户的虚机/应用/实例去挤占其他客户的资源/性能。 + +有兴趣的同学可以查看： + + +谈谈公有云的坏邻居效应 + + +GC 日志监听 + +从 JDK 7 开始，每一款垃圾收集器都提供了通知机制，在程序中监听 GarbageCollectorMXBean，即可在垃圾收集完成后收到 GC 事件的详细信息。目前的监听机制只能得到 GC 完成之后的 Pause 数据，其它环节的 GC 情况无法观察到。 + +一个简单的监听程序实现如下： + +import com.alibaba.fastjson.JSON; +import com.alibaba.fastjson.JSONObject; +import com.sun.management.GarbageCollectionNotificationInfo; +import com.sun.management.GcInfo; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; +import org.springframework.context.annotation.Configuration; + +import javax.annotation.PostConstruct; +import javax.annotation.PreDestroy; +import javax.management.ListenerNotFoundException; +import javax.management.Notification; +import javax.management.NotificationEmitter; +import javax.management.NotificationListener; +import javax.management.openmbean.CompositeData; +import java.lang.management.*; +import java.util.*; +import java.util.concurrent.CopyOnWriteArrayList; +import java.util.concurrent.atomic.AtomicBoolean; +import java.util.concurrent.atomic.AtomicLong; + +/** + * GC 日志监听并输出到 Log + * JVM 启动参数示例: + * -Xmx4g -Xms4g -XX:+UseG1GC -XX:MaxGCPauseMillis=50 + * -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps + */ +@Configuration +public class BindGCNotifyConfig { + + public BindGCNotifyConfig() { + } + + // + private Logger logger = LoggerFactory.getLogger(this.getClass()); + private final AtomicBoolean inited = new AtomicBoolean(Boolean.FALSE); + private final List notifyCleanTasks = new CopyOnWriteArrayList(); + private final AtomicLong maxPauseMillis = new AtomicLong(0L); + private final AtomicLong maxOldSize = new AtomicLong(getOldGen().getUsage().getMax()); + private final AtomicLong youngGenSizeAfter = new AtomicLong(0L); + + @PostConstruct + public void init() { + try { + doInit(); + } catch (Throwable e) { + logger.warn("[GC 日志监听-初始化]失败! ", e); + } + } + + @PreDestroy + public void close() { + for (Runnable task : notifyCleanTasks) { + task.run(); + } + notifyCleanTasks.clear(); + } + + private void doInit() { + // + if (!inited.compareAndSet(Boolean.FALSE, Boolean.TRUE)) { + return; + } + logger.info("[GC 日志监听-初始化]maxOldSize=" + mb(maxOldSize.longValue())); + + // 每个 mbean 都注册监听 + for (GarbageCollectorMXBean mbean : ManagementFactory.getGarbageCollectorMXBeans()) { + if (!(mbean instanceof NotificationEmitter)) { + continue; + } + final NotificationEmitter notificationEmitter = (NotificationEmitter) mbean; + // 添加监听 + final NotificationListener notificationListener = getNewListener(mbean); + notificationEmitter.addNotificationListener(notificationListener, null, null); + + logger.info("[GC 日志监听-初始化]MemoryPoolNames=" + JSON.toJSONString(mbean.getMemoryPoolNames())); + // 加入清理队列 + notifyCleanTasks.add(new Runnable() { + @Override + public void run() { + try { + // 清理掉绑定的 listener + notificationEmitter.removeNotificationListener(notificationListener); + } catch (ListenerNotFoundException e) { + logger.error("[GC 日志监听-清理]清理绑定的 listener 失败", e); + } + } + }); + } + } + + private NotificationListener getNewListener(final GarbageCollectorMXBean mbean) { + // + final NotificationListener listener = new NotificationListener() { + @Override + public void handleNotification(Notification notification, Object ref) { + // 只处理 GC 事件 + if (!notification.getType().equals(GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION)) { + return; + } + CompositeData cd = (CompositeData) notification.getUserData(); + GarbageCollectionNotificationInfo notificationInfo = GarbageCollectionNotificationInfo.from(cd); + // + JSONObject gcDetail = new JSONObject(); + + String gcName = notificationInfo.getGcName(); + String gcAction = notificationInfo.getGcAction(); + String gcCause = notificationInfo.getGcCause(); + GcInfo gcInfo = notificationInfo.getGcInfo(); + // duration 是指 Pause 阶段的总停顿时间，并发阶段没有 pause 不会通知。 + long duration = gcInfo.getDuration(); + if (maxPauseMillis.longValue() < duration) { + maxPauseMillis.set(duration); + } + long gcId = gcInfo.getId(); + // + String type = "jvm.gc.pause"; + // + if (isConcurrentPhase(gcCause)) { + type = "jvm.gc.concurrent.phase.time"; + } + // + gcDetail.put("gcName", gcName); + gcDetail.put("gcAction", gcAction); + gcDetail.put("gcCause", gcCause); + gcDetail.put("gcId", gcId); + gcDetail.put("duration", duration); + gcDetail.put("maxPauseMillis", maxPauseMillis); + gcDetail.put("type", type); + gcDetail.put("collectionCount", mbean.getCollectionCount()); + gcDetail.put("collectionTime", mbean.getCollectionTime()); + + // 存活数据量 + AtomicLong liveDataSize = new AtomicLong(0L); + // 提升数据量 + AtomicLong promotedBytes = new AtomicLong(0L); + + // Update promotion and allocation counters + final Map before = gcInfo.getMemoryUsageBeforeGc(); + final Map after = gcInfo.getMemoryUsageAfterGc(); + // + Set keySet = new HashSet(); + keySet.addAll(before.keySet()); + keySet.addAll(after.keySet()); + // + final Map afterUsage = new HashMap(); + // + for (String key : keySet) { + final long usedBefore = before.get(key).getUsed(); + final long usedAfter = after.get(key).getUsed(); + long delta = usedAfter - usedBefore; + // 判断是 yong 还是 old，算法不同 + if (isYoungGenPool(key)) { + delta = usedBefore - youngGenSizeAfter.get(); + youngGenSizeAfter.set(usedAfter); + } else if (isOldGenPool(key)) { + if (delta > 0L) { + // 提升到老年代的量 + promotedBytes.addAndGet(delta); + gcDetail.put("promotedBytes", mb(promotedBytes)); + } + if (delta < 0L || GcGenerationAge.OLD.contains(gcName)) { + liveDataSize.set(usedAfter); + gcDetail.put("liveDataSize", mb(liveDataSize)); + final long oldMaxAfter = after.get(key).getMax(); + if (maxOldSize.longValue() != oldMaxAfter) { + maxOldSize.set(oldMaxAfter); + // 扩容；老年代的 max 有变更 + gcDetail.put("maxOldSize", mb(maxOldSize)); + } + } + } else if (delta > 0L) { + // + } else if (delta < 0L) { + // 判断 G1 + } + afterUsage.put(key, mb(usedAfter)); + } + // + gcDetail.put("afterUsage", afterUsage); + // + + logger.info("[GC 日志监听-GC 事件]gcId={}; duration:{}; gcDetail: {}", gcId, duration, gcDetail.toJSONString()); + } + }; + + return listener; + } + + private static String mb(Number num) { + long mbValue = num.longValue() / (1024 * 1024); + if (mbValue < 1) { + return "" + mbValue; + } + return mbValue + "MB"; + } + + private static MemoryPoolMXBean getOldGen() { + List list = ManagementFactory + .getPlatformMXBeans(MemoryPoolMXBean.class); + // + for (MemoryPoolMXBean memoryPoolMXBean : list) { + // 非堆的部分-不是老年代 + if (!isHeap(memoryPoolMXBean)) { + continue; + } + if (!isOldGenPool(memoryPoolMXBean.getName())) { + continue; + } + return (memoryPoolMXBean); + } + return null; + } + + private static boolean isConcurrentPhase(String cause) { + return "No GC".equals(cause); + } + + private static boolean isYoungGenPool(String name) { + return name.endsWith("Eden Space"); + } + + private static boolean isOldGenPool(String name) { + return name.endsWith("Old Gen") || name.endsWith("Tenured Gen"); + } + + private static boolean isHeap(MemoryPoolMXBean memoryPoolBean) { + return MemoryType.HEAP.equals(memoryPoolBean.getType()); + } + + private enum GcGenerationAge { + OLD, + YOUNG, + UNKNOWN; + + private static Map knownCollectors = new HashMap() {{ + put("ConcurrentMarkSweep", OLD); + put("Copy", YOUNG); + put("G1 Old Generation", OLD); + put("G1 Young Generation", YOUNG); + put("MarkSweepCompact", OLD); + put("PS MarkSweep", OLD); + put("PS Scavenge", YOUNG); + put("ParNew", YOUNG); + }}; + + static GcGenerationAge fromName(String name) { + return knownCollectors.getOrDefault(name, UNKNOWN); + } + + public boolean contains(String name) { + return this == fromName(name); + } + } + +} + + + +不只是 GC 事件，内存相关的信息都可以通过 JMX 来实现监听。很多 APM 也是通过类似的手段来实现数据上报。 + +APM 工具与监控系统 + +在线可视化监控是如今生产环境必备的一个功能。业务出错和性能问题随时都可能会发生，而且现在很多系统不再有固定的业务窗口期，所以必须做到 7x24 小时的实时监控。 + +目前业界有很多监控工具，各有优缺点，需要根据需要进行抉择。 + +一般来说，系统监控可以分为三个部分： + + +系统性能监控，包括 CPU、内存、磁盘 IO、网络等硬件资源和系统负载的监控信息。 +业务日志监控，场景的是 ELK 技术栈、并使用 Logback+Kafka 等技术来采集日志。 +APM 性能指标监控，比如 QPS、TPS、响应时间等等，例如 MicroMeter、Pinpoint 等。 + + +系统监控的模块也是两大块： + + +指标采集部分 +数据可视化系统 + + +如今监控工具是生产环境的重要组成部分。测量结果的可视化、错误追踪、性能监控和应用分析是对应用的运行状况进行深入观测的基本手段。 + +认识到这一需求非常容易，但要选择哪一款监控工具或者哪一组监控工具却异常困难。 + +下面介绍几款监测工具，这些工具包括混合开源和 SaaS 模式，每个都有其优缺点，可以说没有完美的工具，只有合适的工具。 + +指标采集客户端 + + +Micrometer：作为指标采集的基础类库，基于客户端机器来进行，用户无需关注具体的 JVM 版本和厂商。以相同的方式来配置，可以对接到不同的可视化监控系统服务。主要用于监控、告警，以及对当前的系统环境变化做出响应。Micrometer 还会注册 JMX 相关的 MBeans，非常简单和方便地在本地通过 JMX 来查看相关指标。如果是生产环境中使用，则一般是将监控指标导出到其他监控系统中保存起来。 +云服务监控系统：云服务监控系统厂商一般都会提供配套的指标采集客户端，并对外开放各种 API 接口和数据标准，允许客户使用自己的指标采集系统。 +开源监控系统：各种开源监控系统也会提供对应的指标采集客户端。 + + +云服务监控系统 + +SaaS 服务的监控系统一般提供存储、查询、可视化等功能的一体化云服务。大多包含免费试用和收费服务两种模式。如果企业和机构的条件允许，付费使用云服务一般是最好的选择，毕竟“免费的才是最贵的”。 + +下面我们一起来看看有哪些云服务： + + +AppOptics，支持 APM 和系统监控的 SaaS 服务，支持各种仪表板和时间轴等监控界面，提供 API 和客户端。 +Datadog，支持 APM 和系统监控的 SaaS 服务，内置各种仪表板，支持告警。支持 API 和客户端，以及客户端代理。 +Dynatrace，支持 APM 和系统监控的 SaaS 服务，内置各种仪表板，集成了监控和分析平台。 +Humio，支持 APM、日志和系统监控的 SaaS 服务。 +Instana，支持自动 APM、系统监控的 SaaS 服务。 +New Relic，这是一款具有完整 UI 的可视化 SaaS 产品，支持 NRQL 查询语言，New Relic Insights 基于推模型来运行。 +SignalFx，在推送模型上运行的 SaaS 服务，具有完整 UI。支持实时的系统性能、微服务，以及 APM 监控系统，支持多样化的预警“检测器”。 +Stackdriver，是 Google Cloud 的嵌入式监测套件，用于监控云基础架构、软件和应用的性能，排查其中的问题并加以改善。这个监测套件属于 SaaS 服务，支持内置仪表板和告警功能。 +Wavefront，是基于 SaaS 的指标监视和分析平台，支持可视化查询，以及预警监控等功能，包括系统性能、网络、自定义指标、业务 KPI 等等。 +听云，是国内最大的应用性能管理（APM）解决方案提供商。可以实现应用性能全方位可视化，从 PC 端、浏览器端、移动客户端到服务端，监控定位崩溃、卡顿、交互过慢、第三方 API 调用失败、数据库性能下降、CDN 质量差等多维复杂的性能问题。 +OneAPM，OneAPM（蓝海讯通）提供端到端 APM 应用性能管理软件及应用性能监控软件解决方案。 +Plumbr，监测可用性和性能问题，使用跟踪技术，能迅速定位错误相关的位置信息，发现、验证和修复各种故障和性能问题。 +Takipi，现在改名叫做 OverOps，系统故障实时监测系统。能快速定位问题发生的时间、位置和原因。 + + +其中做得比较好的有国外的 Datadog，国内的听云。 + +开源监控系统 + + +Pinpoint，受 Dapper 启发，使用 Java/PHP 来实现的大型分布式系统 APM 工具。Pinpoint 提供了一套解决方案，可通过跟踪分布式应用程序之间的事务来快速定位调用链路。 +Atlas，是 Netflix 旗下的一款开源的，基于内存的时序数据库，内置图形界面，支持高级数学运算和自定义查询语言。 +ELK 技术栈，一般用于日志监控，Elasticsearch 是搜索引擎，支持各种数据和指标存储，日志监控一般通过 Logstash 执行分析，Kibana 负责人机交互和可视化。 +Influx，InfluxDB 是由 InfluxData 开发的一款开源时序型数据库。它由 Go 写成，着力于高性能地查询与存储时序数据。InfluxDB 被广泛应用于存储系统的监控数据、IoT 行业的实时数据等场景，通过类似 SQL 的查询语言来完成数据分析。InfluxData 工具套件可用于实时流处理，支持抽样采集指标、自动过期、删除不需要的数据，以及备份和还原等功能。 +Ganglia，用于高性能计算系统、群集和网络的可伸缩的分布式监控工具。起源于加州大学伯克利分校，是一款历史悠久的多层级指标监控系统，在 Linux 系统中广受欢迎。 +Graphite，当前非常流行的多层级次指标监控系统，使用固定数量的底层数据库，其设计和目的与 RRD 相似。由 Orbitz 在 2006 年创建，并于 2008 年开源。 +KairosDB，是建立在 Apache Cassandra 基础上的时序数据库。可以通过 Grafana 来绘制精美漂亮的监控图表。 +Prometheus，具有简单的内置 UI，支持自定义查询语言和数学运算的、开源的内存时序数据库。Prometheus 设计为基于拉模型来运行，根据服务发现，定期从应用程序实例中收集指标。 +StatsD，开源的、简单但很强大的统计信息聚合服务器。 + + +其中 Pinpoint 和 Prometheus 比较受欢迎。 + +参考链接 + + +利用 JMX 的 Notifications 监听 GC +推荐 7 个超棒的监控工具 + + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/00开篇词业务代码真的会有这么多坑？.md b/专栏/Java业务开发常见错误100例/00开篇词业务代码真的会有这么多坑？.md new file mode 100644 index 0000000..1a36316 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/00开篇词业务代码真的会有这么多坑？.md @@ -0,0 +1,101 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 00 开篇词 业务代码真的会有这么多坑？ + 我先和你说说我这 15 年的工作经历吧，以加深彼此的了解。前 7 年，我专注于.NET 领域，负责业务项目的同时，也做了很多社区工作。在 CSDN 做版主期间，我因为回答了大量有关.NET 的问题，并把很多问题的答案总结成了博客，获得了 3 次微软 MVP 的称号。 + +后来，我转到了 Java 领域，也从程序员变为了架构师，更关注开源项目和互联网架构设计。在空中网，我整体负责了百万人在线的大型 MMO 网游《激战》技术平台的架构设计，期间和团队开发了许多性能和稳定性都不错的 Java 框架；在饿了么，我负责过日千万订单量的物流平台的开发管理和架构工作，遇到了许多只有高并发下才会出现的问题，积累了大量的架构经验；现在，我在贝壳金服的基础架构团队，负责基础组件、中间件、基础服务开发规划，制定一些流程和规范，带领团队自研 Java 后端开发框架、微服务治理平台等，在落地 Spring Cloud 结合 Kubernetes 容器云平台技术体系的过程中，摸索出了很多适合公司项目的基础组件和最佳实践。 + +这 15 年来，我一直没有脱离编码工作，接触过大大小小的项目不下 400 个，自己亲身经历的、见别人踩过的坑不计其数。我感触很深的一点是，业务代码中真的有太多的坑：有些是看似非常简单的知识点反而容易屡次踩坑，比如 Spring 声明式事务不生效的问题；而有些坑因为“潜伏期”长，引发的线上事故造成了大量的人力和资金损失。因此，我系统梳理了这些案例和坑点，最终筛选出 100 个案例，涉及 130 多个坑点，组成了这个课程。 + +意识不到业务代码的坑，很危险 + +我想看到 100、130 这两个数字，你不禁要问了：“我写了好几年的业务代码了，遇到问题时上网搜一下就有答案，遇到最多的问题就是服务器不稳定，重启一下基本就可以解决，哪里会有这么多坑呢？”带着这个问题，你继续听我往下说吧。 + +据我观察，很多开发同学没意识到这些坑，有以下三种可能： + +意识不到坑的存在，比如所谓的服务器不稳定很可能是代码问题导致的，很多时候遇到 OOM、死锁、超时问题在运维层面通过改配置、重启、扩容等手段解决了，没有反推到开发层面去寻找根本原因。 + +有些问题只会在特定情况下暴露。比如，缓存击穿、在多线程环境使用非线程安全的类，只有在多线程或高并发的情况才会暴露问题。 + +有些性能问题不会导致明显的 Bug，只会让程序运行缓慢、内存使用增加，但会在量变到质变的瞬间爆发。 + +而正是因为没有意识到这些坑和问题，采用了错误的处理方式，最后问题一旦爆发，处理起来就非常棘手，这是非常可怕的。下面这些场景有没有感觉似曾相识呢？ + +比如，我曾听说过有一个订单量很大的项目，每天总有上千份订单的状态或流程有问题，需要花费大量的时间来核对数据，修复订单状态。开发同学因为每天牵扯太多精力在排查问题上，根本没时间开发新需求。技术负责人为此头痛不已，无奈之下招了专门的技术支持人员。最后痛定思痛，才决定开启明细日志彻查这个问题，结果发现是自调用方法导致事务没生效的坑。 + +再比如，有个朋友告诉我，他们的金融项目计算利息的代码中，使用了 float 类型而不是 BigDecimal 类来保存和计算金额，导致给用户结算的每一笔利息都多了几分钱。好在，日终对账及时发现了问题。试想一下，结算的有上千个用户，每个用户有上千笔小订单，如果等月终对账的时候再发现，可能已经损失了几百万。 + +再比如，我们使用 RabbitMQ 做异步处理，业务处理失败的消息会循环不断地进入 MQ。问题爆发之前，可能只影响了消息处理的时效性。但等 MQ 彻底瘫痪时，面对 MQ 中堆积的、混杂了死信和正常消息的几百万条数据，你除了清空又能怎么办。但清空 MQ，就意味着要花费几小时甚至几十小时的时间，来补正常的业务数据，对业务影响时间很长。 + +像这样由一个小坑引发的重大事故，不仅仅会给公司造成损失，还会因为自责影响工作状态，降低编码的自信心。我就曾遇到过一位比较负责的核心开发同学，因为一个 Bug 给公司带来数万元的经济损失，最后心理上承受不住提出了辞职。 + +其实，很多时候不是我们不想从根本上解决问题，只是不知道问题到底在了哪里。要避开这些坑、找到这些定时炸弹，第一步就是得知道它们是什么、在哪里、为什么会出现。而讲清楚这些坑点和相关的最佳实践，正是本课程的主要内容。 + +这个课程是什么？ + +如果用几个关键词概括这个课程的话，那我会选择“Java”“业务开发”“避坑 100 例”这 3 个。接下来，我就和你详细说说这个课程是什么，以及有什么特点。 + +第一个关键词是“Java”，指的是课程内所有 Demo 都是基于 Java 语言的。 + +如果你熟悉 Java，那可以 100% 体会到这些坑点，也可以直接用这些 Demo 去检查你的业务代码是否也有类似的错误实现。 + +如果你不熟悉 Java 问题也不大，现在大部分高级语言的特性和结构都差不多，许多都是共性问题。此外“设计篇”“安全篇”的内容，基本是脱离具体语言层面的、高层次的问题。因此，即使不使用 Java，你也可以有不少收获，这也是本课程的第一个特点。 + +讲到这里，我要说明的是，这个课程是围绕坑点而不是 Java 语言体系展开的，因此不是系统学习 Java 的教材。 + +第二个关键词是“业务开发”，也就是说课程内容限定在业务项目的开发，侧重业务项目开发时可能遇到的坑。 + +我们先看“业务”这个词。做业务开发时间长的同学尤其知道，业务项目有两大特点： + +工期紧、逻辑复杂，开发人员会更多地考虑主流程逻辑的正确实现，忽略非主流程逻辑，或保障、补偿、一致性逻辑的实现； + +往往缺乏详细的设计、监控和容量规划的闭环，结果就是随着业务发展出现各种各样的事故。 + +根据这些性质，我总结出了近 30 个方面的内容，力求覆盖业务项目开发的关键问题。案例的全面性，是本课程的第二大特点。 + +这些案例可以看作是 Java 业务代码的避坑大全，帮助你写出更好的代码，也能帮你进一步补全知识网增加面试的信心。你甚至可以把二级目录当作代码审核的 Checklist，帮助业务项目一起成长和避坑。 + +我们再看“开发”这个词。为了更聚焦，也更有针对性，我把专栏内容限定在业务开发，不会过多地讨论架构、测试、部署运维等阶段的问题。而“设计篇”，重在讲述架构设计上可能会遇到的坑，不会全面、完整地介绍高可用、高并发、可伸缩性等架构因素。 + +第三个关键词是“避坑 100 例”。坑就是容易犯的错，避坑就是踩坑后分析根因，避免重复踩同样的坑。 + +整个课程 30 篇文章，涉及 100 个案例、约 130 个小坑，其中 40% 来自于我经历过或者是见过的 200 多个线上生产事故，剩下的 60% 来自于我开发业务项目，以及日常审核别人的代码发现的问题。贴近实际，而不是讲述过时的或日常开发根本用不到的技术或框架，就是本课程的第三大特点了。 + +大部分案例我会配合一个可执行的 Demo 来演示，Demo 中不仅有错误实现（踩坑），还有修正后的正确实现（避坑）。完整且连续、授人以渔，是本课程的第四大特点。 + +完整且连续，知其所以然。我会按照“知识介绍 -> 还原业务场景 -> 错误实现 -> 正确实现 -> 原理分析 -> 小总结 ”来讲解每个案例，针对每个坑点我至少会给出一个解决方案，并会挑选核心的点和你剖析源码。这样一来，你不仅能避坑，更能知道产生坑的根本原因，提升自己的技术能力。 + +授人以渔。在遇到问题的时候，我们一定是先通过经验和工具来定位分析问题，然后才能定位到坑，并不是一开始就知道为什么的。在这个课程中，我会尽可能地把分析问题的过程完整地呈现给你，而不是直接告诉你为什么，这样你以后遇到问题时也能有解决问题的思路。 + +这也是为什么，网络上虽然有很多关于 Java 代码踩坑的资料，但很多同学却和我反馈说，看过之后印象不深刻，也因为没吃透导致在一个知识点上重复踩坑。鉴于此，我还会与你分析我根据多年经验和思考，梳理出的一些最佳实践。 + +看到这里，是不是迫不及待地想要看看这个专栏的内容都会涉及哪些坑点了呢？那就看看下面这张思维导图吧： + + + +鉴于这个专栏的内容和特点，我再和你说说最佳的学习方式是什么。 + +学习课程的最佳方法 + +我们都知道，编程是一门实践科学，只看不练、不思考，效果通常不会太好。因此，我建议你打开每篇文章后，能够按照下面的方式深入学习： + +对于每一个坑点，实际运行调试一下源码，使用文中提到的工具和方法重现问题，眼见为实。 + +对于每一个坑点，再思考下除了文内的解决方案和思路外，是否还有其他修正方式。 + +对于坑点根因中涉及的 JDK 或框架源码分析，你可以找到相关类再系统阅读一下源码。 + +实践课后思考题。这些思考题，有的是对文章内容的补充，有的是额外容易踩的坑。 + +理解了课程涉及的所有案例后，你应该就对业务代码大部分容易犯错的点了如指掌了，不仅仅自己可以写出更高质量的业务代码，还可以在审核别人代码时发现可能存在的问题，帮助整个团队成长。 + +当然了，你从这个课程收获的将不仅是解决案例中那些问题的方法，还可以提升自己分析定位问题、阅读源码的能力。当你再遇到其他诡异的坑时，也能有清晰的解决思路，也可以成长为一名救火专家，帮助大家一起定位、分析问题。 + +好了，以上就是我今天想要和你分享的内容了。请赶快跟随我们的课程开启避坑之旅吧，也欢迎你留言说说自己的情况，你都踩过哪些坑、对写业务代码又有哪些困惑？我们下一讲见！ + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/01使用了并发工具类库，线程安全就高枕无忧了吗？.md b/专栏/Java业务开发常见错误100例/01使用了并发工具类库，线程安全就高枕无忧了吗？.md new file mode 100644 index 0000000..f804554 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/01使用了并发工具类库，线程安全就高枕无忧了吗？.md @@ -0,0 +1,452 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 01 使用了并发工具类库，线程安全就高枕无忧了吗？ + 作为课程的第一讲，我今天要和你聊聊使用并发工具类库相关的话题。 + +在代码审核讨论的时候，我们有时会听到有关线程安全和并发工具的一些片面的观点和结论，比如“把 HashMap 改为 ConcurrentHashMap，就可以解决并发问题了呀”“要不我们试试无锁的 CopyOnWriteArrayList 吧，性能更好”。事实上，这些说法都不太准确。 + +的确，为了方便开发者进行多线程编程，现代编程语言会提供各种并发工具类。但如果我们没有充分了解它们的使用场景、解决的问题，以及最佳实践的话，盲目使用就可能会导致一些坑，小则损失性能，大则无法确保多线程情况下业务逻辑的正确性。 + +我需要先说明下，这里的并发工具类是指用来解决多线程环境下并发问题的工具类库。一般而言并发工具包括同步器和容器两大类，业务代码中使用并发容器的情况会多一些，我今天分享的例子也会侧重并发容器。 + +接下来，我们就看看在使用并发工具时，最常遇到哪些坑，以及如何解决、避免这些坑吧。 + +没有意识到线程重用导致用户信息错乱的 Bug + +之前有业务同学和我反馈，在生产上遇到一个诡异的问题，有时获取到的用户信息是别人的。查看代码后，我发现他使用了 ThreadLocal 来缓存获取到的用户信息。 + +我们知道，ThreadLocal 适用于变量在线程间隔离，而在方法或类间共享的场景。如果用户信息的获取比较昂贵（比如从数据库查询用户信息），那么在 ThreadLocal 中缓存数据是比较合适的做法。但，这么做为什么会出现用户信息错乱的 Bug 呢？ + +我们看一个具体的案例吧。 + +使用 Spring Boot 创建一个 Web 应用程序，使用 ThreadLocal 存放一个 Integer 的值，来暂且代表需要在线程中保存的用户信息，这个值初始是 null。在业务逻辑中，我先从 ThreadLocal 获取一次值，然后把外部传入的参数设置到 ThreadLocal 中，来模拟从当前上下文获取到用户信息的逻辑，随后再获取一次值，最后输出两次获得的值和线程名称。 + +private static final ThreadLocal currentUser = ThreadLocal.withInitial(() -> null); + +@GetMapping("wrong") +public Map wrong(@RequestParam("userId") Integer userId) { + //设置用户信息之前先查询一次ThreadLocal中的用户信息 + String before = Thread.currentThread().getName() + ":" + currentUser.get(); + //设置用户信息到ThreadLocal + currentUser.set(userId); + //设置用户信息之后再查询一次ThreadLocal中的用户信息 + String after = Thread.currentThread().getName() + ":" + currentUser.get(); + //汇总输出两次查询结果 + Map result = new HashMap(); + result.put("before", before); + result.put("after", after); + return result; +} + + +按理说，在设置用户信息之前第一次获取的值始终应该是 null，但我们要意识到，程序运行在 Tomcat 中，执行程序的线程是 Tomcat 的工作线程，而 Tomcat 的工作线程是基于线程池的。 + +顾名思义，线程池会重用固定的几个线程，一旦线程重用，那么很可能首次从 ThreadLocal 获取的值是之前其他用户的请求遗留的值。这时，ThreadLocal 中的用户信息就是其他用户的信息。 + +为了更快地重现这个问题，我在配置文件中设置一下 Tomcat 的参数，把工作线程池最大线程数设置为 1，这样始终是同一个线程在处理请求： + +server.tomcat.max-threads=1 + + +运行程序后先让用户 1 来请求接口，可以看到第一和第二次获取到用户 ID 分别是 null 和 1，符合预期： + + + +随后用户 2 来请求接口，这次就出现了 Bug，第一和第二次获取到用户 ID 分别是 1 和 2，显然第一次获取到了用户 1 的信息，原因就是 Tomcat 的线程池重用了线程。从图中可以看到，两次请求的线程都是同一个线程：http-nio-8080-exec-1。 + + + +这个例子告诉我们，在写业务代码时，首先要理解代码会跑在什么线程上： + + +我们可能会抱怨学多线程没用，因为代码里没有开启使用多线程。但其实，可能只是我们没有意识到，在 Tomcat 这种 Web 服务器下跑的业务代码，本来就运行在一个多线程环境（否则接口也不可能支持这么高的并发），并不能认为没有显式开启多线程就不会有线程安全问题。 + +因为线程的创建比较昂贵，所以 Web 服务器往往会使用线程池来处理请求，这就意味着线程会被重用。这时，使用类似 ThreadLocal 工具来存放一些数据时，需要特别注意在代码运行完后，显式地去清空设置的数据。如果在代码中使用了自定义的线程池，也同样会遇到这个问题。 + + +理解了这个知识点后，我们修正这段代码的方案是，在代码的 finally 代码块中，显式清除 ThreadLocal 中的数据。这样一来，新的请求过来即使使用了之前的线程也不会获取到错误的用户信息了。修正后的代码如下： + +@GetMapping("right") +public Map right(@RequestParam("userId") Integer userId) { + String before = Thread.currentThread().getName() + ":" + currentUser.get(); + currentUser.set(userId); + try { + String after = Thread.currentThread().getName() + ":" + currentUser.get(); + Map result = new HashMap(); + result.put("before", before); + result.put("after", after); + return result; + } finally { + //在finally代码块中删除ThreadLocal中的数据，确保数据不串 + currentUser.remove(); + } +} + + +重新运行程序可以验证，再也不会出现第一次查询用户信息查询到之前用户请求的 Bug： + + + +ThreadLocal 是利用独占资源的方式，来解决线程安全问题，那如果我们确实需要有资源在线程之间共享，应该怎么办呢？这时，我们可能就需要用到线程安全的容器了。 + +使用了线程安全的并发工具，并不代表解决了所有线程安全问题 + +JDK 1.5 后推出的 ConcurrentHashMap，是一个高性能的线程安全的哈希表容器。“线程安全”这四个字特别容易让人误解，因为 ConcurrentHashMap 只能保证提供的原子性读写操作是线程安全的。 + +我在相当多的业务代码中看到过这个误区，比如下面这个场景。有一个含 900 个元素的 Map，现在再补充 100 个元素进去，这个补充操作由 10 个线程并发进行。开发人员误以为使用了 ConcurrentHashMap 就不会有线程安全问题，于是不加思索地写出了下面的代码：在每一个线程的代码逻辑中先通过 size 方法拿到当前元素数量，计算 ConcurrentHashMap 目前还需要补充多少元素，并在日志中输出了这个值，然后通过 putAll 方法把缺少的元素添加进去。 + +为方便观察问题，我们输出了这个 Map 一开始和最后的元素个数。 + +//线程个数 +private static int THREAD_COUNT = 10; +//总元素数量 +private static int ITEM_COUNT = 1000; +//帮助方法，用来获得一个指定元素数量模拟数据的ConcurrentHashMap +private ConcurrentHashMap getData(int count) { + return LongStream.rangeClosed(1, count) + .boxed() + .collect(Collectors.toConcurrentMap(i -> UUID.randomUUID().toString(), Function.identity(), + (o1, o2) -> o1, ConcurrentHashMap::new)); +} + +@GetMapping("wrong") +public String wrong() throws InterruptedException { + ConcurrentHashMap concurrentHashMap = getData(ITEM_COUNT - 100); + //初始900个元素 + log.info("init size:{}", concurrentHashMap.size()); + ForkJoinPool forkJoinPool = new ForkJoinPool(THREAD_COUNT); + //使用线程池并发处理逻辑 + forkJoinPool.execute(() -> IntStream.rangeClosed(1, 10).parallel().forEach(i -> { + //查询还需要补充多少个元素 + int gap = ITEM_COUNT - concurrentHashMap.size(); + log.info("gap size:{}", gap); + //补充元素 + concurrentHashMap.putAll(getData(gap)); + })); + //等待所有任务完成 + forkJoinPool.shutdown(); + forkJoinPool.awaitTermination(1, TimeUnit.HOURS); + //最后元素个数会是1000吗？ + log.info("finish size:{}", concurrentHashMap.size()); + return "OK"; +} + + +访问接口后程序输出的日志内容如下： + + + +从日志中可以看到： + + +初始大小 900 符合预期，还需要填充 100 个元素。 + +worker1 线程查询到当前需要填充的元素为 36，竟然还不是 100 的倍数。 + +worker13 线程查询到需要填充的元素数是负的，显然已经过度填充了。 + +最后 HashMap 的总项目数是 1536，显然不符合填充满 1000 的预期。 + + +针对这个场景，我们可以举一个形象的例子。ConcurrentHashMap 就像是一个大篮子，现在这个篮子里有 900 个桔子，我们期望把这个篮子装满 1000 个桔子，也就是再装 100 个桔子。有 10 个工人来干这件事儿，大家先后到岗后会计算还需要补多少个桔子进去，最后把桔子装入篮子。 + +ConcurrentHashMap 这个篮子本身，可以确保多个工人在装东西进去时，不会相互影响干扰，但无法确保工人 A 看到还需要装 100 个桔子但是还未装的时候，工人 B 就看不到篮子中的桔子数量。更值得注意的是，你往这个篮子装 100 个桔子的操作不是原子性的，在别人看来可能会有一个瞬间篮子里有 964 个桔子，还需要补 36 个桔子。 + +回到 ConcurrentHashMap，我们需要注意 ConcurrentHashMap 对外提供的方法或能力的限制： + + +使用了 ConcurrentHashMap，不代表对它的多个操作之间的状态是一致的，是没有其他线程在操作它的，如果需要确保需要手动加锁。 + +诸如 size、isEmpty 和 containsValue 等聚合方法，在并发情况下可能会反映 ConcurrentHashMap 的中间状态。因此在并发情况下，这些方法的返回值只能用作参考，而不能用于流程控制。显然，利用 size 方法计算差异值，是一个流程控制。 + +诸如 putAll 这样的聚合方法也不能确保原子性，在 putAll 的过程中去获取数据可能会获取到部分数据。 + + +代码的修改方案很简单，整段逻辑加锁即可： + +@GetMapping("right") +public String right() throws InterruptedException { + ConcurrentHashMap concurrentHashMap = getData(ITEM_COUNT - 100); + log.info("init size:{}", concurrentHashMap.size()); + + ForkJoinPool forkJoinPool = new ForkJoinPool(THREAD_COUNT); + forkJoinPool.execute(() -> IntStream.rangeClosed(1, 10).parallel().forEach(i -> { + //下面的这段复合逻辑需要锁一下这个ConcurrentHashMap + synchronized (concurrentHashMap) { + int gap = ITEM_COUNT - concurrentHashMap.size(); + log.info("gap size:{}", gap); + concurrentHashMap.putAll(getData(gap)); + } + })); + forkJoinPool.shutdown(); + forkJoinPool.awaitTermination(1, TimeUnit.HOURS); + log.info("finish size:{}", concurrentHashMap.size()); + return "OK"; +} + + +重新调用接口，程序的日志输出结果符合预期： + + + +可以看到，只有一个线程查询到了需要补 100 个元素，其他 9 个线程查询到不需要补元素，最后 Map 大小为 1000。 + +到了这里，你可能又要问了，使用 ConcurrentHashMap 全程加锁，还不如使用普通的 HashMap 呢。 + +其实不完全是这样。 + +ConcurrentHashMap 提供了一些原子性的简单复合逻辑方法，用好这些方法就可以发挥其威力。这就引申出代码中常见的另一个问题：在使用一些类库提供的高级工具类时，开发人员可能还是按照旧的方式去使用这些新类，因为没有使用其特性，所以无法发挥其威力。 + +没有充分了解并发工具的特性，从而无法发挥其威力 + +我们来看一个使用 Map 来统计 Key 出现次数的场景吧，这个逻辑在业务代码中非常常见。 + + +使用 ConcurrentHashMap 来统计，Key 的范围是 10。 + +使用最多 10 个并发，循环操作 1000 万次，每次操作累加随机的 Key。 + +如果 Key 不存在的话，首次设置值为 1。 + + +代码如下： + +//循环次数 +private static int LOOP_COUNT = 10000000; +//线程数量 +private static int THREAD_COUNT = 10; +//元素数量 +private static int ITEM_COUNT = 10; +private Map normaluse() throws InterruptedException { + ConcurrentHashMap freqs = new ConcurrentHashMap<>(ITEM_COUNT); + ForkJoinPool forkJoinPool = new ForkJoinPool(THREAD_COUNT); + forkJoinPool.execute(() -> IntStream.rangeClosed(1, LOOP_COUNT).parallel().forEach(i -> { + //获得一个随机的Key + String key = "item" + ThreadLocalRandom.current().nextInt(ITEM_COUNT); + synchronized (freqs) { + if (freqs.containsKey(key)) { + //Key存在则+1 + freqs.put(key, freqs.get(key) + 1); + } else { + //Key不存在则初始化为1 + freqs.put(key, 1L); + } + } + } + )); + forkJoinPool.shutdown(); + forkJoinPool.awaitTermination(1, TimeUnit.HOURS); + return freqs; +} + + +我们吸取之前的教训，直接通过锁的方式锁住 Map，然后做判断、读取现在的累计值、加 1、保存累加后值的逻辑。这段代码在功能上没有问题，但无法充分发挥 ConcurrentHashMap 的威力，改进后的代码如下： + +private Map gooduse() throws InterruptedException { + ConcurrentHashMap freqs = new ConcurrentHashMap<>(ITEM_COUNT); + ForkJoinPool forkJoinPool = new ForkJoinPool(THREAD_COUNT); + forkJoinPool.execute(() -> IntStream.rangeClosed(1, LOOP_COUNT).parallel().forEach(i -> { + String key = "item" + ThreadLocalRandom.current().nextInt(ITEM_COUNT); + //利用computeIfAbsent()方法来实例化LongAdder，然后利用LongAdder来进行线程安全计数 + freqs.computeIfAbsent(key, k -> new LongAdder()).increment(); + } + )); + forkJoinPool.shutdown(); + forkJoinPool.awaitTermination(1, TimeUnit.HOURS); + //因为我们的Value是LongAdder而不是Long，所以需要做一次转换才能返回 + return freqs.entrySet().stream() + .collect(Collectors.toMap( + e -> e.getKey(), + e -> e.getValue().longValue()) + ); +} + + +在这段改进后的代码中，我们巧妙利用了下面两点： + + +使用 ConcurrentHashMap 的原子性方法 computeIfAbsent 来做复合逻辑操作，判断 Key 是否存在 Value，如果不存在则把 Lambda 表达式运行后的结果放入 Map 作为 Value，也就是新创建一个 LongAdder 对象，最后返回 Value。 + +由于 computeIfAbsent 方法返回的 Value 是 LongAdder，是一个线程安全的累加器，因此可以直接调用其 increment 方法进行累加。 + + +这样在确保线程安全的情况下达到极致性能，把之前 7 行代码替换为了 1 行。 + +我们通过一个简单的测试比较一下修改前后两段代码的性能： + +@GetMapping("good") +public String good() throws InterruptedException { + StopWatch stopWatch = new StopWatch(); + stopWatch.start("normaluse"); + Map normaluse = normaluse(); + stopWatch.stop(); + //校验元素数量 + Assert.isTrue(normaluse.size() == ITEM_COUNT, "normaluse size error"); + //校验累计总数 + Assert.isTrue(normaluse.entrySet().stream() + .mapToLong(item -> item.getValue()).reduce(0, Long::sum) == LOOP_COUNT + , "normaluse count error"); + stopWatch.start("gooduse"); + Map gooduse = gooduse(); + stopWatch.stop(); + Assert.isTrue(gooduse.size() == ITEM_COUNT, "gooduse size error"); + Assert.isTrue(gooduse.entrySet().stream() + .mapToLong(item -> item.getValue()) + .reduce(0, Long::sum) == LOOP_COUNT + , "gooduse count error"); + log.info(stopWatch.prettyPrint()); + return "OK"; +} + + +这段测试代码并无特殊之处，使用 StopWatch 来测试两段代码的性能，最后跟了一个断言判断 Map 中元素的个数以及所有 Value 的和，是否符合预期来校验代码的正确性。测试结果如下： + + + +可以看到，优化后的代码，相比使用锁来操作 ConcurrentHashMap 的方式，性能提升了 10 倍。 + +你可能会问，computeIfAbsent 为什么如此高效呢？ + +答案就在源码最核心的部分，也就是 Java 自带的 Unsafe 实现的 CAS。它在虚拟机层面确保了写入数据的原子性，比加锁的效率高得多： + + static final boolean casTabAt(Node[] tab, int i, + Node c, Node v) { + return U.compareAndSetObject(tab, ((long)i << ASHIFT) + ABASE, c, v); + } + + +像 ConcurrentHashMap 这样的高级并发工具的确提供了一些高级 API，只有充分了解其特性才能最大化其威力，而不能因为其足够高级、酷炫盲目使用。 + +没有认清并发工具的使用场景，因而导致性能问题 + +除了 ConcurrentHashMap 这样通用的并发工具类之外，我们的工具包中还有些针对特殊场景实现的生面孔。一般来说，针对通用场景的通用解决方案，在所有场景下性能都还可以，属于“万金油”；而针对特殊场景的特殊实现，会有比通用解决方案更高的性能，但一定要在它针对的场景下使用，否则可能会产生性能问题甚至是 Bug。 + +之前在排查一个生产性能问题时，我们发现一段简单的非数据库操作的业务逻辑，消耗了超出预期的时间，在修改数据时操作本地缓存比回写数据库慢许多。查看代码发现，开发同学使用了 CopyOnWriteArrayList 来缓存大量的数据，而数据变化又比较频繁。 + +CopyOnWrite 是一个时髦的技术，不管是 Linux 还是 Redis 都会用到。在 Java 中，CopyOnWriteArrayList 虽然是一个线程安全的 ArrayList，但因为其实现方式是，每次修改数据时都会复制一份数据出来，所以有明显的适用场景，即读多写少或者说希望无锁读的场景。 + +如果我们要使用 CopyOnWriteArrayList，那一定是因为场景需要而不是因为足够酷炫。如果读写比例均衡或者有大量写操作的话，使用 CopyOnWriteArrayList 的性能会非常糟糕。 + +我们写一段测试代码，来比较下使用 CopyOnWriteArrayList 和普通加锁方式 ArrayList 的读写性能吧。在这段代码中我们针对并发读和并发写分别写了一个测试方法，测试两者一定次数的写或读操作的耗时。 + +//测试并发写的性能 +@GetMapping("write") +public Map testWrite() { + List copyOnWriteArrayList = new CopyOnWriteArrayList<>(); + List synchronizedList = Collections.synchronizedList(new ArrayList<>()); + StopWatch stopWatch = new StopWatch(); + int loopCount = 100000; + stopWatch.start("Write:copyOnWriteArrayList"); + //循环100000次并发往CopyOnWriteArrayList写入随机元素 + IntStream.rangeClosed(1, loopCount).parallel().forEach(__ -> copyOnWriteArrayList.add(ThreadLocalRandom.current().nextInt(loopCount))); + stopWatch.stop(); + stopWatch.start("Write:synchronizedList"); + //循环100000次并发往加锁的ArrayList写入随机元素 + IntStream.rangeClosed(1, loopCount).parallel().forEach(__ -> synchronizedList.add(ThreadLocalRandom.current().nextInt(loopCount))); + stopWatch.stop(); + log.info(stopWatch.prettyPrint()); + Map result = new HashMap(); + result.put("copyOnWriteArrayList", copyOnWriteArrayList.size()); + result.put("synchronizedList", synchronizedList.size()); + return result; +} +//帮助方法用来填充List +private void addAll(List list) { + list.addAll(IntStream.rangeClosed(1, 1000000).boxed().collect(Collectors.toList())); +} +//测试并发读的性能 +@GetMapping("read") +public Map testRead() { + //创建两个测试对象 + List copyOnWriteArrayList = new CopyOnWriteArrayList<>(); + List synchronizedList = Collections.synchronizedList(new ArrayList<>()); + //填充数据 + addAll(copyOnWriteArrayList); + addAll(synchronizedList); + StopWatch stopWatch = new StopWatch(); + int loopCount = 1000000; + int count = copyOnWriteArrayList.size(); + stopWatch.start("Read:copyOnWriteArrayList"); + //循环1000000次并发从CopyOnWriteArrayList随机查询元素 + IntStream.rangeClosed(1, loopCount).parallel().forEach(__ -> copyOnWriteArrayList.get(ThreadLocalRandom.current().nextInt(count))); + stopWatch.stop(); + stopWatch.start("Read:synchronizedList"); + //循环1000000次并发从加锁的ArrayList随机查询元素 + IntStream.range(0, loopCount).parallel().forEach(__ -> synchronizedList.get(ThreadLocalRandom.current().nextInt(count))); + stopWatch.stop(); + log.info(stopWatch.prettyPrint()); + Map result = new HashMap(); + result.put("copyOnWriteArrayList", copyOnWriteArrayList.size()); + result.put("synchronizedList", synchronizedList.size()); + return result; +} + + +运行程序可以看到，大量写的场景（10 万次 add 操作），CopyOnWriteArray 几乎比同步的 ArrayList 慢一百倍： + + + +而在大量读的场景下（100 万次 get 操作），CopyOnWriteArray 又比同步的 ArrayList 快五倍以上： + + + +你可能会问，为何在大量写的场景下，CopyOnWriteArrayList 会这么慢呢？ + +答案就在源码中。以 add 方法为例，每次 add 时，都会用 Arrays.copyOf 创建一个新数组，频繁 add 时内存的申请释放消耗会很大： + + /** + * Appends the specified element to the end of this list. + * + * @param e element to be appended to this list + * @return {@code true} (as specified by {@link Collection#add}) + */ + public boolean add(E e) { + synchronized (lock) { + Object[] elements = getArray(); + int len = elements.length; + Object[] newElements = Arrays.copyOf(elements, len + 1); + newElements[len] = e; + setArray(newElements); + return true; + } + } + + +重点回顾 + +今天，我主要与你分享了，开发人员使用并发工具来解决线程安全问题时容易犯的四类错。 + +一是，只知道使用并发工具，但并不清楚当前线程的来龙去脉，解决多线程问题却不了解线程。比如，使用 ThreadLocal 来缓存数据，以为 ThreadLocal 在线程之间做了隔离不会有线程安全问题，没想到线程重用导致数据串了。请务必记得，在业务逻辑结束之前清理 ThreadLocal 中的数据。 + +二是，误以为使用了并发工具就可以解决一切线程安全问题，期望通过把线程不安全的类替换为线程安全的类来一键解决问题。比如，认为使用了 ConcurrentHashMap 就可以解决线程安全问题，没对复合逻辑加锁导致业务逻辑错误。如果你希望在一整段业务逻辑中，对容器的操作都保持整体一致性的话，需要加锁处理。 + +三是，没有充分了解并发工具的特性，还是按照老方式使用新工具导致无法发挥其性能。比如，使用了 ConcurrentHashMap，但没有充分利用其提供的基于 CAS 安全的方法，还是使用锁的方式来实现逻辑。你可以阅读一下ConcurrentHashMap 的文档，看一下相关原子性操作 API 是否可以满足业务需求，如果可以则优先考虑使用。 + +四是，没有了解清楚工具的适用场景，在不合适的场景下使用了错误的工具导致性能更差。比如，没有理解 CopyOnWriteArrayList 的适用场景，把它用在了读写均衡或者大量写操作的场景下，导致性能问题。对于这种场景，你可以考虑是用普通的 List。 + +其实，这四类坑之所以容易踩到，原因可以归结为，我们在使用并发工具的时候，并没有充分理解其可能存在的问题、适用场景等。所以最后，我还要和你分享两点建议： + + +一定要认真阅读官方文档（比如 Oracle JDK 文档）。充分阅读官方文档，理解工具的适用场景及其 API 的用法，并做一些小实验。了解之后再去使用，就可以避免大部分坑。 + +如果你的代码运行在多线程环境下，那么就会有并发问题，并发问题不那么容易重现，可能需要使用压力测试模拟并发场景，来发现其中的 Bug 或性能问题。 + + +今天用到的代码，我都放在了GitHub上，你可以点击这个链接查看。 + +思考与讨论 + + +今天我们多次用到了 ThreadLocalRandom，你觉得是否可以把它的实例设置到静态变量中，在多线程情况下重用呢？ + +ConcurrentHashMap 还提供了 putIfAbsent 方法，你能否通过查阅JDK文档，说说 computeIfAbsent 和 putIfAbsent 方法的区别？ + + +你在使用并发工具时，还遇到过其他坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/02代码加锁：不要让“锁”事成为烦心事.md b/专栏/Java业务开发常见错误100例/02代码加锁：不要让“锁”事成为烦心事.md new file mode 100644 index 0000000..4383cc0 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/02代码加锁：不要让“锁”事成为烦心事.md @@ -0,0 +1,352 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 02 代码加锁：不要让“锁”事成为烦心事 + 在上一讲中，我与你介绍了使用并发容器等工具解决线程安全的误区。今天，我们来看看解决线程安全问题的另一种重要手段——锁，在使用上比较容易犯哪些错。 + +我先和你分享一个有趣的案例吧。有一天，一位同学在群里说“见鬼了，疑似遇到了一个 JVM 的 Bug”，我们都很好奇是什么 Bug。 + +于是，他贴出了这样一段代码：在一个类里有两个 int 类型的字段 a 和 b，有一个 add 方法循环 1 万次对 a 和 b 进行 ++ 操作，有另一个 compare 方法，同样循环 1 万次判断 a 是否小于 b，条件成立就打印 a 和 b 的值，并判断 a>b 是否成立。 + +@Slf4j +public class Interesting { + volatile int a = 1; + volatile int b = 1; + public void add() { + log.info("add start"); + for (int i = 0; i < 10000; i++) { + a++; + b++; + } + log.info("add done"); + } + public void compare() { + log.info("compare start"); + for (int i = 0; i < 10000; i++) { + //a始终等于b吗？ + if (a < b) { + log.info("a:{},b:{},{}", a, b, a > b); + //最后的a>b应该始终是false吗？ + } + } + log.info("compare done"); + } +} + + +他起了两个线程来分别执行 add 和 compare 方法： + +Interesting interesting = new Interesting(); +new Thread(() -> interesting.add()).start(); +new Thread(() -> interesting.compare()).start(); + + +按道理，a 和 b 同样进行累加操作，应该始终相等，compare 中的第一次判断应该始终不会成立，不会输出任何日志。但，执行代码后发现不但输出了日志，而且更诡异的是，compare 方法在判断 ab 也成立： + + + +群里一位同学看到这个问题笑了，说：“这哪是 JVM 的 Bug，分明是线程安全问题嘛。很明显，你这是在操作两个字段 a 和 b，有线程安全问题，应该为 add 方法加上锁，确保 a 和 b 的 ++ 是原子性的，就不会错乱了。”随后，他为 add 方法加上了锁： + +public synchronized void add() + + +但，加锁后问题并没有解决。 + +我们来仔细想一下，为什么锁可以解决线程安全问题呢。因为只有一个线程可以拿到锁，所以加锁后的代码中的资源操作是线程安全的。但是，这个案例中的 add 方法始终只有一个线程在操作，显然只为 add 方法加锁是没用的。 + +之所以出现这种错乱，是因为两个线程是交错执行 add 和 compare 方法中的业务逻辑，而且这些业务逻辑不是原子性的：a++ 和 b++ 操作中可以穿插在 compare 方法的比较代码中；更需要注意的是，a 这种比较操作在字节码层面是加载 a、加载 b 和比较三步，代码虽然是一行但也不是原子性的。 + +所以，正确的做法应该是，为 add 和 compare 都加上方法锁，确保 add 方法执行时，compare 无法读取 a 和 b： + +public synchronized void add() +public synchronized void compare() + + +所以，使用锁解决问题之前一定要理清楚，我们要保护的是什么逻辑，多线程执行的情况又是怎样的。 + +加锁前要清楚锁和被保护的对象是不是一个层面的 + +除了没有分析清线程、业务逻辑和锁三者之间的关系随意添加无效的方法锁外，还有一种比较常见的错误是，没有理清楚锁和要保护的对象是否是一个层面的。 + +我们知道静态字段属于类，类级别的锁才能保护；而非静态字段属于类实例，实例级别的锁就可以保护。 + +先看看这段代码有什么问题：在类 Data 中定义了一个静态的 int 字段 counter 和一个非静态的 wrong 方法，实现 counter 字段的累加操作。 + +class Data { + @Getter + private static int counter = 0; + + public static int reset() { + counter = 0; + return counter; + } + public synchronized void wrong() { + counter++; + } +} + + +写一段代码测试下： + +@GetMapping("wrong") +public int wrong(@RequestParam(value = "count", defaultValue = "1000000") int count) { + Data.reset(); + //多线程循环一定次数调用Data类不同实例的wrong方法 + IntStream.rangeClosed(1, count).parallel().forEach(i -> new Data().wrong()); + return Data.getCounter(); +} + + +因为默认运行 100 万次，所以执行后应该输出 100 万，但页面输出的是 639242： + + + +我们来分析下为什么会出现这个问题吧。 + +在非静态的 wrong 方法上加锁，只能确保多个线程无法执行同一个实例的 wrong 方法，却不能保证不会执行不同实例的 wrong 方法。而静态的 counter 在多个实例中共享，所以必然会出现线程安全问题。 + +理清思路后，修正方法就很清晰了：同样在类中定义一个 Object 类型的静态字段，在操作 counter 之前对这个字段加锁。 + +class Data { + @Getter + private static int counter = 0; + private static Object locker = new Object(); + public void right() { + synchronized (locker) { + counter++; + } + } +} + + +你可能要问了，把 wrong 方法定义为静态不就可以了，这个时候锁是类级别的。可以是可以，但我们不可能为了解决线程安全问题改变代码结构，把实例方法改为静态方法。 + +感兴趣的同学还可以从字节码以及 JVM 的层面继续探索一下，代码块级别的 synchronized 和方法上标记 synchronized 关键字，在实现上有什么区别。 + +加锁要考虑锁的粒度和场景问题 + +在方法上加 synchronized 关键字实现加锁确实简单，也因此我曾看到一些业务代码中几乎所有方法都加了 synchronized，但这种滥用 synchronized 的做法： + + +一是，没必要。通常情况下 60% 的业务代码是三层架构，数据经过无状态的 Controller、Service、Repository 流转到数据库，没必要使用 synchronized 来保护什么数据。 + +二是，可能会极大地降低性能。使用 Spring 框架时，默认情况下 Controller、Service、Repository 是单例的，加上 synchronized 会导致整个程序几乎就只能支持单线程，造成极大的性能问题。 + + +即使我们确实有一些共享资源需要保护，也要尽可能降低锁的粒度，仅对必要的代码块甚至是需要保护的资源本身加锁。 + +比如，在业务代码中，有一个 ArrayList 因为会被多个线程操作而需要保护，又有一段比较耗时的操作（代码中的 slow 方法）不涉及线程安全问题，应该如何加锁呢？ + +错误的做法是，给整段业务逻辑加锁，把 slow 方法和操作 ArrayList 的代码同时纳入 synchronized 代码块；更合适的做法是，把加锁的粒度降到最低，只在操作 ArrayList 的时候给这个 ArrayList 加锁。 + +private List data = new ArrayList<>(); +//不涉及共享资源的慢方法 +private void slow() { + try { + TimeUnit.MILLISECONDS.sleep(10); + } catch (InterruptedException e) { + } +} +//错误的加锁方法 +@GetMapping("wrong") +public int wrong() { + long begin = System.currentTimeMillis(); + IntStream.rangeClosed(1, 1000).parallel().forEach(i -> { + //加锁粒度太粗了 + synchronized (this) { + slow(); + data.add(i); + } + }); + log.info("took:{}", System.currentTimeMillis() - begin); + return data.size(); +} +//正确的加锁方法 +@GetMapping("right") +public int right() { + long begin = System.currentTimeMillis(); + IntStream.rangeClosed(1, 1000).parallel().forEach(i -> { + slow(); + //只对List加锁 + synchronized (data) { + data.add(i); + } + }); + log.info("took:{}", System.currentTimeMillis() - begin); + return data.size(); +} + + +执行这段代码，同样是 1000 次业务操作，正确加锁的版本耗时 1.4 秒，而对整个业务逻辑加锁的话耗时 11 秒。 + + + +如果精细化考虑了锁应用范围后，性能还无法满足需求的话，我们就要考虑另一个维度的粒度问题了，即：区分读写场景以及资源的访问冲突，考虑使用悲观方式的锁还是乐观方式的锁。 + +一般业务代码中，很少需要进一步考虑这两种更细粒度的锁，所以我只和你分享几个大概的结论，你可以根据自己的需求来考虑是否有必要进一步优化： + + +对于读写比例差异明显的场景，考虑使用 ReentrantReadWriteLock 细化区分读写锁，来提高性能。 + +如果你的 JDK 版本高于 1.8、共享资源的冲突概率也没那么大的话，考虑使用 StampedLock 的乐观读的特性，进一步提高性能。 + +JDK 里 ReentrantLock 和 ReentrantReadWriteLock 都提供了公平锁的版本，在没有明确需求的情况下不要轻易开启公平锁特性，在任务很轻的情况下开启公平锁可能会让性能下降上百倍。 + + +多把锁要小心死锁问题 + +刚才我们聊到锁的粒度够用就好，这就意味着我们的程序逻辑中有时会存在一些细粒度的锁。但一个业务逻辑如果涉及多把锁，容易产生死锁问题。 + +之前我遇到过这样一个案例：下单操作需要锁定订单中多个商品的库存，拿到所有商品的锁之后进行下单扣减库存操作，全部操作完成之后释放所有的锁。代码上线后发现，下单失败概率很高，失败后需要用户重新下单，极大影响了用户体验，还影响到了销量。 + +经排查发现是死锁引起的问题，背后原因是扣减库存的顺序不同，导致并发的情况下多个线程可能相互持有部分商品的锁，又等待其他线程释放另一部分商品的锁，于是出现了死锁问题。 + +接下来，我们剖析一下核心的业务代码。 + +首先，定义一个商品类型，包含商品名、库存剩余和商品的库存锁三个属性，每一种商品默认库存 1000 个；然后，初始化 10 个这样的商品对象来模拟商品清单： + +@Data +@RequiredArgsConstructor +static class Item { + final String name; //商品名 + int remaining = 1000; //库存剩余 + @ToString.Exclude //ToString不包含这个字段 + ReentrantLock lock = new ReentrantLock(); +} + + +随后，写一个方法模拟在购物车进行商品选购，每次从商品清单（items 字段）中随机选购三个商品（为了逻辑简单，我们不考虑每次选购多个同类商品的逻辑，购物车中不体现商品数量）： + +private List createCart() { + return IntStream.rangeClosed(1, 3) + .mapToObj(i -> "item" + ThreadLocalRandom.current().nextInt(items.size())) + .map(name -> items.get(name)).collect(Collectors.toList()); +} + + +下单代码如下：先声明一个 List 来保存所有获得的锁，然后遍历购物车中的商品依次尝试获得商品的锁，最长等待 10 秒，获得全部锁之后再扣减库存；如果有无法获得锁的情况则解锁之前获得的所有锁，返回 false 下单失败。 + +private boolean createOrder(List order) { + //存放所有获得的锁 + List locks = new ArrayList<>(); + for (Item item : order) { + try { + //获得锁10秒超时 + if (item.lock.tryLock(10, TimeUnit.SECONDS)) { + locks.add(item.lock); + } else { + locks.forEach(ReentrantLock::unlock); + return false; + } + } catch (InterruptedException e) { + } + } + //锁全部拿到之后执行扣减库存业务逻辑 + try { + order.forEach(item -> item.remaining--); + } finally { + locks.forEach(ReentrantLock::unlock); + } + return true; +} + + +我们写一段代码测试这个下单操作。模拟在多线程情况下进行 100 次创建购物车和下单操作，最后通过日志输出成功的下单次数、总剩余的商品个数、100 次下单耗时，以及下单完成后的商品库存明细： + +@GetMapping("wrong") +public long wrong() { + long begin = System.currentTimeMillis(); + //并发进行100次下单操作，统计成功次数 + long success = IntStream.rangeClosed(1, 100).parallel() + .mapToObj(i -> { + List cart = createCart(); + return createOrder(cart); + }) + .filter(result -> result) + .count(); + log.info("success:{} totalRemaining:{} took:{}ms items:{}", + success, + items.entrySet().stream().map(item -> item.getValue().remaining).reduce(0, Integer::sum), + System.currentTimeMillis() - begin, items); + return success; +} + + +运行程序，输出如下日志： + + + +可以看到，100 次下单操作成功了 65 次，10 种商品总计 10000 件，库存总计为 9805，消耗了 195 件符合预期（65 次下单成功，每次下单包含三件商品），总耗时 50 秒。 + +为什么会这样呢？ + +使用 JDK 自带的 VisualVM 工具来跟踪一下，重新执行方法后不久就可以看到，线程 Tab 中提示了死锁问题，根据提示点击右侧线程 Dump 按钮进行线程抓取操作： + + + +查看抓取出的线程栈，在页面中部可以看到如下日志： + + + +显然，是出现了死锁，线程 4 在等待的一个锁被线程 3 持有，线程 3 在等待的另一把锁被线程 4 持有。 + +那为什么会有死锁问题呢？ + +我们仔细回忆一下购物车添加商品的逻辑，随机添加了三种商品，假设一个购物车中的商品是 item1 和 item2，另一个购物车中的商品是 item2 和 item1，一个线程先获取到了 item1 的锁，同时另一个线程获取到了 item2 的锁，然后两个线程接下来要分别获取 item2 和 item1 的锁，这个时候锁已经被对方获取了，只能相互等待一直到 10 秒超时。 + +其实，避免死锁的方案很简单，为购物车中的商品排一下序，让所有的线程一定是先获取 item1 的锁然后获取 item2 的锁，就不会有问题了。所以，我只需要修改一行代码，对 createCart 获得的购物车按照商品名进行排序即可： + +@GetMapping("right") +public long right() { + .... + long success = IntStream.rangeClosed(1, 100).parallel() + .mapToObj(i -> { + List cart = createCart().stream() + .sorted(Comparator.comparing(Item::getName)) + .collect(Collectors.toList()); + return createOrder(cart); + }) + .filter(result -> result) + .count(); + ... + return success; +} + + +测试一下 right 方法，不管执行多少次都是 100 次成功下单，而且性能相当高，达到了 3000 以上的 TPS： + + + +这个案例中，虽然产生了死锁问题，但因为尝试获取锁的操作并不是无限阻塞的，所以没有造成永久死锁，之后的改进就是避免循环等待，通过对购物车的商品进行排序来实现有顺序的加锁，避免循环等待。 + +重点回顾 + +我们一起总结回顾下，使用锁来解决多线程情况下线程安全问题的坑吧。 + +第一，使用 synchronized 加锁虽然简单，但我们首先要弄清楚共享资源是类还是实例级别的、会被哪些线程操作，synchronized 关联的锁对象或方法又是什么范围的。 + +第二，加锁尽可能要考虑粒度和场景，锁保护的代码意味着无法进行多线程操作。对于 Web 类型的天然多线程项目，对方法进行大范围加锁会显著降级并发能力，要考虑尽可能地只为必要的代码块加锁，降低锁的粒度；而对于要求超高性能的业务，还要细化考虑锁的读写场景，以及悲观优先还是乐观优先，尽可能针对明确场景精细化加锁方案，可以在适当的场景下考虑使用 ReentrantReadWriteLock、StampedLock 等高级的锁工具类。 + +第三，业务逻辑中有多把锁时要考虑死锁问题，通常的规避方案是，避免无限等待和循环等待。 + +此外，如果业务逻辑中锁的实现比较复杂的话，要仔细看看加锁和释放是否配对，是否有遗漏释放或重复释放的可能性；并且对于分布式锁要考虑锁自动超时释放了，而业务逻辑却还在进行的情况下，如果别的线线程或进程拿到了相同的锁，可能会导致重复执行。 + +为演示方便，今天的案例是在 Controller 的逻辑中开新的线程或使用线程池进行并发模拟，我们当然可以意识到哪些对象是并发操作的。但对于 Web 应用程序的天然多线程场景，你可能更容易忽略这点，并且也可能因为误用锁降低应用整体的吞吐量。Argentina + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + + +本文开头的例子里，变量 a、b 都使用了 volatile 关键字，你知道原因吗？我之前遇到过这样一个坑：我们开启了一个线程无限循环来跑一些任务，有一个 bool 类型的变量来控制循环的退出，默认为 true 代表执行，一段时间后主线程将这个变量设置为了 false。如果这个变量不是 volatile 修饰的，子线程可以退出吗？你能否解释其中的原因呢？ + +文末我们又提了两个坑，一是加锁和释放没有配对的问题，二是锁自动释放导致的重复逻辑执行的问题。你有什么方法来发现和解决这两种问题吗？ + + +在使用锁的过程中，你还遇到过其他坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/03线程池：业务代码最常用也最容易犯错的组件.md b/专栏/Java业务开发常见错误100例/03线程池：业务代码最常用也最容易犯错的组件.md new file mode 100644 index 0000000..99b73de --- /dev/null +++ b/专栏/Java业务开发常见错误100例/03线程池：业务代码最常用也最容易犯错的组件.md @@ -0,0 +1,449 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 03 线程池：业务代码最常用也最容易犯错的组件 + 今天，我来讲讲使用线程池需要注意的一些问题。 + +在程序中，我们会用各种池化技术来缓存创建昂贵的对象，比如线程池、连接池、内存池。一般是预先创建一些对象放入池中，使用的时候直接取出使用，用完归还以便复用，还会通过一定的策略调整池中缓存对象的数量，实现池的动态伸缩。 + +由于线程的创建比较昂贵，随意、没有控制地创建大量线程会造成性能问题，因此短平快的任务一般考虑使用线程池来处理，而不是直接创建线程。 + +今天，我们就针对线程池这个话题展开讨论，通过三个生产事故，来看看使用线程池应该注意些什么。 + +线程池的声明需要手动进行 + +Java 中的 Executors 类定义了一些快捷的工具方法，来帮助我们快速创建线程池。《阿里巴巴 Java 开发手册》中提到，禁止使用这些方法来创建线程池，而应该手动 new ThreadPoolExecutor 来创建线程池。这一条规则的背后，是大量血淋淋的生产事故，最典型的就是 newFixedThreadPool 和 newCachedThreadPool，可能因为资源耗尽导致 OOM 问题。 + +首先，我们来看一下 newFixedThreadPool 为什么可能会出现 OOM 的问题。 + +我们写一段测试代码，来初始化一个单线程的 FixedThreadPool，循环 1 亿次向线程池提交任务，每个任务都会创建一个比较大的字符串然后休眠一小时： + +@GetMapping("oom1") +public void oom1() throws InterruptedException { + + ThreadPoolExecutor threadPool = (ThreadPoolExecutor) Executors.newFixedThreadPool(1); + + //打印线程池的信息，稍后我会解释这段代码 + printStats(threadPool); + + for (int i = 0; i < 100000000; i++) { + + threadPool.execute(() -> { + String payload = IntStream.rangeClosed(1, 1000000) + .mapToObj(__ -> "a") + .collect(Collectors.joining("")) + UUID.randomUUID().toString(); + try { + TimeUnit.HOURS.sleep(1); + } catch (InterruptedException e) { + } + + log.info(payload); + + }); + } + + threadPool.shutdown(); + threadPool.awaitTermination(1, TimeUnit.HOURS); +} + + +执行程序后不久，日志中就出现了如下 OOM： + +Exception in thread "http-nio-45678-ClientPoller" java.lang.OutOfMemoryError: GC overhead limit exceeded + + +翻看 newFixedThreadPool 方法的源码不难发现，线程池的工作队列直接 new 了一个 LinkedBlockingQueue，而默认构造方法的 LinkedBlockingQueue 是一个 Integer.MAX_VALUE 长度的队列，可以认为是无界的： + +public static ExecutorService newFixedThreadPool(int nThreads) { + + return new ThreadPoolExecutor(nThreads, nThreads, + 0L, TimeUnit.MILLISECONDS, + new LinkedBlockingQueue()); + +} + +public class LinkedBlockingQueue extends AbstractQueue + implements BlockingQueue, java.io.Serializable { + + ... + + + + /** + * Creates a {@code LinkedBlockingQueue} with a capacity of + * {@link Integer#MAX_VALUE}. + */ + + public LinkedBlockingQueue() { + this(Integer.MAX_VALUE); + } +... +} + + +虽然使用 newFixedThreadPool 可以把工作线程控制在固定的数量上，但任务队列是无界的。如果任务较多并且执行较慢的话，队列可能会快速积压，撑爆内存导致 OOM。 + +我们再把刚才的例子稍微改一下，改为使用 newCachedThreadPool 方法来获得线程池。程序运行不久后，同样看到了如下 OOM 异常： + +[11:30:30.487] [http-nio-45678-exec-1] [ERROR] [.a.c.c.C.[.[.[/].[dispatcherServlet]:175 ] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: unable to create new native thread] with root cause + +java.lang.OutOfMemoryError: unable to create new native thread + + +从日志中可以看到，这次 OOM 的原因是无法创建线程，翻看 newCachedThreadPool 的源码可以看到，这种线程池的最大线程数是 Integer.MAX_VALUE，可以认为是没有上限的，而其工作队列 SynchronousQueue 是一个没有存储空间的阻塞队列。这意味着，只要有请求到来，就必须找到一条工作线程来处理，如果当前没有空闲的线程就再创建一条新的。 + +由于我们的任务需要 1 小时才能执行完成，大量的任务进来后会创建大量的线程。我们知道线程是需要分配一定的内存空间作为线程栈的，比如 1MB，因此无限制创建线程必然会导致 OOM： + +public static ExecutorService newCachedThreadPool() { + + return new ThreadPoolExecutor(0, Integer.MAX_VALUE, + 60L, TimeUnit.SECONDS, + new SynchronousQueue()); + + +其实，大部分 Java 开发同学知道这两种线程池的特性，只是抱有侥幸心理，觉得只是使用线程池做一些轻量级的任务，不可能造成队列积压或开启大量线程。 + +但，现实往往是残酷的。我之前就遇到过这么一个事故：用户注册后，我们调用一个外部服务去发送短信，发送短信接口正常时可以在 100 毫秒内响应，TPS 100 的注册量，CachedThreadPool 能稳定在占用 10 个左右线程的情况下满足需求。在某个时间点，外部短信服务不可用了，我们调用这个服务的超时又特别长，比如 1 分钟，1 分钟可能就进来了 6000 用户，产生 6000 个发送短信的任务，需要 6000 个线程，没多久就因为无法创建线程导致了 OOM，整个应用程序崩溃。 + +因此，我同样不建议使用 Executors 提供的两种快捷的线程池，原因如下： + +我们需要根据自己的场景、并发情况来评估线程池的几个核心参数，包括核心线程数、最大线程数、线程回收策略、工作队列的类型，以及拒绝策略，确保线程池的工作行为符合需求，一般都需要设置有界的工作队列和可控的线程数。 + +任何时候，都应该为自定义线程池指定有意义的名称，以方便排查问题。当出现线程数量暴增、线程死锁、线程占用大量 CPU、线程执行出现异常等问题时，我们往往会抓取线程栈。此时，有意义的线程名称，就可以方便我们定位问题。 + +除了建议手动声明线程池以外，我还建议用一些监控手段来观察线程池的状态。线程池这个组件往往会表现得任劳任怨、默默无闻，除非是出现了拒绝策略，否则压力再大都不会抛出一个异常。如果我们能提前观察到线程池队列的积压，或者线程数量的快速膨胀，往往可以提早发现并解决问题。 + +线程池线程管理策略详解 + +在之前的 Demo 中，我们用一个 printStats 方法实现了最简陋的监控，每秒输出一次线程池的基本内部信息，包括线程数、活跃线程数、完成了多少任务，以及队列中还有多少积压任务等信息： + +private void printStats(ThreadPoolExecutor threadPool) { + + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> { + + log.info("========================="); + log.info("Pool Size: {}", threadPool.getPoolSize()); + log.info("Active Threads: {}", threadPool.getActiveCount()); + log.info("Number of Tasks Completed: {}", threadPool.getCompletedTaskCount()); + log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size()); + log.info("========================="); + + }, 0, 1, TimeUnit.SECONDS); + +} + + +接下来，我们就利用这个方法来观察一下线程池的基本特性吧。 + +首先，自定义一个线程池。这个线程池具有 2 个核心线程、5 个最大线程、使用容量为 10 的 ArrayBlockingQueue 阻塞队列作为工作队列，使用默认的 AbortPolicy 拒绝策略，也就是任务添加到线程池失败会抛出 RejectedExecutionException。此外，我们借助了 Jodd 类库的 ThreadFactoryBuilder 方法来构造一个线程工厂，实现线程池线程的自定义命名。 + +然后，我们写一段测试代码来观察线程池管理线程的策略。测试代码的逻辑为，每次间隔 1 秒向线程池提交任务，循环 20 次，每个任务需要 10 秒才能执行完成，代码如下： + +@GetMapping("right") +public int right() throws InterruptedException { + + //使用一个计数器跟踪完成的任务数 + AtomicInteger atomicInteger = new AtomicInteger(); + + //创建一个具有2个核心线程、5个最大线程，使用容量为10的ArrayBlockingQueue阻塞队列作为工作队列的线程池，使用默认的AbortPolicy拒绝策略 + ThreadPoolExecutor threadPool = new ThreadPoolExecutor( + 2, 5, + 5, TimeUnit.SECONDS, + new ArrayBlockingQueue<>(10), + new ThreadFactoryBuilder().setNameFormat("demo-threadpool-%d").get(), + new ThreadPoolExecutor.AbortPolicy()); + + printStats(threadPool); + + //每隔1秒提交一次，一共提交20次任务 + IntStream.rangeClosed(1, 20).forEach(i -> { + + try { + TimeUnit.SECONDS.sleep(1); + + } catch (InterruptedException e) { + e.printStackTrace(); + + } + + int id = atomicInteger.incrementAndGet(); + + try { + threadPool.submit(() -> { + log.info("{} started", id); + + //每个任务耗时10秒 + try { + TimeUnit.SECONDS.sleep(10); + } catch (InterruptedException e) { + + } + log.info("{} finished", id); + }); + + } catch (Exception ex) { + + //提交出现异常的话，打印出错信息并为计数器减一 + log.error("error submitting task {}", id, ex); + atomicInteger.decrementAndGet(); + + } + + }); + + TimeUnit.SECONDS.sleep(60); + + return atomicInteger.intValue(); + +} + + +60 秒后页面输出了 17，有 3 次提交失败了： + + + +并且日志中也出现了 3 次类似的错误信息： + +[14:24:52.879] [http-nio-45678-exec-1] [ERROR] [.t.c.t.demo1.ThreadPoolOOMController:103 ] - error submitting task 18 + +java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@163a2dec rejected from java.util.concurrent.ThreadPoolExecutor@18061ad2[Running, pool size = 5, active threads = 5, queued tasks = 10, completed tasks = 2] + + +我们把 printStats 方法打印出的日志绘制成图表，得出如下曲线： + + + +至此，我们可以总结出线程池默认的工作行为： + +不会初始化 corePoolSize 个线程，有任务来了才创建工作线程； + +当核心线程满了之后不会立即扩容线程池，而是把任务堆积到工作队列中； + +当工作队列满了后扩容线程池，一直到线程个数达到 maximumPoolSize 为止； + +如果队列已满且达到了最大线程后还有任务进来，按照拒绝策略处理； + +当线程数大于核心线程数时，线程等待 keepAliveTime 后还是没有任务需要处理的话，收缩线程到核心线程数。 + +了解这个策略，有助于我们根据实际的容量规划需求，为线程池设置合适的初始化参数。当然，我们也可以通过一些手段来改变这些默认工作行为，比如： + +声明线程池后立即调用 prestartAllCoreThreads 方法，来启动所有核心线程； + +传入 true 给 allowCoreThreadTimeOut 方法，来让线程池在空闲的时候同样回收核心线程。 + +不知道你有没有想过：Java 线程池是先用工作队列来存放来不及处理的任务，满了之后再扩容线程池。当我们的工作队列设置得很大时，最大线程数这个参数显得没有意义，因为队列很难满，或者到满的时候再去扩容线程池已经于事无补了。 + +那么，我们有没有办法让线程池更激进一点，优先开启更多的线程，而把队列当成一个后备方案呢？比如我们这个例子，任务执行得很慢，需要 10 秒，如果线程池可以优先扩容到 5 个最大线程，那么这些任务最终都可以完成，而不会因为线程池扩容过晚导致慢任务来不及处理。 + +限于篇幅，这里我只给你一个大致思路： + +由于线程池在工作队列满了无法入队的情况下会扩容线程池，那么我们是否可以重写队列的 offer 方法，造成这个队列已满的假象呢？ + +由于我们 Hack 了队列，在达到了最大线程后势必会触发拒绝策略，那么能否实现一个自定义的拒绝策略处理程序，这个时候再把任务真正插入队列呢？ + +接下来，就请你动手试试看如何实现这样一个“弹性”线程池吧。Tomcat 线程池也实现了类似的效果，可供你借鉴。 + +务必确认清楚线程池本身是不是复用的 + +不久之前我遇到了这样一个事故：某项目生产环境时不时有报警提示线程数过多，超过 2000 个，收到报警后查看监控发现，瞬时线程数比较多但过一会儿又会降下来，线程数抖动很厉害，而应用的访问量变化不大。 + +为了定位问题，我们在线程数比较高的时候进行线程栈抓取，抓取后发现内存中有 1000 多个自定义线程池。一般而言，线程池肯定是复用的，有 5 个以内的线程池都可以认为正常，而 1000 多个线程池肯定不正常。 + +在项目代码里，我们没有搜到声明线程池的地方，搜索 execute 关键字后定位到，原来是业务代码调用了一个类库来获得线程池，类似如下的业务代码：调用 ThreadPoolHelper 的 getThreadPool 方法来获得线程池，然后提交数个任务到线程池处理，看不出什么异常。 + +@GetMapping("wrong") +public String wrong() throws InterruptedException { + + ThreadPoolExecutor threadPool = ThreadPoolHelper.getThreadPool(); + + IntStream.rangeClosed(1, 10).forEach(i -> { + threadPool.execute(() -> { + ... + try { + TimeUnit.SECONDS.sleep(1); + } catch (InterruptedException e) { + + } + }); + }); + + return "OK"; +} + + +但是，来到 ThreadPoolHelper 的实现让人大跌眼镜，getThreadPool 方法居然是每次都使用 Executors.newCachedThreadPool 来创建一个线程池。 + +class ThreadPoolHelper { + + public static ThreadPoolExecutor getThreadPool() { + + //线程池没有复用 + return (ThreadPoolExecutor) Executors.newCachedThreadPool(); + + } + +} + + +通过上一小节的学习，我们可以想到 newCachedThreadPool 会在需要时创建必要多的线程，业务代码的一次业务操作会向线程池提交多个慢任务，这样执行一次业务操作就会开启多个线程。如果业务操作并发量较大的话，的确有可能一下子开启几千个线程。 + +那，为什么我们能在监控中看到线程数量会下降，而不会撑爆内存呢？ + +回到 newCachedThreadPool 的定义就会发现，它的核心线程数是 0，而 keepAliveTime 是 60 秒，也就是在 60 秒之后所有的线程都是可以回收的。好吧，就因为这个特性，我们的业务程序死得没太难看。 + +要修复这个 Bug 也很简单，使用一个静态字段来存放线程池的引用，返回线程池的代码直接返回这个静态字段即可。这里一定要记得我们的最佳实践，手动创建线程池。修复后的 ThreadPoolHelper 类如下： + +class ThreadPoolHelper { + + private static ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor( + 10, 50, + 2, TimeUnit.SECONDS, + new ArrayBlockingQueue<>(1000), + new ThreadFactoryBuilder().setNameFormat("demo-threadpool-%d").get()); + + public static ThreadPoolExecutor getRightThreadPool() { + + return threadPoolExecutor; + } + +} + + +需要仔细斟酌线程池的混用策略 + +线程池的意义在于复用，那这是不是意味着程序应该始终使用一个线程池呢？ + +当然不是。通过第一小节的学习我们知道，要根据任务的“轻重缓急”来指定线程池的核心参数，包括线程数、回收策略和任务队列： + +对于执行比较慢、数量不大的 IO 任务，或许要考虑更多的线程数，而不需要太大的队列。 + +而对于吞吐量较大的计算型任务，线程数量不宜过多，可以是 CPU 核数或核数 *2（理由是，线程一定调度到某个 CPU 进行执行，如果任务本身是 CPU 绑定的任务，那么过多的线程只会增加线程切换的开销，并不能提升吞吐量），但可能需要较长的队列来做缓冲。 + +之前我也遇到过这么一个问题，业务代码使用了线程池异步处理一些内存中的数据，但通过监控发现处理得非常慢，整个处理过程都是内存中的计算不涉及 IO 操作，也需要数秒的处理时间，应用程序 CPU 占用也不是特别高，有点不可思议。 + +经排查发现，业务代码使用的线程池，还被一个后台的文件批处理任务用到了。 + +或许是够用就好的原则，这个线程池只有 2 个核心线程，最大线程也是 2，使用了容量为 100 的 ArrayBlockingQueue 作为工作队列，使用了 CallerRunsPolicy 拒绝策略： + +private static ThreadPoolExecutor threadPool = new ThreadPoolExecutor( + 2, 2, + 1, TimeUnit.HOURS, + new ArrayBlockingQueue<>(100), + new ThreadFactoryBuilder().setNameFormat("batchfileprocess-threadpool-%d").get(), + new ThreadPoolExecutor.CallerRunsPolicy()); + + +这里，我们模拟一下文件批处理的代码，在程序启动后通过一个线程开启死循环逻辑，不断向线程池提交任务，任务的逻辑是向一个文件中写入大量的数据： + +@PostConstruct +public void init() { + + printStats(threadPool); + new Thread(() -> { + + //模拟需要写入的大量数据 + String payload = IntStream.rangeClosed(1, 1_000_000) + .mapToObj(__ -> "a") + .collect(Collectors.joining("")); + + while (true) { + threadPool.execute(() -> { + try { + + //每次都是创建并写入相同的数据到相同的文件 + Files.write(Paths.get("demo.txt"), Collections.singletonList(LocalTime.now().toString() + ":" + payload), UTF_8, CREATE, TRUNCATE_EXISTING); + + } catch (IOException e) { + e.printStackTrace(); + + } + log.info("batch file processing done"); + }); + } + }).start(); + +} + + +可以想象到，这个线程池中的 2 个线程任务是相当重的。通过 printStats 方法打印出的日志，我们观察下线程池的负担： + + + +可以看到，线程池的 2 个线程始终处于活跃状态，队列也基本处于打满状态。因为开启了 CallerRunsPolicy 拒绝处理策略，所以当线程满载队列也满的情况下，任务会在提交任务的线程，或者说调用 execute 方法的线程执行，也就是说不能认为提交到线程池的任务就一定是异步处理的。如果使用了 CallerRunsPolicy 策略，那么有可能异步任务变为同步执行。从日志的第四行也可以看到这点。这也是这个拒绝策略比较特别的原因。 + +不知道写代码的同学为什么设置这个策略，或许是测试时发现线程池因为任务处理不过来出现了异常，而又不希望线程池丢弃任务，所以最终选择了这样的拒绝策略。不管怎样，这些日志足以说明线程池是饱和状态。 + +可以想象到，业务代码复用这样的线程池来做内存计算，命运一定是悲惨的。我们写一段代码测试下，向线程池提交一个简单的任务，这个任务只是休眠 10 毫秒没有其他逻辑： + +private Callable calcTask() { + + return () -> { + TimeUnit.MILLISECONDS.sleep(10); + return 1; + + }; +} + +@GetMapping("wrong") +public int wrong() throws ExecutionException, InterruptedException { + + return threadPool.submit(calcTask()).get(); +} + + +我们使用 wrk 工具对这个接口进行一个简单的压测，可以看到 TPS 为 75，性能的确非常差。 + + + +细想一下，问题其实没有这么简单。因为原来执行 IO 任务的线程池使用的是 CallerRunsPolicy 策略，所以直接使用这个线程池进行异步计算的话，当线程池饱和的时候，计算任务会在执行 Web 请求的 Tomcat 线程执行，这时就会进一步影响到其他同步处理的线程，甚至造成整个应用程序崩溃。 + +解决方案很简单，使用独立的线程池来做这样的“计算任务”即可。计算任务打了双引号，是因为我们的模拟代码执行的是休眠操作，并不属于 CPU 绑定的操作，更类似 IO 绑定的操作，如果线程池线程数设置太小会限制吞吐能力： + +private static ThreadPoolExecutor asyncCalcThreadPool = new ThreadPoolExecutor( + 200, 200, + 1, TimeUnit.HOURS, + new ArrayBlockingQueue<>(1000), + new ThreadFactoryBuilder().setNameFormat("asynccalc-threadpool-%d").get()); + +@GetMapping("right") +public int right() throws ExecutionException, InterruptedException { + return asyncCalcThreadPool.submit(calcTask()).get(); + +} + + +使用单独的线程池改造代码后再来测试一下性能，TPS 提高到了 1727： + + + +可以看到，盲目复用线程池混用线程的问题在于，别人定义的线程池属性不一定适合你的任务，而且混用会相互干扰。这就好比，我们往往会用虚拟化技术来实现资源的隔离，而不是让所有应用程序都直接使用物理机。 + +就线程池混用问题，我想再和你补充一个坑：Java 8 的 parallel stream 功能，可以让我们很方便地并行处理集合中的元素，其背后是共享同一个 ForkJoinPool，默认并行度是 CPU 核数 -1。对于 CPU 绑定的任务来说，使用这样的配置比较合适，但如果集合操作涉及同步 IO 操作的话（比如数据库操作、外部服务调用等），建议自定义一个 ForkJoinPool（或普通线程池）。你可以参考第一讲的相关 Demo。 + +重点回顾 + +线程池管理着线程，线程又属于宝贵的资源，有许多应用程序的性能问题都来自线程池的配置和使用不当。在今天的学习中，我通过三个和线程池相关的生产事故，和你分享了使用线程池的几个最佳实践。 + +第一，Executors 类提供的一些快捷声明线程池的方法虽然简单，但隐藏了线程池的参数细节。因此，使用线程池时，我们一定要根据场景和需求配置合理的线程数、任务队列、拒绝策略、线程回收策略，并对线程进行明确的命名方便排查问题。 + +第二，既然使用了线程池就需要确保线程池是在复用的，每次 new 一个线程池出来可能比不用线程池还糟糕。如果你没有直接声明线程池而是使用其他同学提供的类库来获得一个线程池，请务必查看源码，以确认线程池的实例化方式和配置是符合预期的。 + +第三，复用线程池不代表应用程序始终使用同一个线程池，我们应该根据任务的性质来选用不同的线程池。特别注意 IO 绑定的任务和 CPU 绑定的任务对于线程池属性的偏好，如果希望减少任务间的相互干扰，考虑按需使用隔离的线程池。 + +最后我想强调的是，线程池作为应用程序内部的核心组件往往缺乏监控（如果你使用类似 RabbitMQ 这样的 MQ 中间件，运维同学一般会帮我们做好中间件监控），往往到程序崩溃后才发现线程池的问题，很被动。在设计篇中我们会重新谈及这个问题及其解决方案。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在第一节中我们提到，或许一个激进创建线程的弹性线程池更符合我们的需求，你能给出相关的实现吗？实现后再测试一下，是否所有的任务都可以正常处理完成呢？ + +在第二节中，我们改进了 ThreadPoolHelper 使其能够返回复用的线程池。如果我们不小心每次都创建了这样一个自定义的线程池（10 核心线程，50 最大线程，2 秒回收的），反复执行测试接口线程，最终可以被回收吗？会出现 OOM 问题吗？ + +你还遇到过线程池相关的其他坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/04连接池：别让连接池帮了倒忙.md b/专栏/Java业务开发常见错误100例/04连接池：别让连接池帮了倒忙.md new file mode 100644 index 0000000..6508320 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/04连接池：别让连接池帮了倒忙.md @@ -0,0 +1,523 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 04 连接池：别让连接池帮了倒忙 + 今天，我们来聊聊使用连接池需要注意的问题。 + +在上一讲，我们学习了使用线程池需要注意的问题。今天，我再与你说说另一种很重要的池化技术，即连接池。 + +我先和你说说连接池的结构。连接池一般对外提供获得连接、归还连接的接口给客户端使用，并暴露最小空闲连接数、最大连接数等可配置参数，在内部则实现连接建立、连接心跳保持、连接管理、空闲连接回收、连接可用性检测等功能。连接池的结构示意图，如下所示： + + + +业务项目中经常会用到的连接池，主要是数据库连接池、Redis 连接池和 HTTP 连接池。所以，今天我就以这三种连接池为例，和你聊聊使用和配置连接池容易出错的地方。 + +注意鉴别客户端 SDK 是否基于连接池 + +在使用三方客户端进行网络通信时，我们首先要确定客户端 SDK 是否是基于连接池技术实现的。我们知道，TCP 是面向连接的基于字节流的协议： + +面向连接，意味着连接需要先创建再使用，创建连接的三次握手有一定开销； + +基于字节流，意味着字节是发送数据的最小单元，TCP 协议本身无法区分哪几个字节是完整的消息体，也无法感知是否有多个客户端在使用同一个 TCP 连接，TCP 只是一个读写数据的管道。 + +如果客户端 SDK 没有使用连接池，而直接是 TCP 连接，那么就需要考虑每次建立 TCP 连接的开销，并且因为 TCP 基于字节流，在多线程的情况下对同一连接进行复用，可能会产生线程安全问题。 + +我们先看一下涉及 TCP 连接的客户端 SDK，对外提供 API 的三种方式。在面对各种三方客户端的时候，只有先识别出其属于哪一种，才能理清楚使用方式。 + +连接池和连接分离的 API：有一个 XXXPool 类负责连接池实现，先从其获得连接 XXXConnection，然后用获得的连接进行服务端请求，完成后使用者需要归还连接。通常，XXXPool 是线程安全的，可以并发获取和归还连接，而 XXXConnection 是非线程安全的。对应到连接池的结构示意图中，XXXPool 就是右边连接池那个框，左边的客户端是我们自己的代码。 + +内部带有连接池的 API：对外提供一个 XXXClient 类，通过这个类可以直接进行服务端请求；这个类内部维护了连接池，SDK 使用者无需考虑连接的获取和归还问题。一般而言，XXXClient 是线程安全的。对应到连接池的结构示意图中，整个 API 就是蓝色框包裹的部分。 + +非连接池的 API：一般命名为 XXXConnection，以区分其是基于连接池还是单连接的，而不建议命名为 XXXClient 或直接是 XXX。直接连接方式的 API 基于单一连接，每次使用都需要创建和断开连接，性能一般，且通常不是线程安全的。对应到连接池的结构示意图中，这种形式相当于没有右边连接池那个框，客户端直接连接服务端创建连接。 + +虽然上面提到了 SDK 一般的命名习惯，但不排除有一些客户端特立独行，因此在使用三方 SDK 时，一定要先查看官方文档了解其最佳实践，或是在类似 Stackoverflow 的网站搜索 XXX threadsafe/singleton 字样看看大家的回复，也可以一层一层往下看源码，直到定位到原始 Socket 来判断 Socket 和客户端 API 的对应关系。 + +明确了 SDK 连接池的实现方式后，我们就大概知道了使用 SDK 的最佳实践： + +如果是分离方式，那么连接池本身一般是线程安全的，可以复用。每次使用需要从连接池获取连接，使用后归还，归还的工作由使用者负责。 + +如果是内置连接池，SDK 会负责连接的获取和归还，使用的时候直接复用客户端。 + +如果 SDK 没有实现连接池（大多数中间件、数据库的客户端 SDK 都会支持连接池），那通常不是线程安全的，而且短连接的方式性能不会很高，使用的时候需要考虑是否自己封装一个连接池。 + +接下来，我就以 Java 中用于操作 Redis 最常见的库 Jedis 为例，从源码角度分析下 Jedis 类到底属于哪种类型的 API，直接在多线程环境下复用一个连接会产生什么问题，以及如何用最佳实践来修复这个问题。 + +首先，向 Redis 初始化 2 组数据，Key=a、Value=1，Key=b、Value=2： + +@PostConstruct +public void init() { + + try (Jedis jedis = new Jedis("127.0.0.1", 6379)) { + Assert.isTrue("OK".equals(jedis.set("a", "1")), "set a = 1 return OK"); + Assert.isTrue("OK".equals(jedis.set("b", "2")), "set b = 2 return OK"); + } +} + + +然后，启动两个线程，共享操作同一个 Jedis 实例，每一个线程循环 1000 次，分别读取 Key 为 a 和 b 的 Value，判断是否分别为 1 和 2： + +Jedis jedis = new Jedis("127.0.0.1", 6379); + +new Thread(() -> { + for (int i = 0; i < 1000; i++) { + String result = jedis.get("a"); + if (!result.equals("1")) { + log.warn("Expect a to be 1 but found {}", result); + return; + } + } + +}).start(); + +new Thread(() -> { + for (int i = 0; i < 1000; i++) { + String result = jedis.get("b"); + if (!result.equals("2")) { + log.warn("Expect b to be 2 but found {}", result); + return; + } + } +}).start(); + +TimeUnit.SECONDS.sleep(5); + + +执行程序多次，可以看到日志中出现了各种奇怪的异常信息，有的是读取 Key 为 b 的 Value 读取到了 1，有的是流非正常结束，还有的是连接关闭异常： + +//错误1 +[14:56:19.069] [Thread-28] [WARN ] [.t.c.c.redis.JedisMisreuseController:45 ] - Expect b to be 2 but found 1 + +//错误2 +redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream. + at redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:202) + at redis.clients.jedis.util.RedisInputStream.readLine(RedisInputStream.java:50) + at redis.clients.jedis.Protocol.processError(Protocol.java:114) + at redis.clients.jedis.Protocol.process(Protocol.java:166) + at redis.clients.jedis.Protocol.read(Protocol.java:220) + at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:318) + at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:255) + at redis.clients.jedis.Connection.getBulkReply(Connection.java:245) + at redis.clients.jedis.Jedis.get(Jedis.java:181) + at org.geekbang.time.commonmistakes.connectionpool.redis.JedisMisreuseController.lambda$wrong$1(JedisMisreuseController.java:43) + at java.lang.Thread.run(Thread.java:748) + +//错误3 +java.io.IOException: Socket Closed + at java.net.AbstractPlainSocketImpl.getOutputStream(AbstractPlainSocketImpl.java:440) + at java.net.Socket$3.run(Socket.java:954) + at java.net.Socket$3.run(Socket.java:952) + at java.security.AccessController.doPrivileged(Native Method) + at java.net.Socket.getOutputStream(Socket.java:951) + at redis.clients.jedis.Connection.connect(Connection.java:200) + ... 7 more + + +让我们分析一下 Jedis 类的源码，搞清楚其中缘由吧。 + +public class Jedis extends BinaryJedis implements JedisCommands, MultiKeyCommands, + AdvancedJedisCommands, ScriptingCommands, BasicCommands, ClusterCommands, SentinelCommands, ModuleCommands { + +} + +public class BinaryJedis implements BasicCommands, BinaryJedisCommands, MultiKeyBinaryCommands, + AdvancedBinaryJedisCommands, BinaryScriptingCommands, Closeable { + + protected Client client = null; + + ... + +} + +public class Client extends BinaryClient implements Commands { + +} + +public class BinaryClient extends Connection { + +} + +public class Connection implements Closeable { + + private Socket socket; + + private RedisOutputStream outputStream; + + private RedisInputStream inputStream; + +} + + +可以看到，Jedis 继承了 BinaryJedis，BinaryJedis 中保存了单个 Client 的实例，Client 最终继承了 Connection，Connection 中保存了单个 Socket 的实例，和 Socket 对应的两个读写流。因此，一个 Jedis 对应一个 Socket 连接。类图如下： + + + +BinaryClient 封装了各种 Redis 命令，其最终会调用基类 Connection 的方法，使用 Protocol 类发送命令。看一下 Protocol 类的 sendCommand 方法的源码，可以发现其发送命令时是直接操作 RedisOutputStream 写入字节。 + +我们在多线程环境下复用 Jedis 对象，其实就是在复用 RedisOutputStream。如果多个线程在执行操作，那么既无法确保整条命令以一个原子操作写入 Socket，也无法确保写入后、读取前没有其他数据写到远端： + +private static void sendCommand(final RedisOutputStream os, final byte[] command, + + final byte[]... args) { + + try { + + os.write(ASTERISK_BYTE); + os.writeIntCrLf(args.length + 1); + os.write(DOLLAR_BYTE); + os.writeIntCrLf(command.length); + os.write(command); + os.writeCrLf(); + + for (final byte[] arg : args) { + os.write(DOLLAR_BYTE); + os.writeIntCrLf(arg.length); + os.write(arg); + os.writeCrLf(); + } + } catch (IOException e) { + throw new JedisConnectionException(e); + } +} + + +看到这里我们也可以理解了，为啥多线程情况下使用 Jedis 对象操作 Redis 会出现各种奇怪的问题。 + +比如，写操作互相干扰，多条命令相互穿插的话，必然不是合法的 Redis 命令，那么 Redis 会关闭客户端连接，导致连接断开；又比如，线程 1 和 2 先后写入了 get a 和 get b 操作的请求，Redis 也返回了值 1 和 2，但是线程 2 先读取了数据 1 就会出现数据错乱的问题。 + +修复方式是，使用 Jedis 提供的另一个线程安全的类 JedisPool 来获得 Jedis 的实例。JedisPool 可以声明为 static 在多个线程之间共享，扮演连接池的角色。使用时，按需使用 try-with-resources 模式从 JedisPool 获得和归还 Jedis 实例。 + +private static JedisPool jedisPool = new JedisPool("127.0.0.1", 6379); + +new Thread(() -> { + try (Jedis jedis = jedisPool.getResource()) { + for (int i = 0; i < 1000; i++) { + String result = jedis.get("a"); + if (!result.equals("1")) { + log.warn("Expect a to be 1 but found {}", result); + return; + } + } + } +}).start(); + +new Thread(() -> { + try (Jedis jedis = jedisPool.getResource()) { + for (int i = 0; i < 1000; i++) { + String result = jedis.get("b"); + if (!result.equals("2")) { + log.warn("Expect b to be 2 but found {}", result); + return; + } + } + } +}).start(); + + +这样修复后，代码不再有线程安全问题了。此外，我们最好通过 shutdownhook，在程序退出之前关闭 JedisPool： + +@PostConstruct +public void init() { + + Runtime.getRuntime().addShutdownHook(new Thread(() -> { + jedisPool.close(); + })); + +} + + +看一下 Jedis 类 close 方法的实现可以发现，如果 Jedis 是从连接池获取的话，那么 close 方法会调用连接池的 return 方法归还连接： + +public class Jedis extends BinaryJedis implements JedisCommands, MultiKeyCommands, + AdvancedJedisCommands, ScriptingCommands, BasicCommands, ClusterCommands, SentinelCommands, ModuleCommands { + + protected JedisPoolAbstract dataSource = null; + + @Override + public void close() { + + if (dataSource != null) { + JedisPoolAbstract pool = this.dataSource; + this.dataSource = null; + if (client.isBroken()) { + pool.returnBrokenResource(this); + } else { + pool.returnResource(this); + } + } else { + super.close(); + } + } +} + + +如果不是，则直接关闭连接，其最终调用 Connection 类的 disconnect 方法来关闭 TCP 连接： + +public void disconnect() { + + if (isConnected()) { + try { + outputStream.flush(); + socket.close(); + } catch (IOException ex) { + broken = true; + throw new JedisConnectionException(ex); + } finally { + IOUtils.closeQuietly(socket); + } + } +} + + +可以看到，Jedis 可以独立使用，也可以配合连接池使用，这个连接池就是 JedisPool。我们再看看 JedisPool 的实现。 + +public class JedisPool extends JedisPoolAbstract { + + @Override + public Jedis getResource() { + + Jedis jedis = super.getResource() + jedis.setDataSource(this); + return jedis; + + } + + @Override + protected void returnResource(final Jedis resource) { + + if (resource != null) { + try { + resource.resetState(); + returnResourceObject(resource); + } catch (Exception e) { + returnBrokenResource(resource); + throw new JedisException("Resource is returned to the pool as broken", e); + } + } + } +} + +public class JedisPoolAbstract extends Pool { + +} + +public abstract class Pool implements Closeable { + protected GenericObjectPool internalPool; + +} + + +JedisPool 的 getResource 方法在拿到 Jedis 对象后，将自己设置为了连接池。连接池 JedisPool，继承了 JedisPoolAbstract，而后者继承了抽象类 Pool，Pool 内部维护了 Apache Common 的通用池 GenericObjectPool。JedisPool 的连接池就是基于 GenericObjectPool 的。 + +看到这里我们了解了，Jedis 的 API 实现是我们说的三种类型中的第一种，也就是连接池和连接分离的 API，JedisPool 是线程安全的连接池，Jedis 是非线程安全的单一连接。知道了原理之后，我们再使用 Jedis 就胸有成竹了。 + +使用连接池务必确保复用 + +在介绍线程池的时候我们强调过，池一定是用来复用的，否则其使用代价会比每次创建单一对象更大。对连接池来说更是如此，原因如下： + +创建连接池的时候很可能一次性创建了多个连接，大多数连接池考虑到性能，会在初始化的时候维护一定数量的最小连接（毕竟初始化连接池的过程一般是一次性的），可以直接使用。如果每次使用连接池都按需创建连接池，那么很可能你只用到一个连接，但是创建了 N 个连接。 + +连接池一般会有一些管理模块，也就是连接池的结构示意图中的绿色部分。举个例子，大多数的连接池都有闲置超时的概念。连接池会检测连接的闲置时间，定期回收闲置的连接，把活跃连接数降到最低（闲置）连接的配置值，减轻服务端的压力。一般情况下，闲置连接由独立线程管理，启动了空闲检测的连接池相当于还会启动一个线程。此外，有些连接池还需要独立线程负责连接保活等功能。因此，启动一个连接池相当于启动了 N 个线程。 + +除了使用代价，连接池不释放，还可能会引起线程泄露。接下来，我就以 Apache HttpClient 为例，和你说说连接池不复用的问题。 + +首先，创建一个 CloseableHttpClient，设置使用 PoolingHttpClientConnectionManager 连接池并启用空闲连接驱逐策略，最大空闲时间为 60 秒，然后使用这个连接来请求一个会返回 OK 字符串的服务端接口： + +@GetMapping("wrong1") +public String wrong1() { + + CloseableHttpClient client = HttpClients.custom() + .setConnectionManager(new PoolingHttpClientConnectionManager()) + .evictIdleConnections(60, TimeUnit.SECONDS).build(); + + try (CloseableHttpResponse response = client.execute(new HttpGet("http://127.0.0.1:45678/httpclientnotreuse/test"))) { + return EntityUtils.toString(response.getEntity()); + } catch (Exception ex) { + ex.printStackTrace(); + } + return null; +} + + +访问这个接口几次后查看应用线程情况，可以看到有大量叫作 Connection evictor 的线程，且这些线程不会销毁： + + + +对这个接口进行几秒的压测（压测使用 wrk，1 个并发 1 个连接）可以看到，已经建立了三千多个 TCP 连接到 45678 端口（其中有 1 个是压测客户端到 Tomcat 的连接，大部分都是 HttpClient 到 Tomcat 的连接）： + + + +好在有了空闲连接回收的策略，60 秒之后连接处于 CLOSE_WAIT 状态，最终彻底关闭。 + + + +这 2 点证明，CloseableHttpClient 属于第二种模式，即内部带有连接池的 API，其背后是连接池，最佳实践一定是复用。 + +复用方式很简单，你可以把 CloseableHttpClient 声明为 static，只创建一次，并且在 JVM 关闭之前通过 addShutdownHook 钩子关闭连接池，在使用的时候直接使用 CloseableHttpClient 即可，无需每次都创建。 + +首先，定义一个 right 接口来实现服务端接口调用： + +private static CloseableHttpClient httpClient = null; + +static { + + //当然，也可以把CloseableHttpClient定义为Bean，然后在@PreDestroy标记的方法内close这个HttpClient + httpClient = HttpClients.custom().setMaxConnPerRoute(1).setMaxConnTotal(1).evictIdleConnections(60, TimeUnit.SECONDS).build(); + + Runtime.getRuntime().addShutdownHook(new Thread(() -> { + try { + httpClient.close(); + } catch (IOException ignored) { + } + })); +} + +@GetMapping("right") +public String right() { + + try (CloseableHttpResponse response = httpClient.execute(new HttpGet("http://127.0.0.1:45678/httpclientnotreuse/test"))) { + return EntityUtils.toString(response.getEntity()); + } catch (Exception ex) { + ex.printStackTrace(); + } + return null; +} + + +然后，重新定义一个 wrong2 接口，修复之前按需创建 CloseableHttpClient 的代码，每次用完之后确保连接池可以关闭： + +@GetMapping("wrong2") +public String wrong2() { + + try (CloseableHttpClient client = HttpClients.custom() + .setConnectionManager(new PoolingHttpClientConnectionManager()) + .evictIdleConnections(60, TimeUnit.SECONDS).build(); + + CloseableHttpResponse response = client.execute(new HttpGet("http://127.0.0.1:45678/httpclientnotreuse/test"))) { + return EntityUtils.toString(response.getEntity()); + } catch (Exception ex) { + ex.printStackTrace(); + } + return null; +} + + +使用 wrk 对 wrong2 和 right 两个接口分别压测 60 秒，可以看到两种使用方式性能上的差异，每次创建连接池的 QPS 是 337，而复用连接池的 QPS 是 2022： + + + +如此大的性能差异显然是因为 TCP 连接的复用。你可能注意到了，刚才定义连接池时，我将最大连接数设置为 1。所以，复用连接池方式复用的始终应该是同一个连接，而新建连接池方式应该是每次都会创建新的 TCP 连接。 + +接下来，我们通过网络抓包工具 Wireshark 来证实这一点。 + +如果调用 wrong2 接口每次创建新的连接池来发起 HTTP 请求，从 Wireshark 可以看到，每次请求服务端 45678 的客户端端口都是新的。这里我发起了三次请求，程序通过 HttpClient 访问服务端 45678 的客户端端口号，分别是 51677、51679 和 51681： + + + +也就是说，每次都是新的 TCP 连接，放开 HTTP 这个过滤条件也可以看到完整的 TCP 握手、挥手的过程： + + + +而复用连接池方式的接口 right 的表现就完全不同了。可以看到，第二次 HTTP 请求 #41 的客户端端口 61468 和第一次连接 #23 的端口是一样的，Wireshark 也提示了整个 TCP 会话中，当前 #41 请求是第二次请求，前一次是 #23，后面一次是 #75： + + + +只有 TCP 连接闲置超过 60 秒后才会断开，连接池会新建连接。你可以尝试通过 Wireshark 观察这一过程。 + +接下来，我们就继续聊聊连接池的配置问题。 + +连接池的配置不是一成不变的 + +为方便根据容量规划设置连接处的属性，连接池提供了许多参数，包括最小（闲置）连接、最大连接、闲置连接生存时间、连接生存时间等。其中，最重要的参数是最大连接数，它决定了连接池能使用的连接数量上限，达到上限后，新来的请求需要等待其他请求释放连接。 + +但，最大连接数不是设置得越大越好。如果设置得太大，不仅仅是客户端需要耗费过多的资源维护连接，更重要的是由于服务端对应的是多个客户端，每一个客户端都保持大量的连接，会给服务端带来更大的压力。这个压力又不仅仅是内存压力，可以想一下如果服务端的网络模型是一个 TCP 连接一个线程，那么几千个连接意味着几千个线程，如此多的线程会造成大量的线程切换开销。 + +当然，连接池最大连接数设置得太小，很可能会因为获取连接的等待时间太长，导致吞吐量低下，甚至超时无法获取连接。 + +接下来，我们就模拟下压力增大导致数据库连接池打满的情况，来实践下如何确认连接池的使用情况，以及有针对性地进行参数优化。 + +首先，定义一个用户注册方法，通过 @Transactional 注解为方法开启事务。其中包含了 500 毫秒的休眠，一个数据库事务对应一个 TCP 连接，所以 500 多毫秒的时间都会占用数据库连接： + +@Transactional + +public User register(){ + + User user=new User(); + user.setName("new-user-"+System.currentTimeMillis()); + userRepository.save(user); + + try { + TimeUnit.MILLISECONDS.sleep(500); + } catch (InterruptedException e) { + e.printStackTrace(); + } + return user; +} + + +随后，修改配置文件启用 register-mbeans，使 Hikari 连接池能通过 JMX MBean 注册连接池相关统计信息，方便观察连接池： + +spring.datasource.hikari.register-mbeans=true + + +启动程序并通过 JConsole 连接进程后，可以看到默认情况下最大连接数为 10： + + + +使用 wrk 对应用进行压测，可以看到连接数一下子从 0 到了 10，有 20 个线程在等待获取连接： + + + +不久就出现了无法获取数据库连接的异常，如下所示： + +[15:37:56.156] [http-nio-45678-exec-15] [ERROR] [.a.c.c.C.[.[.[/].[dispatcherServlet]:175 ] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.dao.DataAccessResourceFailureException: unable to obtain isolated JDBC connection; nested exception is org.hibernate.exception.JDBCConnectionException: unable to obtain isolated JDBC connection] with root cause +java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms. + + +从异常信息中可以看到，数据库连接池是 HikariPool，解决方式很简单，修改一下配置文件，调整数据库连接池最大连接参数到 50 即可。 + +spring.datasource.hikari.maximum-pool-size=50 + + +然后，再观察一下这个参数是否适合当前压力，满足需求的同时也不占用过多资源。从监控来看这个调整是合理的，有一半的富余资源，再也没有线程需要等待连接了： + + + +在这个 Demo 里，我知道压测大概能对应使用 25 左右的并发连接，所以直接把连接池最大连接设置为了 50。在真实情况下，只要数据库可以承受，你可以选择在遇到连接超限的时候先设置一个足够大的连接数，然后观察最终应用的并发，再按照实际并发数留出一半的余量来设置最终的最大连接。 + +其实，看到错误日志后再调整已经有点儿晚了。更合适的做法是，对类似数据库连接池的重要资源进行持续检测，并设置一半的使用量作为报警阈值，出现预警后及时扩容。 + +在这里我是为了演示，才通过 JConsole 查看参数配置后的效果，生产上需要把相关数据对接到指标监控体系中持续监测。 + +这里要强调的是，修改配置参数务必验证是否生效，并且在监控系统中确认参数是否生效、是否合理。之所以要“强调”，是因为这里有坑。 + +我之前就遇到过这样一个事故。应用准备针对大促活动进行扩容，把数据库配置文件中 Druid 连接池最大连接数 maxActive 从 50 提高到了 100，修改后并没有通过监控验证，结果大促当天应用因为连接池连接数不够爆了。 + +经排查发现，当时修改的连接数并没有生效。原因是，应用虽然一开始使用的是 Druid 连接池，但后来框架升级了，把连接池替换为了 Hikari 实现，原来的那些配置其实都是无效的，修改后的参数配置当然也不会生效。 + +所以说，对连接池进行调参，一定要眼见为实。 + +重点回顾 + +今天，我以三种业务代码最常用的 Redis 连接池、HTTP 连接池、数据库连接池为例，和你探讨了有关连接池实现方式、使用姿势和参数配置的三大问题。 + +客户端 SDK 实现连接池的方式，包括池和连接分离、内部带有连接池和非连接池三种。要正确使用连接池，就必须首先鉴别连接池的实现方式。比如，Jedis 的 API 实现的是池和连接分离的方式，而 Apache HttpClient 是内置连接池的 API。 + +对于使用姿势其实就是两点，一是确保连接池是复用的，二是尽可能在程序退出之前显式关闭连接池释放资源。连接池设计的初衷就是为了保持一定量的连接，这样连接可以随取随用。从连接池获取连接虽然很快，但连接池的初始化会比较慢，需要做一些管理模块的初始化以及初始最小闲置连接。一旦连接池不是复用的，那么其性能会比随时创建单一连接更差。 + +最后，连接池参数配置中，最重要的是最大连接数，许多高并发应用往往因为最大连接数不够导致性能问题。但，最大连接数不是设置得越大越好，够用就好。需要注意的是，针对数据库连接池、HTTP 连接池、Redis 连接池等重要连接池，务必建立完善的监控和报警机制，根据容量规划及时调整参数配置。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +有了连接池之后，获取连接是从连接池获取，没有足够连接时连接池会创建连接。这时，获取连接操作往往有两个超时时间：一个是从连接池获取连接的最长等待时间，通常叫作请求连接超时 connectRequestTimeout 或连接等待超时 connectWaitTimeout；一个是连接池新建 TCP 连接三次握手的连接超时，通常叫作连接超时 connectTimeout。针对 JedisPool、Apache HttpClient 和 Hikari 数据库连接池，你知道如何设置这 2 个参数吗？ + +对于带有连接池的 SDK 的使用姿势，最主要的是鉴别其内部是否实现了连接池，如果实现了连接池要尽量复用 Client。对于 NoSQL 中的 MongoDB 来说，使用 MongoDB Java 驱动时，MongoClient 类应该是每次都创建还是复用呢？你能否在官方文档中找到答案呢？ + +关于连接池，你还遇到过什么坑吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/05HTTP调用：你考虑到超时、重试、并发了吗？.md b/专栏/Java业务开发常见错误100例/05HTTP调用：你考虑到超时、重试、并发了吗？.md new file mode 100644 index 0000000..ef095ff --- /dev/null +++ b/专栏/Java业务开发常见错误100例/05HTTP调用：你考虑到超时、重试、并发了吗？.md @@ -0,0 +1,533 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 05 HTTP调用：你考虑到超时、重试、并发了吗？ + 今天，我们一起聊聊进行 HTTP 调用需要注意的超时、重试、并发等问题。 + +与执行本地方法不同，进行 HTTP 调用本质上是通过 HTTP 协议进行一次网络请求。网络请求必然有超时的可能性，因此我们必须考虑到这三点： + +首先，框架设置的默认超时是否合理； + +其次，考虑到网络的不稳定，超时后的请求重试是一个不错的选择，但需要考虑服务端接口的幂等性设计是否允许我们重试； + +最后，需要考虑框架是否会像浏览器那样限制并发连接数，以免在服务并发很大的情况下，HTTP 调用的并发数限制成为瓶颈。 + +Spring Cloud 是 Java 微服务架构的代表性框架。如果使用 Spring Cloud 进行微服务开发，就会使用 Feign 进行声明式的服务调用。如果不使用 Spring Cloud，而直接使用 Spring Boot 进行微服务开发的话，可能会直接使用 Java 中最常用的 HTTP 客户端 Apache HttpClient 进行服务调用。 + +接下来，我们就看看使用 Feign 和 Apache HttpClient 进行 HTTP 接口调用时，可能会遇到的超时、重试和并发方面的坑。 + +配置连接超时和读取超时参数的学问 + +对于 HTTP 调用，虽然应用层走的是 HTTP 协议，但网络层面始终是 TCP/IP 协议。TCP/IP 是面向连接的协议，在传输数据之前需要建立连接。几乎所有的网络框架都会提供这么两个超时参数： + +连接超时参数 ConnectTimeout，让用户配置建连阶段的最长等待时间； + +读取超时参数 ReadTimeout，用来控制从 Socket 上读取数据的最长等待时间。 + +这两个参数看似是网络层偏底层的配置参数，不足以引起开发同学的重视。但，正确理解和配置这两个参数，对业务应用特别重要，毕竟超时不是单方面的事情，需要客户端和服务端对超时有一致的估计，协同配合方能平衡吞吐量和错误率。 + +连接超时参数和连接超时的误区有这么两个： + +连接超时配置得特别长，比如 60 秒。一般来说，TCP 三次握手建立连接需要的时间非常短，通常在毫秒级最多到秒级，不可能需要十几秒甚至几十秒。如果很久都无法建连，很可能是网络或防火墙配置的问题。这种情况下，如果几秒连接不上，那么可能永远也连接不上。因此，设置特别长的连接超时意义不大，将其配置得短一些（比如 1~5 秒）即可。如果是纯内网调用的话，这个参数可以设置得更短，在下游服务离线无法连接的时候，可以快速失败。 + +排查连接超时问题，却没理清连的是哪里。通常情况下，我们的服务会有多个节点，如果别的客户端通过客户端负载均衡技术来连接服务端，那么客户端和服务端会直接建立连接，此时出现连接超时大概率是服务端的问题；而如果服务端通过类似 Nginx 的反向代理来负载均衡，客户端连接的其实是 Nginx，而不是服务端，此时出现连接超时应该排查 Nginx。 + +读取超时参数和读取超时则会有更多的误区，我将其归纳为如下三个。 + +第一个误区：认为出现了读取超时，服务端的执行就会中断。 + +我们来简单测试下。定义一个 client 接口，内部通过 HttpClient 调用服务端接口 server，客户端读取超时 2 秒，服务端接口执行耗时 5 秒。 + +@RestController +@RequestMapping("clientreadtimeout") +@Slf4j +public class ClientReadTimeoutController { + + private String getResponse(String url, int connectTimeout, int readTimeout) throws IOException { + return Request.Get("http://localhost:45678/clientreadtimeout" + url) + .connectTimeout(connectTimeout) + .socketTimeout(readTimeout) + .execute() + .returnContent() + .asString(); + } + + + @GetMapping("client") + public String client() throws IOException { + log.info("client1 called"); + //服务端5s超时，客户端读取超时2秒 + return getResponse("/server?timeout=5000", 1000, 2000); + } + + @GetMapping("server") + public void server(@RequestParam("timeout") int timeout) throws InterruptedException { + + log.info("server called"); + TimeUnit.MILLISECONDS.sleep(timeout); + log.info("Done"); + } + +} + + +调用 client 接口后，从日志中可以看到，客户端 2 秒后出现了 SocketTimeoutException，原因是读取超时，服务端却丝毫没受影响在 3 秒后执行完成。 + +[11:35:11.943] [http-nio-45678-exec-1] [INFO ] [.t.c.c.d.ClientReadTimeoutController:29 ] - client1 called +[11:35:12.032] [http-nio-45678-exec-2] [INFO ] [.t.c.c.d.ClientReadTimeoutController:36 ] - server called +[11:35:14.042] [http-nio-45678-exec-1] [ERROR] [.a.c.c.C.[.[.[/].[dispatcherServlet]:175 ] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception +java.net.SocketTimeoutException: Read timed out + at java.net.SocketInputStream.socketRead0(Native Method) + ... + +[11:35:17.036] [http-nio-45678-exec-2] [INFO ] [.t.c.c.d.ClientReadTimeoutController:38 ] - Done + + +我们知道，类似 Tomcat 的 Web 服务器都是把服务端请求提交到线程池处理的，只要服务端收到了请求，网络层面的超时和断开便不会影响服务端的执行。因此，出现读取超时不能随意假设服务端的处理情况，需要根据业务状态考虑如何进行后续处理。 + +第二个误区：认为读取超时只是 Socket 网络层面的概念，是数据传输的最长耗时，故将其配置得非常短，比如 100 毫秒。 + +其实，发生了读取超时，网络层面无法区分是服务端没有把数据返回给客户端，还是数据在网络上耗时较久或丢包。 + +但，因为 TCP 是先建立连接后传输数据，对于网络情况不是特别糟糕的服务调用，通常可以认为出现连接超时是网络问题或服务不在线，而出现读取超时是服务处理超时。确切地说，读取超时指的是，向 Socket 写入数据后，我们等到 Socket 返回数据的超时时间，其中包含的时间或者说绝大部分的时间，是服务端处理业务逻辑的时间。 + +第三个误区：认为超时时间越长任务接口成功率就越高，将读取超时参数配置得太长。 + +进行 HTTP 请求一般是需要获得结果的，属于同步调用。如果超时时间很长，在等待服务端返回数据的同时，客户端线程（通常是 Tomcat 线程）也在等待，当下游服务出现大量超时的时候，程序可能也会受到拖累创建大量线程，最终崩溃。 + +对定时任务或异步任务来说，读取超时配置得长些问题不大。但面向用户响应的请求或是微服务短平快的同步接口调用，并发量一般较大，我们应该设置一个较短的读取超时时间，以防止被下游服务拖慢，通常不会设置超过 30 秒的读取超时。 + +你可能会说，如果把读取超时设置为 2 秒，服务端接口需要 3 秒，岂不是永远都拿不到执行结果了？的确是这样，因此设置读取超时一定要根据实际情况，过长可能会让下游抖动影响到自己，过短又可能影响成功率。甚至，有些时候我们还要根据下游服务的 SLA，为不同的服务端接口设置不同的客户端读取超时。 + +Feign 和 Ribbon 配合使用，你知道怎么配置超时吗？ + +刚才我强调了根据自己的需求配置连接超时和读取超时的重要性，你是否尝试过为 Spring Cloud 的 Feign 配置超时参数呢，有没有被网上的各种资料绕晕呢？ + +在我看来，为 Feign 配置超时参数的复杂之处在于，Feign 自己有两个超时参数，它使用的负载均衡组件 Ribbon 本身还有相关配置。那么，这些配置的优先级是怎样的，又哪些什么坑呢？接下来，我们做一些实验吧。 + +为测试服务端的超时，假设有这么一个服务端接口，什么都不干只休眠 10 分钟： + +@PostMapping("/server") +public void server() throws InterruptedException { + + TimeUnit.MINUTES.sleep(10); +} + + +首先，定义一个 Feign 来调用这个接口： + +@FeignClient(name = "clientsdk") +public interface Client { + + @PostMapping("/feignandribbon/server") + void server(); + +} + + +然后，通过 Feign Client 进行接口调用： + +@GetMapping("client") +public void timeout() { + + long begin=System.currentTimeMillis(); + try{ + client.server(); + }catch (Exception ex){ + log.warn("执行耗时：{}ms 错误：{}", System.currentTimeMillis() - begin, ex.getMessage()); + } +} + + +在配置文件仅指定服务端地址的情况下： + +clientsdk.ribbon.listOfServers=localhost:45678 + + +得到如下输出： + +[15:40:16.094] [http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] - 执行耗时：1007ms 错误：Read timed out executing POST http://clientsdk/feignandribbon/server + + +从这个输出中，我们可以得到结论一，默认情况下 Feign 的读取超时是 1 秒，如此短的读取超时算是坑点一。 + +我们来分析一下源码。打开 RibbonClientConfiguration 类后，会看到 DefaultClientConfigImpl 被创建出来之后，ReadTimeout 和 ConnectTimeout 被设置为 1s： + +/** + * Ribbon client default connect timeout. + */ + +public static final int DEFAULT_CONNECT_TIMEOUT = 1000; + +/** + * Ribbon client default read timeout. + */ +public static final int DEFAULT_READ_TIMEOUT = 1000; + +@Bean +@ConditionalOnMissingBean +public IClientConfig ribbonClientConfig() { + + DefaultClientConfigImpl config = new DefaultClientConfigImpl(); + config.loadProperties(this.name); + config.set(CommonClientConfigKey.ConnectTimeout, DEFAULT_CONNECT_TIMEOUT); + config.set(CommonClientConfigKey.ReadTimeout, DEFAULT_READ_TIMEOUT); + config.set(CommonClientConfigKey.GZipPayload, DEFAULT_GZIP_PAYLOAD); + + return config; +} + + +如果要修改 Feign 客户端默认的两个全局超时时间，你可以设置 feign.client.config.default.readTimeout 和 feign.client.config.default.connectTimeout 参数： + +feign.client.config.default.readTimeout=3000 +feign.client.config.default.connectTimeout=3000 + + +修改配置后重试，得到如下日志： + +[15:43:39.955] [http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] - 执行耗时：3006ms 错误：Read timed out executing POST http://clientsdk/feignandribbon/server + + +可见，3 秒读取超时生效了。注意：这里有一个大坑，如果你希望只修改读取超时，可能会只配置这么一行： + +feign.client.config.default.readTimeout=3000 + + +测试一下你就会发现，这样的配置是无法生效的！ + +结论二，也是坑点二，如果要配置 Feign 的读取超时，就必须同时配置连接超时，才能生效。 + +打开 FeignClientFactoryBean 可以看到，只有同时设置 ConnectTimeout 和 ReadTimeout，Request.Options 才会被覆盖： + +if (config.getConnectTimeout() != null && config.getReadTimeout() != null) { + builder.options(new Request.Options(config.getConnectTimeout(), + config.getReadTimeout())); +} + + +更进一步，如果你希望针对单独的 Feign Client 设置超时时间，可以把 default 替换为 Client 的 name： + +feign.client.config.default.readTimeout=3000 +feign.client.config.default.connectTimeout=3000 +feign.client.config.clientsdk.readTimeout=2000 +feign.client.config.clientsdk.connectTimeout=2000 + + +可以得出结论三，单独的超时可以覆盖全局超时，这符合预期，不算坑： + +[15:45:51.708] [http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] - 执行耗时：2006ms 错误：Read timed out executing POST http://clientsdk/feignandribbon/server + + +结论四，除了可以配置 Feign，也可以配置 Ribbon 组件的参数来修改两个超时时间。这里的坑点三是，参数首字母要大写，和 Feign 的配置不同。 + +ribbon.ReadTimeout=4000 +ribbon.ConnectTimeout=4000 + + +可以通过日志证明参数生效： + +[15:55:18.019] [http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] - 执行耗时：4003ms 错误：Read timed out executing POST http://clientsdk/feignandribbon/server + + +最后，我们来看看同时配置 Feign 和 Ribbon 的参数，最终谁会生效？如下代码的参数配置： + +clientsdk.ribbon.listOfServers=localhost:45678 +feign.client.config.default.readTimeout=3000 +feign.client.config.default.connectTimeout=3000 +ribbon.ReadTimeout=4000 +ribbon.ConnectTimeout=4000 + + +日志输出证明，最终生效的是 Feign 的超时： + +[16:01:19.972] [http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController :26 ] - 执行耗时：3006ms 错误：Read timed out executing POST http://clientsdk/feignandribbon/server + + +结论五，同时配置 Feign 和 Ribbon 的超时，以 Feign 为准。这有点反直觉，因为 Ribbon 更底层所以你会觉得后者的配置会生效，但其实不是这样的。 + +在 LoadBalancerFeignClient 源码中可以看到，如果 Request.Options 不是默认值，就会创建一个 FeignOptionsClientConfig 代替原来 Ribbon 的 DefaultClientConfigImpl，导致 Ribbon 的配置被 Feign 覆盖： + +IClientConfig getClientConfig(Request.Options options, String clientName) { + IClientConfig requestConfig; + + if (options == DEFAULT_OPTIONS) { + requestConfig = this.clientFactory.getClientConfig(clientName); + } else { + requestConfig = new FeignOptionsClientConfig(options); + } + return requestConfig; + +} + + +但如果这么配置最终生效的还是 Ribbon 的超时（4 秒），这容易让人产生 Ribbon 覆盖了 Feign 的错觉，其实这还是因为坑二所致，单独配置 Feign 的读取超时并不能生效： + +clientsdk.ribbon.listOfServers=localhost:45678 +feign.client.config.default.readTimeout=3000 +feign.client.config.clientsdk.readTimeout=2000 +ribbon.ReadTimeout=4000 + + +你是否知道 Ribbon 会自动重试请求呢？ + +一些 HTTP 客户端往往会内置一些重试策略，其初衷是好的，毕竟因为网络问题导致丢包虽然频繁但持续时间短，往往重试下第二次就能成功，但一定要小心这种自作主张是否符合我们的预期。 + +之前遇到过一个短信重复发送的问题，但短信服务的调用方用户服务，反复确认代码里没有重试逻辑。那问题究竟出在哪里了？我们来重现一下这个案例。 + +首先，定义一个 Get 请求的发送短信接口，里面没有任何逻辑，休眠 2 秒模拟耗时： + +@RestController +@RequestMapping("ribbonretryissueserver") +@Slf4j +public class RibbonRetryIssueServerController { + + @GetMapping("sms") + public void sendSmsWrong(@RequestParam("mobile") String mobile, @RequestParam("message") String message, HttpServletRequest request) throws InterruptedException { + + //输出调用参数后休眠2秒 + log.info("{} is called, {}=>{}", request.getRequestURL().toString(), mobile, message); + TimeUnit.SECONDS.sleep(2); + } +} + + +配置一个 Feign 供客户端调用： + +@FeignClient(name = "SmsClient") +public interface SmsClient { + + @GetMapping("/ribbonretryissueserver/sms") + void sendSmsWrong(@RequestParam("mobile") String mobile, @RequestParam("message") String message); +} + + +Feign 内部有一个 Ribbon 组件负责客户端负载均衡，通过配置文件设置其调用的服务端为两个节点： + +SmsClient.ribbon.listOfServers=localhost:45679,localhost:45678 + + +写一个客户端接口，通过 Feign 调用服务端： + +@RestController +@RequestMapping("ribbonretryissueclient") +@Slf4j +public class RibbonRetryIssueClientController { + + @Autowired + private SmsClient smsClient; + + @GetMapping("wrong") + public String wrong() { + log.info("client is called"); + try{ + //通过Feign调用发送短信接口 + smsClient.sendSmsWrong("13600000000", UUID.randomUUID().toString()); + } catch (Exception ex) { + //捕获可能出现的网络错误 + log.error("send sms failed : {}", ex.getMessage()); + } + return "done"; + } +} + + +在 45678 和 45679 两个端口上分别启动服务端，然后访问 45678 的客户端接口进行测试。因为客户端和服务端控制器在一个应用中，所以 45678 同时扮演了客户端和服务端的角色。 + +在 45678 日志中可以看到，29 秒时客户端收到请求开始调用服务端接口发短信，同时服务端收到了请求，2 秒后（注意对比第一条日志和第三条日志）客户端输出了读取超时的错误信息： + +[12:49:29.020] [http-nio-45678-exec-4] [INFO ] [c.d.RibbonRetryIssueClientController:23 ] - client is called +[12:49:29.026] [http-nio-45678-exec-5] [INFO ] [c.d.RibbonRetryIssueServerController:16 ] - http://localhost:45678/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418 +[12:49:31.029] [http-nio-45678-exec-4] [ERROR] [c.d.RibbonRetryIssueClientController:27 ] - send sms failed : Read timed out executing GET http://SmsClient/ribbonretryissueserver/sms?mobile=13600000000&message=a2aa1b32-a044-40e9-8950-7f0189582418 + + +而在另一个服务端 45679 的日志中还可以看到一条请求，30 秒时收到请求，也就是客户端接口调用后的 1 秒： + +[12:49:30.029] [http-nio-45679-exec-2] [INFO ] [c.d.RibbonRetryIssueServerController:16 ] - http://localhost:45679/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418 + + +客户端接口被调用的日志只输出了一次，而服务端的日志输出了两次。虽然 Feign 的默认读取超时时间是 1 秒，但客户端 2 秒后才出现超时错误。显然，这说明客户端自作主张进行了一次重试，导致短信重复发送。 + +翻看 Ribbon 的源码可以发现，MaxAutoRetriesNextServer 参数默认为 1，也就是 Get 请求在某个服务端节点出现问题（比如读取超时）时，Ribbon 会自动重试一次： + +// DefaultClientConfigImpl +public static final int DEFAULT_MAX_AUTO_RETRIES_NEXT_SERVER = 1; +public static final int DEFAULT_MAX_AUTO_RETRIES = 0; + +// RibbonLoadBalancedRetryPolicy +public boolean canRetry(LoadBalancedRetryContext context) { + + HttpMethod method = context.getRequest().getMethod(); + return HttpMethod.GET == method || lbContext.isOkToRetryOnAllOperations(); +} + +@Override +public boolean canRetrySameServer(LoadBalancedRetryContext context) { + + return sameServerCount < lbContext.getRetryHandler().getMaxRetriesOnSameServer() + && canRetry(context); + +} + +@Override +public boolean canRetryNextServer(LoadBalancedRetryContext context) { + + // this will be called after a failure occurs and we increment the counter + // so we check that the count is less than or equals to too make sure + // we try the next server the right number of times + return nextServerCount <= lbContext.getRetryHandler().getMaxRetriesOnNextServer() + && canRetry(context); +} + + +解决办法有两个： + +一是，把发短信接口从 Get 改为 Post。其实，这里还有一个 API 设计问题，有状态的 API 接口不应该定义为 Get。根据 HTTP 协议的规范，Get 请求用于数据查询，而 Post 才是把数据提交到服务端用于修改或新增。选择 Get 还是 Post 的依据，应该是 API 的行为，而不是参数大小。这里的一个误区是，Get 请求的参数包含在 Url QueryString 中，会受浏览器长度限制，所以一些同学会选择使用 JSON 以 Post 提交大参数，使用 Get 提交小参数。 + +二是，将 MaxAutoRetriesNextServer 参数配置为 0，禁用服务调用失败后在下一个服务端节点的自动重试。在配置文件中添加一行即可： + +ribbon.MaxAutoRetriesNextServer=0 + + +看到这里，你觉得问题出在用户服务还是短信服务呢？ + +在我看来，双方都有问题。就像之前说的，Get 请求应该是无状态或者幂等的，短信接口可以设计为支持幂等调用的；而用户服务的开发同学，如果对 Ribbon 的重试机制有所了解的话，或许就能在排查问题上少走些弯路。 + +并发限制了爬虫的抓取能力 + +除了超时和重试的坑，进行 HTTP 请求调用还有一个常见的问题是，并发数的限制导致程序的处理能力上不去。 + +我之前遇到过一个爬虫项目，整体爬取数据的效率很低，增加线程池数量也无济于事，只能堆更多的机器做分布式的爬虫。现在，我们就来模拟下这个场景，看看问题出在了哪里。 + +假设要爬取的服务端是这样的一个简单实现，休眠 1 秒返回数字 1： + +@GetMapping("server") +public int server() throws InterruptedException { + + TimeUnit.SECONDS.sleep(1); + return 1; +} + + +爬虫需要多次调用这个接口进行数据抓取，为了确保线程池不是并发的瓶颈，我们使用一个没有线程上限的 newCachedThreadPool 作为爬取任务的线程池（再次强调，除非你非常清楚自己的需求，否则一般不要使用没有线程数量上限的线程池），然后使用 HttpClient 实现 HTTP 请求，把请求任务循环提交到线程池处理，最后等待所有任务执行完成后输出执行耗时： + +private int sendRequest(int count, Supplier client) throws InterruptedException { + + //用于计数发送的请求个数 + AtomicInteger atomicInteger = new AtomicInteger(); + + //使用HttpClient从server接口查询数据的任务提交到线程池并行处理 + ExecutorService threadPool = Executors.newCachedThreadPool(); + + long begin = System.currentTimeMillis(); + IntStream.rangeClosed(1, count).forEach(i -> { + threadPool.execute(() -> { + try (CloseableHttpResponse response = client.get().execute(new HttpGet("http://127.0.0.1:45678/routelimit/server"))) { + atomicInteger.addAndGet(Integer.parseInt(EntityUtils.toString(response.getEntity()))); + } catch (Exception ex) { + ex.printStackTrace(); + } + }); + }); + + //等到count个任务全部执行完毕 + threadPool.shutdown(); + threadPool.awaitTermination(1, TimeUnit.HOURS); + log.info("发送 {} 次请求，耗时 {} ms", atomicInteger.get(), System.currentTimeMillis() - begin); + return atomicInteger.get(); +} + + +首先，使用默认的 PoolingHttpClientConnectionManager 构造的 CloseableHttpClient，测试一下爬取 10 次的耗时： + +static CloseableHttpClient httpClient1; + +static { + httpClient1 = HttpClients.custom().setConnectionManager(new PoolingHttpClientConnectionManager()).build(); + +} + +@GetMapping("wrong") +public int wrong(@RequestParam(value = "count", defaultValue = "10") int count) throws InterruptedException { + return sendRequest(count, () -> httpClient1); +} + + +虽然一个请求需要 1 秒执行完成，但我们的线程池是可以扩张使用任意数量线程的。按道理说，10 个请求并发处理的时间基本相当于 1 个请求的处理时间，也就是 1 秒，但日志中显示实际耗时 5 秒： + +[12:48:48.122] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.h.r.RouteLimitController :54 ] - 发送 10 次请求，耗时 5265 ms + + +查看 PoolingHttpClientConnectionManager 源码，可以注意到有两个重要参数： + +defaultMaxPerRoute=2，也就是同一个主机 / 域名的最大并发请求数为 2。我们的爬虫需要 10 个并发，显然是默认值太小限制了爬虫的效率。 + +maxTotal=20，也就是所有主机整体最大并发为 20，这也是 HttpClient 整体的并发度。目前，我们请求数是 10 最大并发是 10，20 不会成为瓶颈。举一个例子，使用同一个 HttpClient 访问 10 个域名，defaultMaxPerRoute 设置为 10，为确保每一个域名都能达到 10 并发，需要把 maxTotal 设置为 100。 + +public PoolingHttpClientConnectionManager( + + final HttpClientConnectionOperator httpClientConnectionOperator, + final HttpConnectionFactory connFactory, + final long timeToLive, final TimeUnit timeUnit) { + + ... + this.pool = new CPool(new InternalConnectionFactory( + this.configData, connFactory), 2, 20, timeToLive, timeUnit); + ... +} + +public CPool( + + final ConnFactory connFactory, + final int defaultMaxPerRoute, final int maxTotal, + final long timeToLive, final TimeUnit timeUnit) { + + ... + +}} + + +HttpClient 是 Java 非常常用的 HTTP 客户端，这个问题经常出现。你可能会问，为什么默认值限制得这么小。 + +其实，这不能完全怪 HttpClient，很多早期的浏览器也限制了同一个域名两个并发请求。对于同一个域名并发连接的限制，其实是 HTTP 1.1 协议要求的，这里有这么一段话： + +Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion. + + +HTTP 1.1 协议是 20 年前制定的，现在 HTTP 服务器的能力强很多了，所以有些新的浏览器没有完全遵从 2 并发这个限制，放开并发数到了 8 甚至更大。如果需要通过 HTTP 客户端发起大量并发请求，不管使用什么客户端，请务必确认客户端的实现默认的并发度是否满足需求。 + +既然知道了问题所在，我们就尝试声明一个新的 HttpClient 放开相关限制，设置 maxPerRoute 为 50、maxTotal 为 100，然后修改一下刚才的 wrong 方法，使用新的客户端进行测试： + +httpClient2 = HttpClients.custom().setMaxConnPerRoute(10).setMaxConnTotal(20).build(); + + +输出如下，10 次请求在 1 秒左右执行完成。可以看到，因为放开了一个 Host 2 个并发的默认限制，爬虫效率得到了大幅提升： + +[12:58:11.333] [http-nio-45678-exec-3] [INFO ] [o.g.t.c.h.r.RouteLimitController :54 ] - 发送 10 次请求，耗时 1023 ms + + +重点回顾 + +今天，我和你分享了 HTTP 调用最常遇到的超时、重试和并发问题。 + +连接超时代表建立 TCP 连接的时间，读取超时代表了等待远端返回数据的时间，也包括远端程序处理的时间。在解决连接超时问题时，我们要搞清楚连的是谁；在遇到读取超时问题的时候，我们要综合考虑下游服务的服务标准和自己的服务标准，设置合适的读取超时时间。此外，在使用诸如 Spring Cloud Feign 等框架时务必确认，连接和读取超时参数的配置是否正确生效。 + +对于重试，因为 HTTP 协议认为 Get 请求是数据查询操作，是无状态的，又考虑到网络出现丢包是比较常见的事情，有些 HTTP 客户端或代理服务器会自动重试 Get/Head 请求。如果你的接口设计不支持幂等，需要关闭自动重试。但，更好的解决方案是，遵从 HTTP 协议的建议来使用合适的 HTTP 方法。 + +最后我们看到，包括 HttpClient 在内的 HTTP 客户端以及浏览器，都会限制客户端调用的最大并发数。如果你的客户端有比较大的请求调用并发，比如做爬虫，或是扮演类似代理的角色，又或者是程序本身并发较高，如此小的默认值很容易成为吞吐量的瓶颈，需要及时调整。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +第一节中我们强调了要注意连接超时和读取超时参数的配置，大多数的 HTTP 客户端也都有这两个参数。有读就有写，但为什么我们很少看到“写入超时”的概念呢？ + +除了 Ribbon 的 AutoRetriesNextServer 重试机制，Nginx 也有类似的重试功能。你了解 Nginx 相关的配置吗？ + +针对 HTTP 调用，你还遇到过什么坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/062成的业务代码的Spring声明式事务，可能都没处理正确.md b/专栏/Java业务开发常见错误100例/062成的业务代码的Spring声明式事务，可能都没处理正确.md new file mode 100644 index 0000000..94aac55 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/062成的业务代码的Spring声明式事务，可能都没处理正确.md @@ -0,0 +1,508 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 06 2成的业务代码的Spring声明式事务，可能都没处理正确 + 今天，我来和你聊聊业务代码中与数据库事务相关的坑。 + +Spring 针对 Java Transaction API (JTA)、JDBC、Hibernate 和 Java Persistence API (JPA) 等事务 API，实现了一致的编程模型，而 Spring 的声明式事务功能更是提供了极其方便的事务配置方式，配合 Spring Boot 的自动配置，大多数 Spring Boot 项目只需要在方法上标记 @Transactional 注解，即可一键开启方法的事务性配置。 + +据我观察，大多数业务开发同学都有事务的概念，也知道如果整体考虑多个数据库操作要么成功要么失败时，需要通过数据库事务来实现多个操作的一致性和原子性。但，在使用上大多仅限于为方法标记 @Transactional，不会去关注事务是否有效、出错后事务是否正确回滚，也不会考虑复杂的业务代码中涉及多个子业务逻辑时，怎么正确处理事务。 + +事务没有被正确处理，一般来说不会过于影响正常流程，也不容易在测试阶段被发现。但当系统越来越复杂、压力越来越大之后，就会带来大量的数据不一致问题，随后就是大量的人工介入查看和修复数据。 + +所以说，一个成熟的业务系统和一个基本可用能完成功能的业务系统，在事务处理细节上的差异非常大。要确保事务的配置符合业务功能的需求，往往不仅仅是技术问题，还涉及产品流程和架构设计的问题。今天这一讲的标题“20% 的业务代码的 Spring 声明式事务，可能都没处理正确”中，20% 这个数字在我看来还是比较保守的。 + +我今天要分享的内容，就是帮助你在技术问题上理清思路，避免因为事务处理不当让业务逻辑的实现产生大量偶发 Bug。 + +小心 Spring 的事务可能没有生效 + +在使用 @Transactional 注解开启声明式事务时， 第一个最容易忽略的问题是，很可能事务并没有生效。 + +实现下面的 Demo 需要一些基础类，首先定义一个具有 ID 和姓名属性的 UserEntity，也就是一个包含两个字段的用户表： + +@Entity +@Data +public class UserEntity { + + @Id + @GeneratedValue(strategy = AUTO) + private Long id; + + private String name; + + public UserEntity() { } + + public UserEntity(String name) { + this.name = name; + } + +} + + +为了方便理解，我使用 Spring JPA 做数据库访问，实现这样一个 Repository，新增一个根据用户名查询所有数据的方法： + +@Repository +public interface UserRepository extends JpaRepository { + + List findByName(String name); + +} + + +定义一个 UserService 类，负责业务逻辑处理。如果不清楚 @Transactional 的实现方式，只考虑代码逻辑的话，这段代码看起来没有问题。 + +定义一个入口方法 createUserWrong1 来调用另一个私有方法 createUserPrivate，私有方法上标记了 @Transactional 注解。当传入的用户名包含 test 关键字时判断为用户名不合法，抛出异常，让用户创建操作失败，期望事务可以回滚： + +@Service +@Slf4j +public class UserService { + + @Autowired + private UserRepository userRepository; + + //一个公共方法供Controller调用，内部调用事务性的私有方法 + public int createUserWrong1(String name) { + + try { + this.createUserPrivate(new UserEntity(name)); + } catch (Exception ex) { + log.error("create user failed because {}", ex.getMessage()); + } + return userRepository.findByName(name).size(); + } + + //标记了@Transactional的private方法 + @Transactional + private void createUserPrivate(UserEntity entity) { + + userRepository.save(entity); + if (entity.getName().contains("test")) + throw new RuntimeException("invalid username!"); + } + + //根据用户名查询用户数 + public int getUserCount(String name) { + return userRepository.findByName(name).size(); + } +} + + +下面是 Controller 的实现，只是调用一下刚才定义的 UserService 中的入口方法 createUserWrong1。 + +@Autowired +private UserService userService; + +@GetMapping("wrong1") +public int wrong1(@RequestParam("name") String name) { + return userService.createUserWrong1(name); +} + + +调用接口后发现，即便用户名不合法，用户也能创建成功。刷新浏览器，多次发现有十几个的非法用户注册。 + +这里给出 @Transactional 生效原则 1，除非特殊配置（比如使用 AspectJ 静态织入实现 AOP），否则只有定义在 public 方法上的 @Transactional 才能生效。原因是，Spring 默认通过动态代理的方式实现 AOP，对目标方法进行增强，private 方法无法代理到，Spring 自然也无法动态增强事务处理逻辑。 + +你可能会说，修复方式很简单，把标记了事务注解的 createUserPrivate 方法改为 public 即可。在 UserService 中再建一个入口方法 createUserWrong2，来调用这个 public 方法再次尝试： + +public int createUserWrong2(String name) { + + try { + this.createUserPublic(new UserEntity(name)); + } catch (Exception ex) { + log.error("create user failed because {}", ex.getMessage()); + } + return userRepository.findByName(name).size(); +} + +//标记了@Transactional的public方法 +@Transactional +public void createUserPublic(UserEntity entity) { + userRepository.save(entity); + if (entity.getName().contains("test")) + throw new RuntimeException("invalid username!"); +} + + +测试发现，调用新的 createUserWrong2 方法事务同样不生效。这里，我给出 @Transactional 生效原则 2，必须通过代理过的类从外部调用目标方法才能生效。 + +Spring 通过 AOP 技术对方法进行增强，要调用增强过的方法必然是调用代理后的对象。我们尝试修改下 UserService 的代码，注入一个 self，然后再通过 self 实例调用标记有 @Transactional 注解的 createUserPublic 方法。设置断点可以看到，self 是由 Spring 通过 CGLIB 方式增强过的类： + +CGLIB 通过继承方式实现代理类，private 方法在子类不可见，自然也就无法进行事务增强； + +this 指针代表对象自己，Spring 不可能注入 this，所以通过 this 访问方法必然不是代理。 + + + +把 this 改为 self 后测试发现，在 Controller 中调用 createUserRight 方法可以验证事务是生效的，非法的用户注册操作可以回滚。 + +虽然在 UserService 内部注入自己调用自己的 createUserPublic 可以正确实现事务，但更合理的实现方式是，让 Controller 直接调用之前定义的 UserService 的 createUserPublic 方法，因为注入自己调用自己很奇怪，也不符合分层实现的规范： + +@GetMapping("right2") +public int right2(@RequestParam("name") String name) { + + try { + userService.createUserPublic(new UserEntity(name)); + } catch (Exception ex) { + log.error("create user failed because {}", ex.getMessage()); + } + + return userService.getUserCount(name); +} + + +我们再通过一张图来回顾下 this 自调用、通过 self 调用，以及在 Controller 中调用 UserService 三种实现的区别： + + + +通过 this 自调用，没有机会走到 Spring 的代理类；后两种改进方案调用的是 Spring 注入的 UserService，通过代理调用才有机会对 createUserPublic 方法进行动态增强。 + +这里，我还有一个小技巧，强烈建议你在开发时打开相关的 Debug 日志，以方便了解 Spring 事务实现的细节，并及时判断事务的执行情况。 + +我们的 Demo 代码使用 JPA 进行数据库访问，可以这么开启 Debug 日志： + +logging.level.org.springframework.orm.jpa=DEBUG + + +开启日志后，我们再比较下在 UserService 中通过 this 调用和在 Controller 中通过注入的 UserService Bean 调用 createUserPublic 区别。很明显，this 调用因为没有走代理，事务没有在 createUserPublic 方法上生效，只在 Repository 的 save 方法层面生效： + +//在UserService中通过this调用public的createUserPublic +[10:10:19.913] [http-nio-45678-exec-1] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :370 ] - Creating new transaction with name [org.springframework.data.jpa.repository.support.SimpleJpaRepository.save]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT + +//在Controller中通过注入的UserService Bean调用createUserPublic +[10:10:47.750] [http-nio-45678-exec-6] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :370 ] - Creating new transaction with name [org.geekbang.time.commonmistakes.transaction.demo1.UserService.createUserPublic]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT + + +你可能还会考虑一个问题，这种实现在 Controller 里处理了异常显得有点繁琐，还不如直接把 createUserWrong2 方法加上 @Transactional 注解，然后在 Controller 中直接调用这个方法。这样一来，既能从外部（Controller 中）调用 UserService 中的方法，方法又是 public 的能够被动态代理 AOP 增强。 + +你可以试一下这种方法，但很容易就会踩第二个坑，即因为没有正确处理异常，导致事务即便生效也不一定能回滚。 + +事务即便生效也不一定能回滚 + +通过 AOP 实现事务处理可以理解为，使用 try…catch…来包裹标记了 @Transactional 注解的方法，当方法出现了异常并且满足一定条件的时候，在 catch 里面我们可以设置事务回滚，没有异常则直接提交事务。 + +这里的“一定条件”，主要包括两点。 + +第一，只有异常传播出了标记了 @Transactional 注解的方法，事务才能回滚。在 Spring 的 TransactionAspectSupport 里有个 invokeWithinTransaction 方法，里面就是处理事务的逻辑。可以看到，只有捕获到异常才能进行后续事务处理： + +try { + + // This is an around advice: Invoke the next interceptor in the chain. + // This will normally result in a target object being invoked. + retVal = invocation.proceedWithInvocation(); +} catch (Throwable ex) { + + // target invocation exception + completeTransactionAfterThrowing(txInfo, ex); + throw ex; +} finally { + cleanupTransactionInfo(txInfo); +} + + +第二，默认情况下，出现 RuntimeException（非受检异常）或 Error 的时候，Spring 才会回滚事务。 + +打开 Spring 的 DefaultTransactionAttribute 类能看到如下代码块，可以发现相关证据，通过注释也能看到 Spring 这么做的原因，大概的意思是受检异常一般是业务异常，或者说是类似另一种方法的返回值，出现这样的异常可能业务还能完成，所以不会主动回滚；而 Error 或 RuntimeException 代表了非预期的结果，应该回滚： + +/** + * The default behavior is as with EJB: rollback on unchecked exception + * ({@link RuntimeException}), assuming an unexpected outcome outside of any + * business rules. Additionally, we also attempt to rollback on {@link Error} which + * is clearly an unexpected outcome as well. By contrast, a checked exception is + * considered a business exception and therefore a regular expected outcome of the + * transactional business method, i.e. a kind of alternative return value which + * still allows for regular completion of resource operations. + *

This is largely consistent with TransactionTemplate's default behavior, + * except that TransactionTemplate also rolls back on undeclared checked exceptions + * (a corner case). For declarative transactions, we expect checked exceptions to be + * intentionally declared as business exceptions, leading to a commit by default. + * @see org.springframework.transaction.support.TransactionTemplate#execute + */ + +@Override +public boolean rollbackOn(Throwable ex) { + return (ex instanceof RuntimeException || ex instanceof Error); +} + + +接下来，我和你分享 2 个反例。 + +重新实现一下 UserService 中的注册用户操作： + +在 createUserWrong1 方法中会抛出一个 RuntimeException，但由于方法内 catch 了所有异常，异常无法从方法传播出去，事务自然无法回滚。 + +在 createUserWrong2 方法中，注册用户的同时会有一次 otherTask 文件读取操作，如果文件读取失败，我们希望用户注册的数据库操作回滚。虽然这里没有捕获异常，但因为 otherTask 方法抛出的是受检异常，createUserWrong2 传播出去的也是受检异常，事务同样不会回滚。 + +@Service +@Slf4j +public class UserService { + + @Autowired + private UserRepository userRepository; + + //异常无法传播出方法，导致事务无法回滚 + @Transactional + public void createUserWrong1(String name) { + + try { + userRepository.save(new UserEntity(name)); + throw new RuntimeException("error"); + } catch (Exception ex) { + log.error("create user failed", ex); + } + } + + //即使出了受检异常也无法让事务回滚 + @Transactional + public void createUserWrong2(String name) throws IOException { + + userRepository.save(new UserEntity(name)); + otherTask(); + } + + //因为文件不存在，一定会抛出一个IOException + private void otherTask() throws IOException { + Files.readAllLines(Paths.get("file-that-not-exist")); + } + +} + + +Controller 中的实现，仅仅是调用 UserService 的 createUserWrong1 和 createUserWrong2 方法，这里就贴出实现了。这 2 个方法的实现和调用，虽然完全避开了事务不生效的坑，但因为异常处理不当，导致程序没有如我们期望的文件操作出现异常时回滚事务。 + +现在，我们来看下修复方式，以及如何通过日志来验证是否修复成功。针对这 2 种情况，对应的修复方法如下。 + +第一，如果你希望自己捕获异常进行处理的话，也没关系，可以手动设置让当前事务处于回滚状态： + +@Transactional +public void createUserRight1(String name) { + + try { + userRepository.save(new UserEntity(name)); + throw new RuntimeException("error"); + } catch (Exception ex) { + log.error("create user failed", ex); + TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); + } +} + + +运行后可以在日志中看到 Rolling back 字样，确认事务回滚了。同时，我们还注意到“Transactional code has requested rollback”的提示，表明手动请求回滚： + +[22:14:49.352] [http-nio-45678-exec-4] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :698 ] - Transactional code has requested rollback +[22:14:49.353] [http-nio-45678-exec-4] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :834 ] - Initiating transaction rollback +[22:14:49.353] [http-nio-45678-exec-4] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :555 ] - Rolling back JPA transaction on EntityManager [SessionImpl(1906719643)] + + +第二，在注解中声明，期望遇到所有的 Exception 都回滚事务（来突破默认不回滚受检异常的限制）： + +@Transactional(rollbackFor = Exception.class) +public void createUserRight2(String name) throws IOException { + userRepository.save(new UserEntity(name)); + otherTask(); +} + + +运行后，同样可以在日志中看到回滚的提示： + +[22:10:47.980] [http-nio-45678-exec-4] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :834 ] - Initiating transaction rollback +[22:10:47.981] [http-nio-45678-exec-4] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :555 ] - Rolling back JPA transaction on EntityManager [SessionImpl(1419329213)] + + +在这个例子中，我们展现的是一个复杂的业务逻辑，其中有数据库操作、IO 操作，在 IO 操作出现问题时希望让数据库事务也回滚，以确保逻辑的一致性。在有些业务逻辑中，可能会包含多次数据库操作，我们不一定希望将两次操作作为一个事务来处理，这时候就需要仔细考虑事务传播的配置了，否则也可能踩坑。 + +请确认事务传播配置是否符合自己的业务逻辑 + +有这么一个场景：一个用户注册的操作，会插入一个主用户到用户表，还会注册一个关联的子用户。我们希望将子用户注册的数据库操作作为一个独立事务来处理，即使失败也不会影响主流程，即不影响主用户的注册。 + +接下来，我们模拟一个实现类似业务逻辑的 UserService： + +@Autowired +private UserRepository userRepository; + +@Autowired +private SubUserService subUserService; + +@Transactional +public void createUserWrong(UserEntity entity) { + createMainUser(entity); + subUserService.createSubUserWithExceptionWrong(entity); +} + +private void createMainUser(UserEntity entity) { + userRepository.save(entity); + log.info("createMainUser finish"); +} + + +SubUserService 的 createSubUserWithExceptionWrong 实现正如其名，因为最后我们抛出了一个运行时异常，错误原因是用户状态无效，所以子用户的注册肯定是失败的。我们期望子用户的注册作为一个事务单独回滚，不影响主用户的注册，这样的逻辑可以实现吗？ + +@Service +@Slf4j +public class SubUserService { + + @Autowired + private UserRepository userRepository; + + @Transactional + public void createSubUserWithExceptionWrong(UserEntity entity) { + + log.info("createSubUserWithExceptionWrong start"); + userRepository.save(entity); + throw new RuntimeException("invalid status"); + } +} + + +我们在 Controller 里实现一段测试代码，调用 UserService： + +@GetMapping("wrong") +public int wrong(@RequestParam("name") String name) { + + try { + userService.createUserWrong(new UserEntity(name)); + } catch (Exception ex) { + log.error("createUserWrong failed, reason:{}", ex.getMessage()); + } + + return userService.getUserCount(name); +} + + +调用后可以在日志中发现如下信息，很明显事务回滚了，最后 Controller 打出了创建子用户抛出的运行时异常： + +[22:50:42.866] [http-nio-45678-exec-8] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :555 ] - Rolling back JPA transaction on EntityManager [SessionImpl(103972212)] +[22:50:42.869] [http-nio-45678-exec-8] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :620 ] - Closing JPA EntityManager [SessionImpl(103972212)] after transaction +[22:50:42.869] [http-nio-45678-exec-8] [ERROR] [t.d.TransactionPropagationController:23 ] - createUserWrong failed, reason:invalid status + + +你马上就会意识到，不对呀，因为运行时异常逃出了 @Transactional 注解标记的 createUserWrong 方法，Spring 当然会回滚事务了。如果我们希望主方法不回滚，应该把子方法抛出的异常捕获了。 + +也就是这么改，把 subUserService.createSubUserWithExceptionWrong 包裹上 catch，这样外层主方法就不会出现异常了： + +@Transactional +public void createUserWrong2(UserEntity entity) { + createMainUser(entity); + + try{ + subUserService.createSubUserWithExceptionWrong(entity); + } catch (Exception ex) { + // 虽然捕获了异常，但是因为没有开启新事务，而当前事务因为异常已经被标记为rollback了，所以最终还是会回滚。 + log.error("create sub user error:{}", ex.getMessage()); + } +} + + +运行程序后可以看到如下日志： + +[22:57:21.722] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :370 ] - Creating new transaction with name [org.geekbang.time.commonmistakes.transaction.demo3.UserService.createUserWrong2]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT +[22:57:21.739] [http-nio-45678-exec-3] [INFO ] [t.c.transaction.demo3.SubUserService:19 ] - createSubUserWithExceptionWrong start +[22:57:21.739] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :356 ] - Found thread-bound EntityManager [SessionImpl(1794007607)] for JPA transaction +[22:57:21.739] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :471 ] - Participating in existing transaction +[22:57:21.740] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :843 ] - Participating transaction failed - marking existing transaction as rollback-only +[22:57:21.740] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :580 ] - Setting JPA transaction on EntityManager [SessionImpl(1794007607)] rollback-only +[22:57:21.740] [http-nio-45678-exec-3] [ERROR] [.g.t.c.transaction.demo3.UserService:37 ] - create sub user error:invalid status +[22:57:21.740] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :741 ] - Initiating transaction commit +[22:57:21.740] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :529 ] - Committing JPA transaction on EntityManager [SessionImpl(1794007607)] +[22:57:21.743] [http-nio-45678-exec-3] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :620 ] - Closing JPA EntityManager [SessionImpl(1794007607)] after transaction +[22:57:21.743] [http-nio-45678-exec-3] [ERROR] [t.d.TransactionPropagationController:33 ] - createUserWrong2 failed, reason:Transaction silently rolled back because it has been marked as rollback-only +org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only +... + + +需要注意以下几点： + +如第 1 行所示，对 createUserWrong2 方法开启了异常处理； + +如第 5 行所示，子方法因为出现了运行时异常，标记当前事务为回滚； + +如第 7 行所示，主方法的确捕获了异常打印出了 create sub user error 字样； + +如第 9 行所示，主方法提交了事务； + +奇怪的是，如第 11 行和 12 行所示，Controller 里出现了一个 UnexpectedRollbackException，异常描述提示最终这个事务回滚了，而且是静默回滚的。之所以说是静默，是因为 createUserWrong2 方法本身并没有出异常，只不过提交后发现子方法已经把当前事务设置为了回滚，无法完成提交。 + +这挺反直觉的。我们之前说，出了异常事务不一定回滚，这里说的却是不出异常，事务也不一定可以提交。原因是，主方法注册主用户的逻辑和子方法注册子用户的逻辑是同一个事务，子逻辑标记了事务需要回滚，主逻辑自然也不能提交了。 + +看到这里，修复方式就很明确了，想办法让子逻辑在独立事务中运行，也就是改一下 SubUserService 注册子用户的方法，为注解加上 propagation = Propagation.REQUIRES_NEW 来设置 REQUIRES_NEW 方式的事务传播策略，也就是执行到这个方法时需要开启新的事务，并挂起当前事务： + +@Transactional(propagation = Propagation.REQUIRES_NEW) +public void createSubUserWithExceptionRight(UserEntity entity) { + log.info("createSubUserWithExceptionRight start"); + userRepository.save(entity); + throw new RuntimeException("invalid status"); +} + + +主方法没什么变化，同样需要捕获异常，防止异常漏出去导致主事务回滚，重新命名为 createUserRight： + +@Transactional +public void createUserRight(UserEntity entity) { + createMainUser(entity); + try{ + subUserService.createSubUserWithExceptionRight(entity); + } catch (Exception ex) { + // 捕获异常，防止主方法回滚 + log.error("create sub user error:{}", ex.getMessage()); + } +} + + +改造后，重新运行程序可以看到如下的关键日志： + +第 1 行日志提示我们针对 createUserRight 方法开启了主方法的事务； + +第 2 行日志提示创建主用户完成； + +第 3 行日志可以看到主事务挂起了，开启了一个新的事务，针对 createSubUserWithExceptionRight 方案，也就是我们的创建子用户的逻辑； + +第 4 行日志提示子方法事务回滚； + +第 5 行日志提示子方法事务完成，继续主方法之前挂起的事务； + +第 6 行日志提示主方法捕获到了子方法的异常； + +第 8 行日志提示主方法的事务提交了，随后我们在 Controller 里没看到静默回滚的异常。 + +[23:17:20.935] [http-nio-45678-exec-1] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :370 ] - Creating new transaction with name [org.geekbang.time.commonmistakes.transaction.demo3.UserService.createUserRight]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT +[23:17:21.079] [http-nio-45678-exec-1] [INFO ] [.g.t.c.transaction.demo3.UserService:55 ] - createMainUser finish +[23:17:21.082] [http-nio-45678-exec-1] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :420 ] - Suspending current transaction, creating new transaction with name [org.geekbang.time.commonmistakes.transaction.demo3.SubUserService.createSubUserWithExceptionRight] +[23:17:21.153] [http-nio-45678-exec-1] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :834 ] - Initiating transaction rollback +[23:17:21.160] [http-nio-45678-exec-1] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :1009] - Resuming suspended transaction after completion of inner transaction +[23:17:21.161] [http-nio-45678-exec-1] [ERROR] [.g.t.c.transaction.demo3.UserService:49 ] - create sub user error:invalid status +[23:17:21.161] [http-nio-45678-exec-1] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :741 ] - Initiating transaction commit +[23:17:21.161] [http-nio-45678-exec-1] [DEBUG] [o.s.orm.jpa.JpaTransactionManager :529 ] - Committing JPA transaction on EntityManager [SessionImpl(396441411)] + + +运行测试程序看到如下结果，getUserCount 得到的用户数量为 1，代表只有一个用户也就是主用户注册完成了，符合预期： + + + +重点回顾 + +今天，我针对业务代码中最常见的使用数据库事务的方式，即 Spring 声明式事务，与你总结了使用上可能遇到的三类坑，包括： + +第一，因为配置不正确，导致方法上的事务没生效。我们务必确认调用 @Transactional 注解标记的方法是 public 的，并且是通过 Spring 注入的 Bean 进行调用的。 + +第二，因为异常处理不正确，导致事务虽然生效但出现异常时没回滚。Spring 默认只会对标记 @Transactional 注解的方法出现了 RuntimeException 和 Error 的时候回滚，如果我们的方法捕获了异常，那么需要通过手动编码处理事务回滚。如果希望 Spring 针对其他异常也可以回滚，那么可以相应配置 @Transactional 注解的 rollbackFor 和 noRollbackFor 属性来覆盖其默认设置。 + +第三，如果方法涉及多次数据库操作，并希望将它们作为独立的事务进行提交或回滚，那么我们需要考虑进一步细化配置事务传播方式，也就是 @Transactional 注解的 Propagation 属性。 + +可见，正确配置事务可以提高业务项目的健壮性。但，又因为健壮性问题往往体现在异常情况或一些细节处理上，很难在主流程的运行和测试中发现，导致业务代码的事务处理逻辑往往容易被忽略，因此我在代码审查环节一直很关注事务是否正确处理。 + +如果你无法确认事务是否真正生效，是否按照预期的逻辑进行，可以尝试打开 Spring 的部分 Debug 日志，通过事务的运作细节来验证。也建议你在单元测试时尽量覆盖多的异常场景，这样在重构时，也能及时发现因为方法的调用方式、异常处理逻辑的调整，导致的事务失效问题。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +考虑到 Demo 的简洁，文中所有数据访问使用的都是 Spring Data JPA。国内大多数互联网业务项目是使用 MyBatis 进行数据访问的，使用 MyBatis 配合 Spring 的声明式事务也同样需要注意文中提到的这些点。你可以尝试把今天的 Demo 改为 MyBatis 做数据访问实现，看看日志中是否可以体现出这些坑。 + +在第一节中我们提到，如果要针对 private 方法启用事务，动态代理方式的 AOP 不可行，需要使用静态织入方式的 AOP，也就是在编译期间织入事务增强代码，可以配置 Spring 框架使用 AspectJ 来实现 AOP。你能否参阅 Spring 的文档“Using @Transactional with AspectJ”试试呢？注意：AspectJ 配合 lombok 使用，还可能会踩一些坑。 + +有关数据库事务，你还遇到过其他坑吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/07数据库索引：索引并不是万能药.md b/专栏/Java业务开发常见错误100例/07数据库索引：索引并不是万能药.md new file mode 100644 index 0000000..3aa89ee --- /dev/null +++ b/专栏/Java业务开发常见错误100例/07数据库索引：索引并不是万能药.md @@ -0,0 +1,371 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 07 数据库索引：索引并不是万能药 + 今天，我要和你分享的主题是，数据库的索引并不是万能药。 + +几乎所有的业务项目都会涉及数据存储，虽然当前各种 NoSQL 和文件系统大行其道，但 MySQL 等关系型数据库因为满足 ACID、可靠性高、对开发友好等特点，仍然最常被用于存储重要数据。在关系型数据库中，索引是优化查询性能的重要手段。 + +为此，我经常看到一些同学一遇到查询性能问题，就盲目要求运维或 DBA 给数据表相关字段创建大量索引。显然，这种想法是错误的。今天，我们就以 MySQL 为例来深入理解下索引的原理，以及相关误区。 + +InnoDB 是如何存储数据的？ + +MySQL 把数据存储和查询操作抽象成了存储引擎，不同的存储引擎，对数据的存储和读取方式各不相同。MySQL 支持多种存储引擎，并且可以以表为粒度设置存储引擎。因为支持事务，我们最常使用的是 InnoDB。为方便理解下面的内容，我先和你简单说说 InnoDB 是如何存储数据的。 + +虽然数据保存在磁盘中，但其处理是在内存中进行的。为了减少磁盘随机读取次数，InnoDB 采用页而不是行的粒度来保存数据，即数据被分成若干页，以页为单位保存在磁盘中。InnoDB 的页大小，一般是 16KB。 + +各个数据页组成一个双向链表，每个数据页中的记录按照主键顺序组成单向链表；每一个数据页中有一个页目录，方便按照主键查询记录。数据页的结构如下： + + + +页目录通过槽把记录分成不同的小组，每个小组有若干条记录。如图所示，记录中最前面的小方块中的数字，代表的是当前分组的记录条数，最小和最大的槽指向 2 个特殊的伪记录。有了槽之后，我们按照主键搜索页中记录时，就可以采用二分法快速搜索，无需从最小记录开始遍历整个页中的记录链表。 + +举一个例子，如果要搜索主键（PK）=15 的记录： + +先二分得出槽中间位是 (0+6)/2=3，看到其指向的记录是 12＜15，所以需要从 #3 槽后继续搜索记录； + +再使用二分搜索出 #3 槽和 #6 槽的中间位是 (3+6)/2=4.5 取整 4，#4 槽对应的记录是 16＞15，所以记录一定在 #4 槽中； + +再从 #3 槽指向的 12 号记录开始向下搜索 3 次，定位到 15 号记录。 + +理解了 InnoDB 存储数据的原理后，我们就可以继续学习 MySQL 索引相关的原理和坑了。 + +聚簇索引和二级索引 + +说到索引，页目录就是最简单的索引，是通过对记录进行一级分组来降低搜索的时间复杂度。但，这样能够降低的时间复杂度数量级，非常有限。当有无数个数据页来存储表数据的时候，我们就需要考虑如何建立合适的索引，才能方便定位记录所在的页。 + +为了解决这个问题，InnoDB 引入了 B+ 树。如下图所示，B+ 树是一棵倒过来的树： + + + +B+ 树的特点包括： + +最底层的节点叫作叶子节点，用来存放数据； + +其他上层节点叫作非叶子节点，仅用来存放目录项，作为索引； + +非叶子节点分为不同层次，通过分层来降低每一层的搜索量； + +所有节点按照索引键大小排序，构成一个双向链表，加速范围查找。 + +因此，InnoDB 使用 B+ 树，既可以保存实际数据，也可以加速数据搜索，这就是聚簇索引。如果把上图叶子节点下面方块中的省略号看作实际数据的话，那么它就是聚簇索引的示意图。由于数据在物理上只会保存一份，所以包含实际数据的聚簇索引只能有一个。 + +InnoDB 会自动使用主键（唯一定义一条记录的单个或多个字段）作为聚簇索引的索引键（如果没有主键，就选择第一个不包含 NULL 值的唯一列）。上图方框中的数字代表了索引键的值，对聚簇索引而言一般就是主键。 + +我们再看看 B+ 树如何实现快速查找主键。比如，我们要搜索 PK=4 的数据，通过根节点中的索引可以知道数据在第一个记录指向的 2 号页中，通过 2 号页的索引又可以知道数据在 5 号页，5 号页就是实际的数据页，然后再通过二分法查找页目录马上可以找到记录的指针。 + +为了实现非主键字段的快速搜索，就引出了二级索引，也叫作非聚簇索引、辅助索引。二级索引，也是利用的 B+ 树的数据结构，如下图所示： + + + +这次二级索引的叶子节点中保存的不是实际数据，而是主键，获得主键值后去聚簇索引中获得数据行。这个过程就叫作回表。 + +举个例子，有个索引是针对用户名字段创建的，索引记录上面方块中的字母是用户名，按照顺序形成链表。如果我们要搜索用户名为 b 的数据，经过两次定位可以得出在 #5 数据页中，查出所有的主键为 7 和 6，再拿着这两个主键继续使用聚簇索引进行两次回表得到完整数据。 + +考虑额外创建二级索引的代价 + +创建二级索引的代价，主要表现在维护代价、空间代价和回表代价三个方面。接下来，我就与你仔细分析下吧。 + +首先是维护代价。创建 N 个二级索引，就需要再创建 N 棵 B+ 树，新增数据时不仅要修改聚簇索引，还需要修改这 N 个二级索引。 + +我们通过实验测试一下创建索引的代价。假设有一个 person 表，有主键 ID，以及 name、score、create_time 三个字段： + +CREATE TABLE `person` ( + `id` bigint(20) NOT NULL AUTO_INCREMENT, + `name` varchar(255) NOT NULL, + `score` int(11) NOT NULL, + `create_time` timestamp NOT NULL, + PRIMARY KEY (`id`) +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; + + +通过下面的存储过程循环创建 10 万条测试数据，我的机器的耗时是 140 秒（本文的例子均在 MySQL 5.7.26 中执行）： + +CREATE DEFINER=`root`@`%` PROCEDURE `insert_person`() +begin + declare c_id integer default 1; + while c_id<=100000 do + insert into person values(c_id, concat('name',c_id), c_id+100, date_sub(NOW(), interval c_id second)); + set c_id=c_id+1; + end while; +end + + +如果再创建两个索引，一个是 name 和 score 构成的联合索引，另一个是单一列 create_time 的索引，那么创建 10 万条记录的耗时提高到 154 秒： + +KEY `name_score` (`name`,`score`) USING BTREE, +KEY `create_time` (`create_time`) USING BTREE + + +这里，我再额外提一下，页中的记录都是按照索引值从小到大的顺序存放的，新增记录就需要往页中插入数据，现有的页满了就需要新创建一个页，把现有页的部分数据移过去，这就是页分裂；如果删除了许多数据使得页比较空闲，还需要进行页合并。页分裂和合并，都会有 IO 代价，并且可能在操作过程中产生死锁。 + +你可以查看这个文档，以进一步了解如何设置合理的合并阈值，来平衡页的空闲率和因为再次页分裂产生的代价。 + +其次是空间代价。虽然二级索引不保存原始数据，但要保存索引列的数据，所以会占用更多的空间。比如，person 表创建了两个索引后，使用下面的 SQL 查看数据和索引占用的磁盘： + +DATA_LENGTH, INDEX_LENGTH FROM information_schema.TABLES WHERE TABLE_NAME='person' + + +结果显示，数据本身只占用了 4.7M，而索引占用了 8.4M。 + +最后是回表的代价。二级索引不保存原始数据，通过索引找到主键后需要再查询聚簇索引，才能得到我们要的数据。比如，使用 SELECT * 按照 name 字段查询用户，使用 EXPLAIN 查看执行计划： + +EXPLAIN SELECT * FROM person WHERE NAME='name1' + + +执行计划如下，可以发现： + + + +key 字段代表实际走的是哪个索引，其值是 name_score，说明走的是 name_score 这个索引。 + +type 字段代表了访问表的方式，其值 ref 说明是二级索引等值匹配，符合我们的查询。 + +把 SQL 中的 * 修改为 NAME 和 SCORE，也就是 SELECT name_score 联合索引包含的两列： + +EXPLAIN SELECT NAME,SCORE FROM person WHERE NAME='name1' + + +再来看看执行计划： + + + +可以看到，Extra 列多了一行 Using index 的提示，证明这次查询直接查的是二级索引，免去了回表。 + +原因很简单，联合索引中其实保存了多个索引列的值，对于页中的记录先按照字段 1 排序，如果相同再按照字段 2 排序，如图所示： + + + +图中，叶子节点每一条记录的第一和第二个方块是索引列的数据，第三个方块是记录的主键。如果我们需要查询的是索引列索引或联合索引能覆盖的数据，那么查询索引本身已经“覆盖”了需要的数据，不再需要回表查询。因此，这种情况也叫作索引覆盖。我会在最后一小节介绍如何查看不同查询的成本，和你一起看看索引覆盖和索引查询后回表的代价差异。 + +最后，我和你总结下关于索引开销的最佳实践吧。 + +第一，无需一开始就建立索引，可以等到业务场景明确后，或者是数据量超过 1 万、查询变慢后，再针对需要查询、排序或分组的字段创建索引。创建索引后可以使用 EXPLAIN 命令，确认查询是否可以使用索引。我会在下一小节展开说明。 + +第二，尽量索引轻量级的字段，比如能索引 int 字段就不要索引 varchar 字段。索引字段也可以是部分前缀，在创建的时候指定字段索引长度。针对长文本的搜索，可以考虑使用 Elasticsearch 等专门用于文本搜索的索引数据库。 + +第三，尽量不要在 SQL 语句中 SELECT *，而是 SELECT 必要的字段，甚至可以考虑使用联合索引来包含我们要搜索的字段，既能实现索引加速，又可以避免回表的开销。 + +不是所有针对索引列的查询都能用上索引 + +在上一个案例中，我创建了一个 name+score 的联合索引，仅搜索 name 时就能够用上这个联合索引。这就引出两个问题： + +是不是建了索引一定可以用上？ + +怎么选择创建联合索引还是多个独立索引？ + +首先，我们通过几个案例来分析一下索引失效的情况。 + +第一，索引只能匹配列前缀。比如下面的 LIKE 语句，搜索 name 后缀为 name123 的用户无法走索引，执行计划的 type=ALL 代表了全表扫描： + +EXPLAIN SELECT * FROM person WHERE NAME LIKE '%name123' LIMIT 100 + + + + +把百分号放到后面走前缀匹配，type=range 表示走索引扫描，key=name_score 看到实际走了 name_score 索引： + +EXPLAIN SELECT * FROM person WHERE NAME LIKE 'name123%' LIMIT 100 + + + + +原因很简单，索引 B+ 树中行数据按照索引值排序，只能根据前缀进行比较。如果要按照后缀搜索也希望走索引的话，并且永远只是按照后缀搜索的话，可以把数据反过来存，用的时候再倒过来。 + +第二，条件涉及函数操作无法走索引。比如搜索条件用到了 LENGTH 函数，肯定无法走索引： + +EXPLAIN SELECT * FROM person WHERE LENGTH(NAME)=7 + + + + +同样的原因，索引保存的是索引列的原始值，而不是经过函数计算后的值。如果需要针对函数调用走数据库索引的话，只能保存一份函数变换后的值，然后重新针对这个计算列做索引。 + +第三，联合索引只能匹配左边的列。也就是说，虽然对 name 和 score 建了联合索引，但是仅按照 score 列搜索无法走索引： + +EXPLAIN SELECT * FROM person WHERE SCORE>45678 + + + + +原因也很简单，在联合索引的情况下，数据是按照索引第一列排序，第一列数据相同时才会按照第二列排序。也就是说，如果我们想使用联合索引中尽可能多的列，查询条件中的各个列必须是联合索引中从最左边开始连续的列。如果我们仅仅按照第二列搜索，肯定无法走索引。尝试把搜索条件加入 name 列，可以看到走了 name_score 索引： + +EXPLAIN SELECT * FROM person WHERE SCORE>45678 AND NAME LIKE 'NAME45%' + + + + +需要注意的是，因为有查询优化器，所以 name 作为 WHERE 子句的第几个条件并不是很重要。 + +现在回到最开始的两个问题。 + +是不是建了索引一定可以用上？并不是，只有当查询能符合索引存储的实际结构时，才能用上。这里，我只给出了三个肯定用不上索引的反例。其实，有的时候即使可以走索引，MySQL 也不一定会选择使用索引。我会在下一小节展开这一点。 + +怎么选择建联合索引还是多个独立索引？如果你的搜索条件经常会使用多个字段进行搜索，那么可以考虑针对这几个字段建联合索引；同时，针对多字段建立联合索引，使用索引覆盖的可能更大。如果只会查询单个字段，可以考虑建单独的索引，毕竟联合索引保存了不必要字段也有成本。 + +数据库基于成本决定是否走索引 + +通过前面的案例，我们可以看到，查询数据可以直接在聚簇索引上进行全表扫描，也可以走二级索引扫描后到聚簇索引回表。看到这里，你不禁要问了，MySQL 到底是怎么确定走哪种方案的呢。 + +其实，MySQL 在查询数据之前，会先对可能的方案做执行计划，然后依据成本决定走哪个执行计划。 + +这里的成本，包括 IO 成本和 CPU 成本： + +IO 成本，是从磁盘把数据加载到内存的成本。默认情况下，读取数据页的 IO 成本常数是 1（也就是读取 1 个页成本是 1）。 + +CPU 成本，是检测数据是否满足条件和排序等 CPU 操作的成本。默认情况下，检测记录的成本是 0.2。 + +基于此，我们分析下全表扫描的成本。 + +全表扫描，就是把聚簇索引中的记录依次和给定的搜索条件做比较，把符合搜索条件的记录加入结果集的过程。那么，要计算全表扫描的代价需要两个信息： + +聚簇索引占用的页面数，用来计算读取数据的 IO 成本； + +表中的记录数，用来计算搜索的 CPU 成本。 + +那么，MySQL 是实时统计这些信息的吗？其实并不是，MySQL 维护了表的统计信息，可以使用下面的命令查看： + +SHOW TABLE STATUS LIKE 'person' + + +输出如下： + + + +可以看到： + +总行数是 100086 行（之前 EXPLAIN 时，也看到 rows 为 100086）。你可能说，person 表不是有 10 万行记录吗，为什么这里多了 86 行？其实，MySQL 的统计信息是一个估算，其统计方式比较复杂我就不再展开了。但不妨碍我们根据这个值估算 CPU 成本，是 100086*0.2=20017 左右。 + +数据长度是 4734976 字节。对于 InnoDB 来说，这就是聚簇索引占用的空间，等于聚簇索引的页面数量 * 每个页面的大小。InnoDB 每个页面的大小是 16KB，大概计算出页面数量是 289，因此 IO 成本是 289 左右。 + +所以，全表扫描的总成本是 20306 左右。 + +接下来，我还是用 person 表这个例子，和你分析下 MySQL 如何基于成本来制定执行计划。现在，我要用下面的 SQL 查询 name>‘name84059’ AND create_time>‘2020-01-24 05:00:00’ + +EXPLAIN SELECT * FROM person WHERE NAME >'name84059' AND create_time>'2020-01-24 05:00:00' + + +其执行计划是全表扫描： + + + +只要把 create_time 条件中的 5 点改为 6 点就变为走索引了，并且走的是 create_time 索引而不是 name_score 联合索引： + + + +我们可以得到两个结论： + +MySQL 选择索引，并不是按照 WHERE 条件中列的顺序进行的； + +即便列有索引，甚至有多个可能的索引方案，MySQL 也可能不走索引。 + +其原因就是，MySQL 并不是猜拳决定是否走索引的，而是根据成本来判断的。虽然表的统计信息不完全准确，但足够用于策略的判断了。 + +不过，有时会因为统计信息的不准确或成本估算的问题，实际开销会和 MySQL 统计出来的差距较大，导致 MySQL 选择错误的索引或是直接选择走全表扫描，这个时候就需要人工干预，使用强制索引了。比如，像这样强制走 name_score 索引： + +EXPLAIN SELECT * FROM person FORCE INDEX(name_score) WHERE NAME >'name84059' AND create_time>'2020-01-24 05:00:00' + + +我们介绍了 MySQL 会根据成本选择执行计划，也通过 EXPLAIN 知道了优化器最终会选择怎样的执行计划，但 MySQL 如何制定执行计划始终是一个黑盒。那么，有没有什么办法可以了解各种执行计划的成本，以及 MySQL 做出选择的依据呢？ + +在 MySQL 5.6 及之后的版本中，我们可以使用 optimizer trace 功能查看优化器生成执行计划的整个过程。有了这个功能，我们不仅可以了解优化器的选择过程，更可以了解每一个执行环节的成本，然后依靠这些信息进一步优化查询。 + +如下代码所示，打开 optimizer_trace 后，再执行 SQL 就可以查询 information_schema.OPTIMIZER_TRACE 表查看执行计划了，最后可以关闭 optimizer_trace 功能： + +SET optimizer_trace="enabled=on"; +SELECT * FROM person WHERE NAME >'name84059' AND create_time>'2020-01-24 05:00:00'; +SELECT * FROM information_schema.OPTIMIZER_TRACE; +SET optimizer_trace="enabled=off"; + + +对于按照 create_time>‘2020-01-24 05:00:00’条件走全表扫描的 SQL，我从 OPTIMIZER_TRACE 的执行结果中，摘出了几个重要片段来重点分析： + +使用 name_score 对 name84059 name 条件进行索引扫描需要扫描 25362 行，成本是 30435，因此最终没有选择这个方案。这里的 30435 是查询二级索引的 IO 成本和 CPU 成本之和，再加上回表查询聚簇索引的 IO 成本和 CPU 成本之和，我就不再具体分析了： + +{ + "index": "name_score", + "ranges": [ + "name84059 < name" + ], + "rows": 25362, + "cost": 30435, + "chosen": false, + "cause": "cost" +}, + + +使用 create_time 进行索引扫描需要扫描 23758 行，成本是 28511，同样因为成本原因没有选择这个方案： + +{ + "index": "create_time", + "ranges": [ + "0x5e2a79d0 < create_time" + ], + "rows": 23758, + "cost": 28511, + "chosen": false, + "cause": "cost" +} + + +最终选择了全表扫描方式作为执行计划。可以看到，全表扫描 100086 条记录的成本是 20306，和我们之前计算的一致，显然是小于其他两个方案的 28511 和 30435： + +{ + "considered_execution_plans": [{ + "table": "`person`", + "best_access_path": { + "considered_access_paths": [{ + "rows_to_scan": 100086, + "access_type": "scan", + "resulting_rows": 100086, + "cost": 20306, + "chosen": true + }] + }, + "rows_for_plan": 100086, + "cost_for_plan": 20306, + "chosen": true + }] +}, + + +把 SQL 中的 create_time 条件从 05:00 改为 06:00，再次分析 OPTIMIZER_TRACE 可以看到，这次执行计划选择的是走 create_time 索引。因为是查询更晚时间的数据，走 create_time 索引需要扫描的行数从 23758 减少到了 16588。这次走这个索引的成本 19907 小于全表扫描的 20306，更小于走 name_score 索引的 30435： + +{ + "index": "create_time", + "ranges": [ + "0x5e2a87e0 < create_time" + ], + "rows": 16588, + "cost": 19907, + "chosen": true +} + + +有关 optimizer trace 的更多信息，你可以参考MySQL 的文档。 + +重点回顾 + +今天，我先和你分析了 MySQL InnoDB 存储引擎页、聚簇索引和二级索引的结构，然后分析了关于索引的两个误区。 + +第一个误区是，考虑到索引的维护代价、空间占用和查询时回表的代价，不能认为索引越多越好。索引一定是按需创建的，并且要尽可能确保足够轻量。一旦创建了多字段的联合索引，我们要考虑尽可能利用索引本身完成数据查询，减少回表的成本。 + +第二个误区是，不能认为建了索引就一定有效，对于后缀的匹配查询、查询中不包含联合索引的第一列、查询条件涉及函数计算等情况无法使用索引。此外，即使 SQL 本身符合索引的使用条件，MySQL 也会通过评估各种查询方式的代价，来决定是否走索引，以及走哪个索引。 + +因此，在尝试通过索引进行 SQL 性能优化的时候，务必通过执行计划或实际的效果来确认索引是否能有效改善性能问题，否则增加了索引不但没解决性能问题，还增加了数据库增删改的负担。如果对 EXPLAIN 给出的执行计划有疑问的话，你还可以利用 optimizer_trace 查看详细的执行计划做进一步分析。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在介绍二级索引代价时，我们通过 EXPLAIN 命令看到了索引覆盖和回表的两种情况。你能用 optimizer trace 来分析一下这两种情况的成本差异吗？ + +索引除了可以用于加速搜索外，还可以在排序时发挥作用，你能通过 EXPLAIN 来证明吗？你知道，在什么情况下针对排序索引会失效吗？ + +针对数据库索引，你还有什么心得吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/08判等问题：程序里如何确定你就是你？.md b/专栏/Java业务开发常见错误100例/08判等问题：程序里如何确定你就是你？.md new file mode 100644 index 0000000..8da74de --- /dev/null +++ b/专栏/Java业务开发常见错误100例/08判等问题：程序里如何确定你就是你？.md @@ -0,0 +1,676 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 08 判等问题：程序里如何确定你就是你？ + 今天，我来和你聊聊程序里的判等问题。 + +你可能会说，判等不就是一行代码的事情吗，有什么好说的。但，这一行代码如果处理不当，不仅会出现 Bug，还可能会引起内存泄露等问题。涉及判等的 Bug，即使是使用 == 这种错误的判等方式，也不是所有时候都会出问题。所以类似的判等问题不太容易发现，可能会被隐藏很久。 + +今天，我就 equals、compareTo 和 Java 的数值缓存、字符串驻留等问题展开讨论，希望你可以理解其原理，彻底消除业务代码中的相关 Bug。 + +注意 equals 和 == 的区别 + +在业务代码中，我们通常使用 equals 或 == 进行判等操作。equals 是方法而 == 是操作符，它们的使用是有区别的： + +对基本类型，比如 int、long，进行判等，只能使用 ==，比较的是直接值。因为基本类型的值就是其数值。 + +对引用类型，比如 Integer、Long 和 String，进行判等，需要使用 equals 进行内容判等。因为引用类型的直接值是指针，使用 == 的话，比较的是指针，也就是两个对象在内存中的地址，即比较它们是不是同一个对象，而不是比较对象的内容。 + +这就引出了我们必须必须要知道的第一个结论：比较值的内容，除了基本类型只能使用 == 外，其他类型都需要使用 equals。 + +在开篇我提到了，即使使用 == 对 Integer 或 String 进行判等，有些时候也能得到正确结果。这又是为什么呢？ + +我们用下面的测试用例深入研究下： + +使用 == 对两个值为 127 的直接赋值的 Integer 对象判等； + +使用 == 对两个值为 128 的直接赋值的 Integer 对象判等； + +使用 == 对一个值为 127 的直接赋值的 Integer 和另一个通过 new Integer 声明的值为 127 的对象判等； + +使用 == 对两个通过 new Integer 声明的值为 127 的对象判等； + +使用 == 对一个值为 128 的直接赋值的 Integer 对象和另一个值为 128 的 int 基本类型判等。 + +Integer a = 127; //Integer.valueOf(127) +Integer b = 127; //Integer.valueOf(127) +log.info("\nInteger a = 127;\n" + + "Integer b = 127;\n" + + "a == b ? {}",a == b); // true +Integer c = 128; //Integer.valueOf(128) +Integer d = 128; //Integer.valueOf(128) +log.info("\nInteger c = 128;\n" + + "Integer d = 128;\n" + + "c == d ? {}", c == d); //false +Integer e = 127; //Integer.valueOf(127) +Integer f = new Integer(127); //new instance +log.info("\nInteger e = 127;\n" + + "Integer f = new Integer(127);\n" + + "e == f ? {}", e == f); //false +Integer g = new Integer(127); //new instance +Integer h = new Integer(127); //new instance +log.info("\nInteger g = new Integer(127);\n" + + "Integer h = new Integer(127);\n" + + "g == h ? {}", g == h); //false +Integer i = 128; //unbox +int j = 128; + +log.info("\nInteger i = 128;\n" + + "int j = 128;\n" + + "i == j ? {}", i == j); //true + + +通过运行结果可以看到，虽然看起来永远是在对 127 和 127、128 和 128 判等，但 == 却没有永远给我们 true 的答复。原因是什么呢？ + +第一个案例中，编译器会把 Integer a = 127 转换为 Integer.valueOf(127)。查看源码可以发现，这个转换在内部其实做了缓存，使得两个 Integer 指向同一个对象，所以 == 返回 true。 + +public static Integer valueOf(int i) { + + if (i >= IntegerCache.low && i <= IntegerCache.high) + return IntegerCache.cache[i + (-IntegerCache.low)]; + return new Integer(i); +} + + +第二个案例中，之所以同样的代码 128 就返回 false 的原因是，默认情况下会缓存[-128, 127]的数值，而 128 处于这个区间之外。设置 JVM 参数加上 -XX:AutoBoxCacheMax=1000 再试试，是不是就返回 true 了呢？ + +private static class IntegerCache { + + static final int low = -128; + static final int high; + + static { + // high value may be configured by property + int h = 127; + String integerCacheHighPropValue = + sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high"); + if (integerCacheHighPropValue != null) { + try { + int i = parseInt(integerCacheHighPropValue); + i = Math.max(i, 127); + // Maximum array size is Integer.MAX_VALUE + h = Math.min(i, Integer.MAX_VALUE - (-low) -1); + } catch( NumberFormatException nfe) { + // If the property cannot be parsed into an int, ignore it. + } + } + high = h; + + cache = new Integer[(high - low) + 1]; + int j = low; + for(int k = 0; k < cache.length; k++) + cache[k] = new Integer(j++); + + // range [-128, 127] must be interned (JLS7 5.1.7) + assert IntegerCache.high >= 127; + } +} + + +第三和第四个案例中，New 出来的 Integer 始终是不走缓存的新对象。比较两个新对象，或者比较一个新对象和一个来自缓存的对象，结果肯定不是相同的对象，因此返回 false。 + +第五个案例中，我们把装箱的 Integer 和基本类型 int 比较，前者会先拆箱再比较，比较的肯定是数值而不是引用，因此返回 true。 + +看到这里，对于 Integer 什么时候是相同对象什么时候是不同对象，就很清楚了吧。但知道这些其实意义不大，因为在大多数时候，我们并不关心 Integer 对象是否是同一个，只需要记得比较 Integer 的值请使用 equals，而不是 ==（对于基本类型 int 的比较当然只能使用 ==）。 + +其实，我们应该都知道这个原则，只是有的时候特别容易忽略。以我之前遇到过的一个生产事故为例，有这么一个枚举定义了订单状态和对于状态的描述： + +enum StatusEnum { + + CREATED(1000, "已创建"), + PAID(1001, "已支付"), + DELIVERED(1002, "已送到"), + FINISHED(1003, "已完成"); + + private final Integer status; //注意这里的Integer + + private final String desc; + + StatusEnum(Integer status, String desc) { + this.status = status; + this.desc = desc; + } +} + + +在业务代码中，开发同学使用了 == 对枚举和入参 OrderQuery 中的 status 属性进行判等： + +@Data +public class OrderQuery { + + private Integer status; + private String name; + +} + +@PostMapping("enumcompare") +public void enumcompare(@RequestBody OrderQuery orderQuery){ + + StatusEnum statusEnum = StatusEnum.DELIVERED; + + log.info("orderQuery:{} statusEnum:{} result:{}", orderQuery, statusEnum, statusEnum.status == orderQuery.getStatus()); + +} + + +因为枚举和入参 OrderQuery 中的 status 都是包装类型，所以通过 == 判等肯定是有问题的。只是这个问题比较隐晦，究其原因在于： + +只看枚举的定义 CREATED(1000, “已创建”)，容易让人误解 status 值是基本类型； + +因为有 Integer 缓存机制的存在，所以使用 == 判等并不是所有情况下都有问题。在这次事故中，订单状态的值从 100 开始增长，程序一开始不出问题，直到订单状态超过 127 后才出现 Bug。 + +在了解清楚为什么 Integer 使用 == 判等有时候也有效的原因之后，我们再来看看为什么 String 也有这个问题。我们使用几个用例来测试下： + +对两个直接声明的值都为 1 的 String 使用 == 判等； + +对两个 new 出来的值都为 2 的 String 使用 == 判等； + +对两个 new 出来的值都为 3 的 String 先进行 intern 操作，再使用 == 判等； + +对两个 new 出来的值都为 4 的 String 通过 equals 判等。 + +String a = "1"; +String b = "1"; +log.info("\nString a = \"1\";\n" + + "String b = \"1\";\n" + + "a == b ? {}", a == b); //true + +String c = new String("2"); +String d = new String("2"); + +log.info("\nString c = new String(\"2\");\n" + + "String d = new String(\"2\");" + + "c == d ? {}", c == d); //false + +String e = new String("3").intern(); +String f = new String("3").intern(); +log.info("\nString e = new String(\"3\").intern();\n" + + "String f = new String(\"3\").intern();\n" + + "e == f ? {}", e == f); //true + +String g = new String("4"); +String h = new String("4"); +log.info("\nString g = new String(\"4\");\n" + + "String h = new String(\"4\");\n" + + "g == h ? {}", g.equals(h)); //true + + +在分析这个结果之前，我先和你说说 Java 的字符串常量池机制。首先要明确的是其设计初衷是节省内存。当代码中出现双引号形式创建字符串对象时，JVM 会先对这个字符串进行检查，如果字符串常量池中存在相同内容的字符串对象的引用，则将这个引用返回；否则，创建新的字符串对象，然后将这个引用放入字符串常量池，并返回该引用。这种机制，就是字符串驻留或池化。 + +再回到刚才的例子，再来分析一下运行结果： + +第一个案例返回 true，因为 Java 的字符串驻留机制，直接使用双引号声明出来的两个 String 对象指向常量池中的相同字符串。 + +第二个案例，new 出来的两个 String 是不同对象，引用当然不同，所以得到 false 的结果。 + +第三个案例，使用 String 提供的 intern 方法也会走常量池机制，所以同样能得到 true。 + +第四个案例，通过 equals 对值内容判等，是正确的处理方式，当然会得到 true。 + +虽然使用 new 声明的字符串调用 intern 方法，也可以让字符串进行驻留，但在业务代码中滥用 intern，可能会产生性能问题。 + +写代码测试一下，通过循环把 1 到 1000 万之间的数字以字符串形式 intern 后，存入一个 List： + +List list = new ArrayList<>(); + +@GetMapping("internperformance") +public int internperformance(@RequestParam(value = "size", defaultValue = "10000000")int size) { + + //-XX:+PrintStringTableStatistics + //-XX:StringTableSize=10000000 + long begin = System.currentTimeMillis(); + list = IntStream.rangeClosed(1, size) + .mapToObj(i-> String.valueOf(i).intern()) + .collect(Collectors.toList()); + + log.info("size:{} took:{}", size, System.currentTimeMillis() - begin); + return list.size(); +} + + +在启动程序时设置 JVM 参数 -XX:+PrintStringTableStatistic，程序退出时可以打印出字符串常量表的统计信息。调用接口后关闭程序，输出如下： + +[11:01:57.770] [http-nio-45678-exec-2] [INFO ] [.t.c.e.d.IntAndStringEqualController:54 ] - size:10000000 took:44907 +StringTable statistics: +Number of buckets : 60013 = 480104 bytes, avg 8.000 +Number of entries : 10030230 = 240725520 bytes, avg 24.000 +Number of literals : 10030230 = 563005568 bytes, avg 56.131 +Total footprint : = 804211192 bytes +Average bucket size : 167.134 +Variance of bucket size : 55.808 +Std. dev. of bucket size: 7.471 +Maximum bucket size : 198 + + +可以看到，1000 万次 intern 操作耗时居然超过了 44 秒。 + +其实，原因在于字符串常量池是一个固定容量的 Map。如果容量太小（Number of buckets=60013）、字符串太多（1000 万个字符串），那么每一个桶中的字符串数量会非常多，所以搜索起来就很慢。输出结果中的 Average bucket size=167，代表了 Map 中桶的平均长度是 167。 + +解决方式是，设置 JVM 参数 -XX:StringTableSize，指定更多的桶。设置 -XX:StringTableSize=10000000 后，重启应用： + +[11:09:04.475] [http-nio-45678-exec-1] [INFO ] [.t.c.e.d.IntAndStringEqualController:54 ] - size:10000000 took:5557 +StringTable statistics: +Number of buckets : 10000000 = 80000000 bytes, avg 8.000 +Number of entries : 10030156 = 240723744 bytes, avg 24.000 +Number of literals : 10030156 = 562999472 bytes, avg 56.131 +Total footprint : = 883723216 bytes +Average bucket size : 1.003 +Variance of bucket size : 1.587 +Std. dev. of bucket size: 1.260 +Maximum bucket size : 10 + + +可以看到，1000 万次调用耗时只有 5.5 秒，Average bucket size 降到了 1，效果明显。 + +好了，是时候给出第二原则了：没事别轻易用 intern，如果要用一定要注意控制驻留的字符串的数量，并留意常量表的各项指标。 + +实现一个 equals 没有这么简单 + +如果看过 Object 类源码，你可能就知道，equals 的实现其实是比较对象引用： + +public boolean equals(Object obj) { + return (this == obj); +} + + +之所以 Integer 或 String 能通过 equals 实现内容判等，是因为它们都重写了这个方法。比如，String 的 equals 的实现： + +public boolean equals(Object anObject) { + + if (this == anObject) { + return true; + } + + if (anObject instanceof String) { + String anotherString = (String)anObject; + int n = value.length; + if (n == anotherString.value.length) { + char v1[] = value; + char v2[] = anotherString.value; + int i = 0; + while (n-- != 0) { + if (v1[i] != v2[i]) + return false; + i++; + } + return true; + } + } + return false; +} + + +对于自定义类型，如果不重写 equals 的话，默认就是使用 Object 基类的按引用的比较方式。我们写一个自定义类测试一下。 + +假设有这样一个描述点的类 Point，有 x、y 和描述三个属性： + +class Point { + + private int x; + private int y; + private final String desc; + + public Point(int x, int y, String desc) { + this.x = x; + this.y = y; + this.desc = desc; + } +} + + +定义三个点 p1、p2 和 p3，其中 p1 和 p2 的描述属性不同，p1 和 p3 的三个属性完全相同，并写一段代码测试一下默认行为： + +Point p1 = new Point(1, 2, "a"); +Point p2 = new Point(1, 2, "b"); +Point p3 = new Point(1, 2, "a"); + +log.info("p1.equals(p2) ? {}", p1.equals(p2)); +log.info("p1.equals(p3) ? {}", p1.equals(p3)); + + +通过 equals 方法比较 p1 和 p2、p1 和 p3 均得到 false，原因正如刚才所说，我们并没有为 Point 类实现自定义的 equals 方法，Object 超类中的 equals 默认使用 == 判等，比较的是对象的引用。 + +我们期望的逻辑是，只要 x 和 y 这 2 个属性一致就代表是同一个点，所以写出了如下的改进代码，重写 equals 方法，把参数中的 Object 转换为 Point 比较其 x 和 y 属性： + +class PointWrong { + + private int x; + private int y; + + private final String desc; + + public PointWrong(int x, int y, String desc) { + this.x = x; + this.y = y; + this.desc = desc; + } + + @Override + public boolean equals(Object o) { + PointWrong that = (PointWrong) o; + return x == that.x && y == that.y; + } +} + + +为测试改进后的 Point 是否可以满足需求，我们定义了三个用例： + +比较一个 Point 对象和 null； + +比较一个 Object 对象和一个 Point 对象； + +比较两个 x 和 y 属性值相同的 Point 对象。 + +PointWrong p1 = new PointWrong(1, 2, "a"); +try { + log.info("p1.equals(null) ? {}", p1.equals(null)); +} catch (Exception ex) { + log.error(ex.getMessage()); +} + +Object o = new Object(); + +try { + log.info("p1.equals(expression) ? {}", p1.equals(o)); +} catch (Exception ex) { + log.error(ex.getMessage()); +} + +PointWrong p2 = new PointWrong(1, 2, "b"); +log.info("p1.equals(p2) ? {}", p1.equals(p2)); + + +通过日志中的结果可以看到，第一次比较出现了空指针异常，第二次比较出现了类型转换异常，第三次比较符合预期输出了 true。 + +[17:54:39.120] [http-nio-45678-exec-1] [ERROR] [t.c.e.demo1.EqualityMethodController:32 ] - java.lang.NullPointerException +[17:54:39.120] [http-nio-45678-exec-1] [ERROR] [t.c.e.demo1.EqualityMethodController:39 ] - java.lang.ClassCastException: java.lang.Object cannot be cast to org.geekbang.time.commonmistakes.equals.demo1.EqualityMethodController$PointWrong +[17:54:39.120] [http-nio-45678-exec-1] [INFO ] [t.c.e.demo1.EqualityMethodController:43 ] - p1.equals(p2) ? true + + +通过这些失效的用例，我们大概可以总结出实现一个更好的 equals 应该注意的点： + +考虑到性能，可以先进行指针判等，如果对象是同一个那么直接返回 true； + +需要对另一方进行判空，空对象和自身进行比较，结果一定是 fasle； + +需要判断两个对象的类型，如果类型都不同，那么直接返回 false； + +确保类型相同的情况下再进行类型强制转换，然后逐一判断所有字段。 + +修复和改进后的 equals 方法如下： + +@Override +public boolean equals(Object o) { + + if (this == o) return true; + if (o == null || getClass() != o.getClass()) return false; + PointRight that = (PointRight) o; + return x == that.x && y == that.y; +} + + +改进后的 equals 看起来完美了，但还没完。我们继续往下看。 + +hashCode 和 equals 要配对实现 + +我们来试试下面这个用例，定义两个 x 和 y 属性值完全一致的 Point 对象 p1 和 p2，把 p1 加入 HashSet，然后判断这个 Set 中是否存在 p2： + +PointWrong p1 = new PointWrong(1, 2, "a"); +PointWrong p2 = new PointWrong(1, 2, "b"); + +HashSet points = new HashSet<>(); +points.add(p1); +log.info("points.contains(p2) ? {}", points.contains(p2)); + + +按照改进后的 equals 方法，这 2 个对象可以认为是同一个，Set 中已经存在了 p1 就应该包含 p2，但结果却是 false。 + +出现这个 Bug 的原因是，散列表需要使用 hashCode 来定位元素放到哪个桶。如果自定义对象没有实现自定义的 hashCode 方法，就会使用 Object 超类的默认实现，得到的两个 hashCode 是不同的，导致无法满足需求。 + +要自定义 hashCode，我们可以直接使用 Objects.hash 方法来实现，改进后的 Point 类如下： + +class PointRight { + + private final int x; + private final int y; + private final String desc; + + ... + + @Override + public boolean equals(Object o) { + ... + } + + @Override + public int hashCode() { + return Objects.hash(x, y); + } +} + + +改进 equals 和 hashCode 后，再测试下之前的四个用例，结果全部符合预期。 + +[18:25:23.091] [http-nio-45678-exec-4] [INFO ] [t.c.e.demo1.EqualityMethodController:54 ] - p1.equals(null) ? false +[18:25:23.093] [http-nio-45678-exec-4] [INFO ] [t.c.e.demo1.EqualityMethodController:61 ] - p1.equals(expression) ? false +[18:25:23.094] [http-nio-45678-exec-4] [INFO ] [t.c.e.demo1.EqualityMethodController:67 ] - p1.equals(p2) ? true +[18:25:23.094] [http-nio-45678-exec-4] [INFO ] [t.c.e.demo1.EqualityMethodController:71 ] - points.contains(p2) ? true + + +看到这里，你可能会觉得自己实现 equals 和 hashCode 很麻烦，实现 equals 有很多注意点而且代码量很大。不过，实现这两个方法也有简单的方式，一是后面要讲到的 Lombok 方法，二是使用 IDE 的代码生成功能。IDEA 的类代码快捷生成菜单支持的功能如下： + + + +注意 compareTo 和 equals 的逻辑一致性 + +除了自定义类型需要确保 equals 和 hashCode 要逻辑一致外，还有一个更容易被忽略的问题，即 compareTo 同样需要和 equals 确保逻辑一致性。 + +我之前遇到过这么一个问题，代码里本来使用了 ArrayList 的 indexOf 方法进行元素搜索，但是一位好心的开发同学觉得逐一比较的时间复杂度是 O(n)，效率太低了，于是改为了排序后通过 Collections.binarySearch 方法进行搜索，实现了 O(log n) 的时间复杂度。没想到，这么一改却出现了 Bug。 + +我们来重现下这个问题。首先，定义一个 Student 类，有 id 和 name 两个属性，并实现了一个 Comparable 接口来返回两个 id 的值： + +@Data +@AllArgsConstructor +class Student implements Comparable{ + + private int id; + private String name; + + @Override + public int compareTo(Student other) { + + int result = Integer.compare(other.id, id); + if (result==0) + log.info("this {} == other {}", this, other); + return result; + } +} + + +然后，写一段测试代码分别通过 indexOf 方法和 Collections.binarySearch 方法进行搜索。列表中我们存放了两个学生，第一个学生 id 是 1 叫 zhang，第二个学生 id 是 2 叫 wang，搜索这个列表是否存在一个 id 是 2 叫 li 的学生： + +@GetMapping("wrong") +public void wrong(){ + + List list = new ArrayList<>(); + list.add(new Student(1, "zhang")); + list.add(new Student(2, "wang")); + + Student student = new Student(2, "li"); + log.info("ArrayList.indexOf"); + + int index1 = list.indexOf(student); + Collections.sort(list); + log.info("Collections.binarySearch"); + + int index2 = Collections.binarySearch(list, student); + log.info("index1 = " + index1); + log.info("index2 = " + index2); +} + + +代码输出的日志如下： + +[18:46:50.226] [http-nio-45678-exec-1] [INFO ] [t.c.equals.demo2.CompareToController:28 ] - ArrayList.indexOf +[18:46:50.226] [http-nio-45678-exec-1] [INFO ] [t.c.equals.demo2.CompareToController:31 ] - Collections.binarySearch +[18:46:50.227] [http-nio-45678-exec-1] [INFO ] [t.c.equals.demo2.CompareToController:67 ] - this CompareToController.Student(id=2, name=wang) == other CompareToController.Student(id=2, name=li) +[18:46:50.227] [http-nio-45678-exec-1] [INFO ] [t.c.equals.demo2.CompareToController:34 ] - index1 = -1 +[18:46:50.227] [http-nio-45678-exec-1] [INFO ] [t.c.equals.demo2.CompareToController:35 ] - index2 = 1 + + +我们注意到如下几点： + +binarySearch 方法内部调用了元素的 compareTo 方法进行比较； + +indexOf 的结果没问题，列表中搜索不到 id 为 2、name 是 li 的学生； + +binarySearch 返回了索引 1，代表搜索到的结果是 id 为 2，name 是 wang 的学生。 + +修复方式很简单，确保 compareTo 的比较逻辑和 equals 的实现一致即可。重新实现一下 Student 类，通过 Comparator.comparing 这个便捷的方法来实现两个字段的比较： + +@Data +@AllArgsConstructor +class StudentRight implements Comparable{ + + private int id; + private String name; + + @Override + public int compareTo(StudentRight other) { + return Comparator.comparing(StudentRight::getName) + .thenComparingInt(StudentRight::getId) + .compare(this, other); + } +} + + +其实，这个问题容易被忽略的原因在于两方面： + +一是，我们使用了 Lombok 的 @Data 标记了 Student，@Data 注解（详见这里）其实包含了 @EqualsAndHashCode 注解（详见这里）的作用，也就是默认情况下使用类型所有的字段（不包括 static 和 transient 字段）参与到 equals 和 hashCode 方法的实现中。因为这两个方法的实现不是我们自己实现的，所以容易忽略其逻辑。 + +二是，compareTo 方法需要返回数值，作为排序的依据，容易让人使用数值类型的字段随意实现。 + +我再强调下，对于自定义的类型，如果要实现 Comparable，请记得 equals、hashCode、compareTo 三者逻辑一致。 + +小心 Lombok 生成代码的“坑” + +Lombok 的 @Data 注解会帮我们实现 equals 和 hashcode 方法，但是有继承关系时，Lombok 自动生成的方法可能就不是我们期望的了。 + +我们先来研究一下其实现：定义一个 Person 类型，包含姓名和身份证两个字段： + +@Data +class Person { + + private String name; + private String identity; + + public Person(String name, String identity) { + this.name = name; + this.identity = identity; + } +} + + +对于身份证相同、姓名不同的两个 Person 对象： + +Person person1 = new Person("zhuye","001"); +Person person2 = new Person("Joseph","001"); +log.info("person1.equals(person2) ? {}", person1.equals(person2)); + + +使用 equals 判等会得到 false。如果你希望只要身份证一致就认为是同一个人的话，可以使用 @EqualsAndHashCode.Exclude 注解来修饰 name 字段，从 equals 和 hashCode 的实现中排除 name 字段： + +@EqualsAndHashCode.Exclude +private String name; + + +修改后得到 true。打开编译后的代码可以看到，Lombok 为 Person 生成的 equals 方法的实现，确实只包含了 identity 属性： + +public boolean equals(final Object o) { + + if (o == this) { + return true; + } else if (!(o instanceof LombokEquealsController.Person)) { + return false; + } else { + LombokEquealsController.Person other = (LombokEquealsController.Person)o; + if (!other.canEqual(this)) { + return false; + } else { + Object this$identity = this.getIdentity(); + Object other$identity = other.getIdentity(); + if (this$identity == null) { + if (other$identity != null) { + return false; + } + } else if (!this$identity.equals(other$identity)) { + return false; + } + return true; + } + } +} + + +但到这里还没完，如果类型之间有继承，Lombok 会怎么处理子类的 equals 和 hashCode 呢？我们来测试一下，写一个 Employee 类继承 Person，并新定义一个公司属性： + +@Data +class Employee extends Person { + + private String company; + + public Employee(String name, String identity, String company) { + super(name, identity); + this.company = company; + } +} + + +在如下的测试代码中，声明两个 Employee 实例，它们具有相同的公司名称，但姓名和身份证均不同： + +Employee employee1 = new Employee("zhuye","001", "bkjk.com"); +Employee employee2 = new Employee("Joseph","002", "bkjk.com"); + +log.info("employee1.equals(employee2) ? {}", employee1.equals(employee2)); + + +很遗憾，结果是 true，显然是没有考虑父类的属性，而认为这两个员工是同一人，说明 @EqualsAndHashCode 默认实现没有使用父类属性。 + +为解决这个问题，我们可以手动设置 callSuper 开关为 true，来覆盖这种默认行为： + +@Data +@EqualsAndHashCode(callSuper = true) +class Employee extends Person { + + +修改后的代码，实现了同时以子类的属性 company 加上父类中的属性 identity，作为 equals 和 hashCode 方法的实现条件（实现上其实是调用了父类的 equals 和 hashCode）。 + +重点回顾 + +现在，我们来回顾下对象判等和比较的重点内容吧。 + +首先，我们要注意 equals 和 == 的区别。业务代码中进行内容的比较，针对基本类型只能使用 ==，针对 Integer、String 在内的引用类型，需要使用 equals。Integer 和 String 的坑在于，使用 == 判等有时也能获得正确结果。 + +其次，对于自定义类型，如果类型需要参与判等，那么务必同时实现 equals 和 hashCode 方法，并确保逻辑一致。如果希望快速实现 equals、hashCode 方法，我们可以借助 IDE 的代码生成功能，或使用 Lombok 来生成。如果类型也要参与比较，那么 compareTo 方法的逻辑同样需要和 equals、hashCode 方法一致。 + +最后，Lombok 的 @EqualsAndHashCode 注解实现 equals 和 hashCode 的时候，默认使用类型所有非 static、非 transient 的字段，且不考虑父类。如果希望改变这种默认行为，可以使用 @EqualsAndHashCode.Exclude 排除一些字段，并设置 callSuper = true 来让子类的 equals 和 hashCode 调用父类的相应方法。 + +在比较枚举值和 POJO 参数值的例子中，我们还可以注意到，使用 == 来判断两个包装类型的低级错误，确实容易被忽略。所以，我建议你在 IDE 中安装阿里巴巴的 Java 规约插件（详见这里），来及时提示我们这类低级错误： + + + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在实现 equals 时，我是先通过 getClass 方法判断两个对象的类型，你可能会想到还可以使用 instanceof 来判断。你能说说这两种实现方式的区别吗？ + +在第三节的例子中，我演示了可以通过 HashSet 的 contains 方法判断元素是否在 HashSet 中，同样是 Set 的 TreeSet 其 contains 方法和 HashSet 有什么区别吗？ + +有关对象判等、比较，你还遇到过其他坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/09数值计算：注意精度、舍入和溢出问题.md b/专栏/Java业务开发常见错误100例/09数值计算：注意精度、舍入和溢出问题.md new file mode 100644 index 0000000..d1ecd52 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/09数值计算：注意精度、舍入和溢出问题.md @@ -0,0 +1,340 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 09 数值计算：注意精度、舍入和溢出问题 + 今天，我要和你说说数值计算的精度、舍入和溢出问题。 + +之所以要单独分享数值计算，是因为很多时候我们习惯的或者说认为理所当然的计算，在计算器或计算机看来并不是那么回事儿。就比如前段时间爆出的一条新闻，说是手机计算器把 10%+10% 算成了 0.11 而不是 0.2。 + +出现这种问题的原因在于，国外的计算程序使用的是单步计算法。在单步计算法中，a+b% 代表的是 a*(1+b%)。所以，手机计算器计算 10%+10% 时，其实计算的是 10%*（1+10%），所以得到的是 0.11 而不是 0.2。 + +在我看来，计算器或计算机会得到反直觉的计算结果的原因，可以归结为： + +在人看来，浮点数只是具有小数点的数字，0.1 和 1 都是一样精确的数字。但，计算机其实无法精确保存浮点数，因此浮点数的计算结果也不可能精确。 + +在人看来，一个超大的数字只是位数多一点而已，多写几个 1 并不会让大脑死机。但，计算机是把数值保存在了变量中，不同类型的数值变量能保存的数值范围不同，当数值超过类型能表达的数值上限则会发生溢出问题。 + +接下来，我们就具体看看这些问题吧。 + +“危险”的 Double + +我们先从简单的反直觉的四则运算看起。对几个简单的浮点数进行加减乘除运算： + +System.out.println(0.1+0.2); +System.out.println(1.0-0.8); +System.out.println(4.015*100); +System.out.println(123.3/100); + +double amount1 = 2.15; +double amount2 = 1.10; + +if (amount1 - amount2 == 1.05) + System.out.println("OK"); + + +输出结果如下： + +0.30000000000000004 +0.19999999999999996 +401.49999999999994 +1.2329999999999999 + + +可以看到，输出结果和我们预期的很不一样。比如，0.1+0.2 输出的不是 0.3 而是 0.30000000000000004；再比如，对 2.15-1.10 和 1.05 判等，结果判等不成立。 + +出现这种问题的主要原因是，计算机是以二进制存储数值的，浮点数也不例外。Java 采用了IEEE 754 标准实现浮点数的表达和运算，你可以通过这里查看数值转化为二进制的结果。 + +比如，0.1 的二进制表示为 0.0 0011 0011 0011… （0011 无限循环)，再转换为十进制就是 0.1000000000000000055511151231257827021181583404541015625。对于计算机而言，0.1 无法精确表达，这是浮点数计算造成精度损失的根源。 + +你可能会说，以 0.1 为例，其十进制和二进制间转换后相差非常小，不会对计算产生什么影响。但，所谓积土成山，如果大量使用 double 来作大量的金钱计算，最终损失的精度就是大量的资金出入。比如，每天有一百万次交易，每次交易都差一分钱，一个月下来就差 30 万。这就不是小事儿了。那，如何解决这个问题呢？ + +我们大都听说过 BigDecimal 类型，浮点数精确表达和运算的场景，一定要使用这个类型。不过，在使用 BigDecimal 时有几个坑需要避开。我们用 BigDecimal 把之前的四则运算改一下： + +System.out.println(new BigDecimal(0.1).add(new BigDecimal(0.2))); +System.out.println(new BigDecimal(1.0).subtract(new BigDecimal(0.8))); +System.out.println(new BigDecimal(4.015).multiply(new BigDecimal(100))); +System.out.println(new BigDecimal(123.3).divide(new BigDecimal(100))); + + +输出如下： + +0.3000000000000000166533453693773481063544750213623046875 +0.1999999999999999555910790149937383830547332763671875 +401.49999999999996802557689079549163579940795898437500 +1.232999999999999971578290569595992565155029296875 + + +可以看到，运算结果还是不精确，只不过是精度高了而已。这里给出浮点数运算避坑第一原则：使用 BigDecimal 表示和计算浮点数，且务必使用字符串的构造方法来初始化 BigDecimal： + +System.out.println(new BigDecimal("0.1").add(new BigDecimal("0.2"))); +System.out.println(new BigDecimal("1.0").subtract(new BigDecimal("0.8"))); +System.out.println(new BigDecimal("4.015").multiply(new BigDecimal("100"))); +System.out.println(new BigDecimal("123.3").divide(new BigDecimal("100"))); + + +改进后，就能得到我们想要的输出了： + +0.3 +0.2 +401.500 +1.233 + + +到这里，你可能会继续问，不能调用 BigDecimal 传入 Double 的构造方法，但手头只有一个 Double，如何转换为精确表达的 BigDecimal 呢？ + +我们试试用 Double.toString 把 double 转换为字符串，看看行不行？ + +System.out.println(new BigDecimal("4.015").multiply(new BigDecimal(Double.toString(100)))); + + +输出为 401.5000。与上面字符串初始化 100 和 4.015 相乘得到的结果 401.500 相比，这里为什么多了 1 个 0 呢？原因就是，BigDecimal 有 scale 和 precision 的概念，scale 表示小数点右边的位数，而 precision 表示精度，也就是有效数字的长度。 + +调试一下可以发现，new BigDecimal(Double.toString(100)) 得到的 BigDecimal 的 scale=1、precision=4；而 new BigDecimal(“100”) 得到的 BigDecimal 的 scale=0、precision=3。对于 BigDecimal 乘法操作，返回值的 scale 是两个数的 scale 相加。所以，初始化 100 的两种不同方式，导致最后结果的 scale 分别是 4 和 3： + +private static void testScale() { + + BigDecimal bigDecimal1 = new BigDecimal("100"); + BigDecimal bigDecimal2 = new BigDecimal(String.valueOf(100d)); + BigDecimal bigDecimal3 = new BigDecimal(String.valueOf(100)); + BigDecimal bigDecimal4 = BigDecimal.valueOf(100d); + BigDecimal bigDecimal5 = new BigDecimal(Double.toString(100)); + + print(bigDecimal1); //scale 0 precision 3 result 401.500 + print(bigDecimal2); //scale 1 precision 4 result 401.5000 + print(bigDecimal3); //scale 0 precision 3 result 401.500 + print(bigDecimal4); //scale 1 precision 4 result 401.5000 + print(bigDecimal5); //scale 1 precision 4 result 401.5000 +} + +private static void print(BigDecimal bigDecimal) { + + log.info("scale {} precision {} result {}", bigDecimal.scale(), bigDecimal.precision(), bigDecimal.multiply(new BigDecimal("4.015"))); +} + + +BigDecimal 的 toString 方法得到的字符串和 scale 相关，又会引出了另一个问题：对于浮点数的字符串形式输出和格式化，我们应该考虑显式进行，通过格式化表达式或格式化工具来明确小数位数和舍入方式。接下来，我们就聊聊浮点数舍入和格式化。 + +考虑浮点数舍入和格式化的方式 + +除了使用 Double 保存浮点数可能带来精度问题外，更匪夷所思的是这种精度问题，加上 String.format 的格式化舍入方式，可能得到让人摸不着头脑的结果。 + +我们看一个例子吧。首先用 double 和 float 初始化两个 3.35 的浮点数，然后通过 String.format 使用 %.1f 来格式化这 2 个数字： + +double num1 = 3.35; +float num2 = 3.35f; + +System.out.println(String.format("%.1f", num1));//四舍五入 +System.out.println(String.format("%.1f", num2)); + + +得到的结果居然是 3.4 和 3.3。 + +这就是由精度问题和舍入方式共同导致的，double 和 float 的 3.35 其实相当于 3.350xxx 和 3.349xxx： + +3.350000000000000088817841970012523233890533447265625 +3.349999904632568359375 + + +String.format 采用四舍五入的方式进行舍入，取 1 位小数，double 的 3.350 四舍五入为 3.4，而 float 的 3.349 四舍五入为 3.3。 + +我们看一下 Formatter 类的相关源码，可以发现使用的舍入模式是 HALF_UP（代码第 11 行）： + +else if (c == Conversion.DECIMAL_FLOAT) { + + // Create a new BigDecimal with the desired precision. + int prec = (precision == -1 ? 6 : precision); + int scale = value.scale(); + + if (scale > prec) { + // more "scale" digits than the requested "precision" + int compPrec = value.precision(); + if (compPrec <= scale) { + // case of 0.xxxxxx + value = value.setScale(prec, RoundingMode.HALF_UP); + } else { + compPrec -= (scale - prec); + value = new BigDecimal(value.unscaledValue(), + scale, + new MathContext(compPrec)); + } + } +} + + +如果我们希望使用其他舍入方式来格式化字符串的话，可以设置 DecimalFormat，如下代码所示： + +double num1 = 3.35; +float num2 = 3.35f; +DecimalFormat format = new DecimalFormat("#.##"); + +format.setRoundingMode(RoundingMode.DOWN); +System.out.println(format.format(num1)); +format.setRoundingMode(RoundingMode.DOWN); +System.out.println(format.format(num2)); + + +当我们把这 2 个浮点数向下舍入取 2 位小数时，输出分别是 3.35 和 3.34，还是我们之前说的浮点数无法精确存储的问题。 + +因此，即使通过 DecimalFormat 来精确控制舍入方式，double 和 float 的问题也可能产生意想不到的结果，所以浮点数避坑第二原则：浮点数的字符串格式化也要通过 BigDecimal 进行。 + +比如下面这段代码，使用 BigDecimal 来格式化数字 3.35，分别使用向下舍入和四舍五入方式取 1 位小数进行格式化： + +BigDecimal num1 = new BigDecimal("3.35"); +BigDecimal num2 = num1.setScale(1, BigDecimal.ROUND_DOWN); + +System.out.println(num2); +BigDecimal num3 = num1.setScale(1, BigDecimal.ROUND_HALF_UP); +System.out.println(num3); + + +这次得到的结果是 3.3 和 3.4，符合预期。 + +用 equals 做判等，就一定是对的吗？ + +现在我们知道了，应该使用 BigDecimal 来进行浮点数的表示、计算、格式化。在上一讲介绍判等问题时，我提到一个原则：包装类的比较要通过 equals 进行，而不能使用 ==。那么，使用 equals 方法对两个 BigDecimal 判等，一定能得到我们想要的结果吗？ + +我们来看下面的例子。使用 equals 方法比较 1.0 和 1 这两个 BigDecimal： + +System.out.println(new BigDecimal("1.0").equals(new BigDecimal("1"))) + + +你可能已经猜到我要说什么了，结果当然是 false。BigDecimal 的 equals 方法的注释中说明了原因，equals 比较的是 BigDecimal 的 value 和 scale，1.0 的 scale 是 1，1 的 scale 是 0，所以结果一定是 false： + +/** + * Compares this {@code BigDecimal} with the specified + * {@code Object} for equality. Unlike {@link + * #compareTo(BigDecimal) compareTo}, this method considers two + * {@code BigDecimal} objects equal only if they are equal in + * value and scale (thus 2.0 is not equal to 2.00 when compared by + * this method). + * + * @param x {@code Object} to which this {@code BigDecimal} is + * to be compared. + * @return {@code true} if and only if the specified {@code Object} is a + * {@code BigDecimal} whose value and scale are equal to this + * {@code BigDecimal}'s. + * @see #compareTo(java.math.BigDecimal) + * @see #hashCode + */ +@Override +public boolean equals(Object x) + + +如果我们希望只比较 BigDecimal 的 value，可以使用 compareTo 方法，修改后代码如下： + +System.out.println(new BigDecimal("1.0").compareTo(new BigDecimal("1"))==0); + + +学过上一讲，你可能会意识到 BigDecimal 的 equals 和 hashCode 方法会同时考虑 value 和 scale，如果结合 HashSet 或 HashMap 使用的话就可能会出现麻烦。比如，我们把值为 1.0 的 BigDecimal 加入 HashSet，然后判断其是否存在值为 1 的 BigDecimal，得到的结果是 false： + +Set hashSet1 = new HashSet<>(); +hashSet1.add(new BigDecimal("1.0")); +System.out.println(hashSet1.contains(new BigDecimal("1")));//返回false + + +解决这个问题的办法有两个： + +第一个方法是，使用 TreeSet 替换 HashSet。TreeSet 不使用 hashCode 方法，也不使用 equals 比较元素，而是使用 compareTo 方法，所以不会有问题。 + +Set treeSet = new TreeSet<>(); +treeSet.add(new BigDecimal("1.0")); +System.out.println(treeSet.contains(new BigDecimal("1")));//返回true + + +第二个方法是，把 BigDecimal 存入 HashSet 或 HashMap 前，先使用 stripTrailingZeros 方法去掉尾部的零，比较的时候也去掉尾部的 0，确保 value 相同的 BigDecimal，scale 也是一致的： + +Set hashSet2 = new HashSet<>(); +hashSet2.add(new BigDecimal("1.0").stripTrailingZeros()); +System.out.println(hashSet2.contains(new BigDecimal("1.000").stripTrailingZeros()));//返回true + + +小心数值溢出问题 + +数值计算还有一个要小心的点是溢出，不管是 int 还是 long，所有的基本数值类型都有超出表达范围的可能性。 + +比如，对 Long 的最大值进行 +1 操作： + +long l = Long.MAX_VALUE; +System.out.println(l + 1); +System.out.println(l + 1 == Long.MIN_VALUE); + + +输出结果是一个负数，因为 Long 的最大值 +1 变为了 Long 的最小值： + +-9223372036854775808 +true + + +显然这是发生了溢出，而且是默默地溢出，并没有任何异常。这类问题非常容易被忽略，改进方式有下面 2 种。 + +方法一是，考虑使用 Math 类的 addExact、subtractExact 等 xxExact 方法进行数值运算，这些方法可以在数值溢出时主动抛出异常。我们来测试一下，使用 Math.addExact 对 Long 最大值做 +1 操作： + +try { + long l = Long.MAX_VALUE; + System.out.println(Math.addExact(l, 1)); +} catch (Exception ex) { + ex.printStackTrace(); +} + + +执行后，可以得到 ArithmeticException，这是一个 RuntimeException： + +java.lang.ArithmeticException: long overflow + at java.lang.Math.addExact(Math.java:809) + at org.geekbang.time.commonmistakes.numeralcalculations.demo3.CommonMistakesApplication.right2(CommonMistakesApplication.java:25) + at org.geekbang.time.commonmistakes.numeralcalculations.demo3.CommonMistakesApplication.main(CommonMistakesApplication.java:13) + + +方法二是，使用大数类 BigInteger。BigDecimal 是处理浮点数的专家，而 BigInteger 则是对大数进行科学计算的专家。 + +如下代码，使用 BigInteger 对 Long 最大值进行 +1 操作；如果希望把计算结果转换一个 Long 变量的话，可以使用 BigInteger 的 longValueExact 方法，在转换出现溢出时，同样会抛出 ArithmeticException： + +BigInteger i = new BigInteger(String.valueOf(Long.MAX_VALUE)); +System.out.println(i.add(BigInteger.ONE).toString()); +try { + long l = i.add(BigInteger.ONE).longValueExact(); +} catch (Exception ex) { + ex.printStackTrace(); +} + + +输出结果如下： + +9223372036854775808 +java.lang.ArithmeticException: BigInteger out of long range + at java.math.BigInteger.longValueExact(BigInteger.java:4632) + at org.geekbang.time.commonmistakes.numeralcalculations.demo3.CommonMistakesApplication.right1(CommonMistakesApplication.java:37) + at org.geekbang.time.commonmistakes.numeralcalculations.demo3.CommonMistakesApplication.main(CommonMistakesApplication.java:11) + + +可以看到，通过 BigInteger 对 Long 的最大值加 1 一点问题都没有，当尝试把结果转换为 Long 类型时，则会提示 BigInteger out of long range。 + +重点回顾 + +今天，我与你分享了浮点数的表示、计算、舍入和格式化、溢出等涉及的一些坑。 + +第一，切记，要精确表示浮点数应该使用 BigDecimal。并且，使用 BigDecimal 的 Double 入参的构造方法同样存在精度丢失问题，应该使用 String 入参的构造方法或者 BigDecimal.valueOf 方法来初始化。 + +第二，对浮点数做精确计算，参与计算的各种数值应该始终使用 BigDecimal，所有的计算都要通过 BigDecimal 的方法进行，切勿只是让 BigDecimal 来走过场。任何一个环节出现精度损失，最后的计算结果可能都会出现误差。 + +第三，对于浮点数的格式化，如果使用 String.format 的话，需要认识到它使用的是四舍五入，可以考虑使用 DecimalFormat 来明确指定舍入方式。但考虑到精度问题，我更建议使用 BigDecimal 来表示浮点数，并使用其 setScale 方法指定舍入的位数和方式。 + +第四，进行数值运算时要小心溢出问题，虽然溢出后不会出现异常，但得到的计算结果是完全错误的。我们考虑使用 Math.xxxExact 方法来进行运算，在溢出时能抛出异常，更建议对于可能会出现溢出的大数运算使用 BigInteger 类。 + +总之，对于金融、科学计算等场景，请尽可能使用 BigDecimal 和 BigInteger，避免由精度和溢出问题引发难以发现，但影响重大的 Bug。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +BigDecimal提供了 8 种舍入模式，你能通过一些例子说说它们的区别吗？ + +数据库（比如 MySQL）中的浮点数和整型数字，你知道应该怎样定义吗？又如何实现浮点数的准确计算呢？ + +针对数值运算，你还遇到过什么坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/10集合类：坑满地的List列表操作.md b/专栏/Java业务开发常见错误100例/10集合类：坑满地的List列表操作.md new file mode 100644 index 0000000..0166823 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/10集合类：坑满地的List列表操作.md @@ -0,0 +1,538 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 10 集合类：坑满地的List列表操作 + 今天，我来和你说说 List 列表操作有哪些坑。 + +Pascal 之父尼克劳斯 · 维尔特（Niklaus Wirth），曾提出一个著名公式“程序 = 数据结构 + 算法”。由此可见，数据结构的重要性。常见的数据结构包括 List、Set、Map、Queue、Tree、Graph、Stack 等，其中 List、Set、Map、Queue 可以从广义上统称为集合类数据结构。 + +现代编程语言一般都会提供各种数据结构的实现，供我们开箱即用。Java 也是一样，比如提供了集合类的各种实现。Java 的集合类包括 Map 和 Collection 两大类。Collection 包括 List、Set 和 Queue 三个小类，其中 List 列表集合是最重要也是所有业务代码都会用到的。所以，今天我会重点介绍 List 的内容，而不会集中介绍 Map 以及 Collection 中其他小类的坑。 + +今天，我们就从把数组转换为 List 集合、对 List 进行切片操作、List 搜索的性能问题等几个方面着手，来聊聊其中最可能遇到的一些坑。 + +使用 Arrays.asList 把数据转换为 List 的三个坑 + +Java 8 中 Stream 流式处理的各种功能，大大减少了集合类各种操作（投影、过滤、转换）的代码量。所以，在业务开发中，我们常常会把原始的数组转换为 List 类数据结构，来继续展开各种 Stream 操作。 + +你可能也想到了，使用 Arrays.asList 方法可以把数组一键转换为 List，但其实没这么简单。接下来，就让我们看看其中的缘由，以及使用 Arrays.asList 把数组转换为 List 的几个坑。 + +在如下代码中，我们初始化三个数字的 int[]数组，然后使用 Arrays.asList 把数组转换为 List： + +int[] arr = {1, 2, 3}; +List list = Arrays.asList(arr); +log.info("list:{} size:{} class:{}", list, list.size(), list.get(0).getClass()); + + +但，这样初始化的 List 并不是我们期望的包含 3 个数字的 List。通过日志可以发现，这个 List 包含的其实是一个 int 数组，整个 List 的元素个数是 1，元素类型是整数数组。 + +12:50:39.445 [main] INFO org.geekbang.time.commonmistakes.collection.aslist.AsListApplication - list:[[I@1c53fd30] size:1 class:class [I + + +其原因是，只能是把 int 装箱为 Integer，不可能把 int 数组装箱为 Integer 数组。我们知道，Arrays.asList 方法传入的是一个泛型 T 类型可变参数，最终 int 数组整体作为了一个对象成为了泛型类型 T： + +public static List asList(T... a) { + return new ArrayList<>(a); +} + + +直接遍历这样的 List 必然会出现 Bug，修复方式有两种，如果使用 Java8 以上版本可以使用 Arrays.stream 方法来转换，否则可以把 int 数组声明为包装类型 Integer 数组： + +int[] arr1 = {1, 2, 3}; +List list1 = Arrays.stream(arr1).boxed().collect(Collectors.toList()); +log.info("list:{} size:{} class:{}", list1, list1.size(), list1.get(0).getClass()); + +Integer[] arr2 = {1, 2, 3}; +List list2 = Arrays.asList(arr2); +log.info("list:{} size:{} class:{}", list2, list2.size(), list2.get(0).getClass()); + + +修复后的代码得到如下日志，可以看到 List 具有三个元素，元素类型是 Integer： + +13:10:57.373 [main] INFO org.geekbang.time.commonmistakes.collection.aslist.AsListApplication - list:[1, 2, 3] size:3 class:class java.lang.Integer + + +可以看到第一个坑是，不能直接使用 Arrays.asList 来转换基本类型数组。那么，我们获得了正确的 List，是不是就可以像普通的 List 那样使用了呢？我们继续往下看。 + +把三个字符串 1、2、3 构成的字符串数组，使用 Arrays.asList 转换为 List 后，将原始字符串数组的第二个字符修改为 4，然后为 List 增加一个字符串 5，最后数组和 List 会是怎样呢？ + +String[] arr = {"1", "2", "3"}; +List list = Arrays.asList(arr); +arr[1] = "4"; +try { + list.add("5"); +} catch (Exception ex) { + ex.printStackTrace(); +} + +log.info("arr:{} list:{}", Arrays.toString(arr), list); + + +可以看到，日志里有一个 UnsupportedOperationException，为 List 新增字符串 5 的操作失败了，而且把原始数组的第二个元素从 2 修改为 4 后，asList 获得的 List 中的第二个元素也被修改为 4 了： + +java.lang.UnsupportedOperationException + at java.util.AbstractList.add(AbstractList.java:148) + at java.util.AbstractList.add(AbstractList.java:108) + at org.geekbang.time.commonmistakes.collection.aslist.AsListApplication.wrong2(AsListApplication.java:41) + at org.geekbang.time.commonmistakes.collection.aslist.AsListApplication.main(AsListApplication.java:15) +13:15:34.699 [main] INFO org.geekbang.time.commonmistakes.collection.aslist.AsListApplication - arr:[1, 4, 3] list:[1, 4, 3] + + +这里，又引出了两个坑。 + +第二个坑，Arrays.asList 返回的 List 不支持增删操作。Arrays.asList 返回的 List 并不是我们期望的 java.util.ArrayList，而是 Arrays 的内部类 ArrayList。ArrayList 内部类继承自 AbstractList 类，并没有覆写父类的 add 方法，而父类中 add 方法的实现，就是抛出 UnsupportedOperationException。相关源码如下所示： + +public static List asList(T... a) { + return new ArrayList<>(a); +} + +private static class ArrayList extends AbstractList implements RandomAccess, java.io.Serializable { + + private final E[] a; + + ArrayList(E[] array) { + a = Objects.requireNonNull(array); + } +... + @Override + public E set(int index, E element) { + + E oldValue = a[index]; + a[index] = element; + return oldValue; + } + ... +} + +public abstract class AbstractList extends AbstractCollection implements List { + +... + +public void add(int index, E element) { + throw new UnsupportedOperationException(); + } +} + + +第三个坑，对原始数组的修改会影响到我们获得的那个 List。看一下 ArrayList 的实现，可以发现 ArrayList 其实是直接使用了原始的数组。所以，我们要特别小心，把通过 Arrays.asList 获得的 List 交给其他方法处理，很容易因为共享了数组，相互修改产生 Bug。 + +修复方式比较简单，重新 new 一个 ArrayList 初始化 Arrays.asList 返回的 List 即可： + +String[] arr = {"1", "2", "3"}; +List list = new ArrayList(Arrays.asList(arr)); +arr[1] = "4"; + +try { + list.add("5"); +} catch (Exception ex) { + ex.printStackTrace(); +} + +log.info("arr:{} list:{}", Arrays.toString(arr), list); + + +修改后的代码实现了原始数组和 List 的“解耦”，不再相互影响。同时，因为操作的是真正的 ArrayList，add 也不再出错： + +13:34:50.829 [main] INFO org.geekbang.time.commonmistakes.collection.aslist.AsListApplication - arr:[1, 4, 3] list:[1, 2, 3, 5] + + +使用 List.subList 进行切片操作居然会导致 OOM？ + +业务开发时常常要对 List 做切片处理，即取出其中部分元素构成一个新的 List，我们通常会想到使用 List.subList 方法。但，和 Arrays.asList 的问题类似，List.subList 返回的子 List 不是一个普通的 ArrayList。这个子 List 可以认为是原始 List 的视图，会和原始 List 相互影响。如果不注意，很可能会因此产生 OOM 问题。接下来，我们就一起分析下其中的坑。 + +如下代码所示，定义一个名为 data 的静态 List 来存放 Integer 的 List，也就是说 data 的成员本身是包含了多个数字的 List。循环 1000 次，每次都从一个具有 10 万个 Integer 的 List 中，使用 subList 方法获得一个只包含一个数字的子 List，并把这个子 List 加入 data 变量： + +private static List> data = new ArrayList<>(); + +private static void oom() { + for (int i = 0; i < 1000; i++) { + List rawList = IntStream.rangeClosed(1, 100000).boxed().collect(Collectors.toList()); + data.add(rawList.subList(0, 1)); + } +} + + +你可能会觉得，这个 data 变量里面最终保存的只是 1000 个具有 1 个元素的 List，不会占用很大空间，但程序运行不久就出现了 OOM： + +Exception in thread "main" java.lang.OutOfMemoryError: Java heap space + at java.util.Arrays.copyOf(Arrays.java:3181) + at java.util.ArrayList.grow(ArrayList.java:265) + + +出现 OOM 的原因是，循环中的 1000 个具有 10 万个元素的 List 始终得不到回收，因为它始终被 subList 方法返回的 List 强引用。那么，返回的子 List 为什么会强引用原始的 List，它们又有什么关系呢？我们再继续做实验观察一下这个子 List 的特性。 + +首先初始化一个包含数字 1 到 10 的 ArrayList，然后通过调用 subList 方法取出 2、3、4；随后删除这个 SubList 中的元素数字 3，并打印原始的 ArrayList；最后为原始的 ArrayList 增加一个元素数字 0，遍历 SubList 输出所有元素： + +List list = IntStream.rangeClosed(1, 10).boxed().collect(Collectors.toList()); +List subList = list.subList(1, 4); +System.out.println(subList); +subList.remove(1); +System.out.println(list); +list.add(0); +try { + subList.forEach(System.out::println); +} catch (Exception ex) { + ex.printStackTrace(); +} + + +代码运行后得到如下输出： + +[2, 3, 4] +[1, 2, 4, 5, 6, 7, 8, 9, 10] +java.util.ConcurrentModificationException + at java.util.ArrayList$SubList.checkForComodification(ArrayList.java:1239) + at java.util.ArrayList$SubList.listIterator(ArrayList.java:1099) + at java.util.AbstractList.listIterator(AbstractList.java:299) + at java.util.ArrayList$SubList.iterator(ArrayList.java:1095) + at java.lang.Iterable.forEach(Iterable.java:74) + + +可以看到两个现象： + +原始 List 中数字 3 被删除了，说明删除子 List 中的元素影响到了原始 List； + +尝试为原始 List 增加数字 0 之后再遍历子 List，会出现 ConcurrentModificationException。 + +我们分析下 ArrayList 的源码，看看为什么会是这样。 + +public class ArrayList extends AbstractList + implements List, RandomAccess, Cloneable, java.io.Serializable { + + protected transient int modCount = 0; + + private void ensureExplicitCapacity(int minCapacity) { + modCount++; + // overflow-conscious code + if (minCapacity - elementData.length > 0) + grow(minCapacity); + } + + public void add(int index, E element) { + rangeCheckForAdd(index); + ensureCapacityInternal(size + 1); // Increments modCount!! + System.arraycopy(elementData, index, elementData, index + 1, + size - index); + elementData[index] = element; + size++; + } + + public List subList(int fromIndex, int toIndex) { + subListRangeCheck(fromIndex, toIndex, size); + return new SubList(this, offset, fromIndex, toIndex); + } + + private class SubList extends AbstractList implements RandomAccess { + + private final AbstractList parent; + private final int parentOffset; + private final int offset; + int size; + + SubList(AbstractList parent, + int offset, int fromIndex, int toIndex) { + this.parent = parent; + this.parentOffset = fromIndex; + this.offset = offset + fromIndex; + this.size = toIndex - fromIndex; + this.modCount = ArrayList.this.modCount; + } + + public E set(int index, E element) { + rangeCheck(index); + checkForComodification(); + return l.set(index+offset, element); + } + + public ListIterator listIterator(final int index) { + checkForComodification(); + ... + } + + private void checkForComodification() { + if (ArrayList.this.modCount != this.modCount) + throw new ConcurrentModificationException(); + } + ... + } +} + + +第一，ArrayList 维护了一个叫作 modCount 的字段，表示集合结构性修改的次数。所谓结构性修改，指的是影响 List 大小的修改，所以 add 操作必然会改变 modCount 的值。 + +第二，分析第 21 到 24 行的 subList 方法可以看到，获得的 List 其实是内部类 SubList，并不是普通的 ArrayList，在初始化的时候传入了 this。 + +第三，分析第 26 到 39 行代码可以发现，这个 SubList 中的 parent 字段就是原始的 List。SubList 初始化的时候，并没有把原始 List 中的元素复制到独立的变量中保存。我们可以认为 SubList 是原始 List 的视图，并不是独立的 List。双方对元素的修改会相互影响，而且 SubList 强引用了原始的 List，所以大量保存这样的 SubList 会导致 OOM。 + +第四，分析第 47 到 55 行代码可以发现，遍历 SubList 的时候会先获得迭代器，比较原始 ArrayList modCount 的值和 SubList 当前 modCount 的值。获得了 SubList 后，我们为原始 List 新增了一个元素修改了其 modCount，所以判等失败抛出 ConcurrentModificationException 异常。 + +既然 SubList 相当于原始 List 的视图，那么避免相互影响的修复方式有两种： + +一种是，不直接使用 subList 方法返回的 SubList，而是重新使用 new ArrayList，在构造方法传入 SubList，来构建一个独立的 ArrayList； + +另一种是，对于 Java 8 使用 Stream 的 skip 和 limit API 来跳过流中的元素，以及限制流中元素的个数，同样可以达到 SubList 切片的目的。 + +//方式一： +List subList = new ArrayList<>(list.subList(1, 4)); + +//方式二： +List subList = list.stream().skip(1).limit(3).collect(Collectors.toList()); + + +修复后代码输出如下： + +[2, 3, 4] +[1, 2, 3, 4, 5, 6, 7, 8, 9, 10] +2 +4 + + +可以看到，删除 SubList 的元素不再影响原始 List，而对原始 List 的修改也不会再出现 List 迭代异常。 + +一定要让合适的数据结构做合适的事情 + +在介绍并发工具时，我提到要根据业务场景选择合适的并发工具或容器。在使用 List 集合类的时候，不注意使用场景也会遇见两个常见误区。 + +第一个误区是，使用数据结构不考虑平衡时间和空间。 + +首先，定义一个只有一个 int 类型订单号字段的 Order 类： + +@Data +@NoArgsConstructor +@AllArgsConstructor +static class Order { + private int orderId; +} + + +然后，定义一个包含 elementCount 和 loopCount 两个参数的 listSearch 方法，初始化一个具有 elementCount 个订单对象的 ArrayList，循环 loopCount 次搜索这个 ArrayList，每次随机搜索一个订单号： + +private static Object listSearch(int elementCount, int loopCount) { + + List list = IntStream.rangeClosed(1, elementCount).mapToObj(i -> new Order(i)).collect(Collectors.toList()); + + IntStream.rangeClosed(1, loopCount).forEach(i -> { + int search = ThreadLocalRandom.current().nextInt(elementCount); + Order result = list.stream().filter(order -> order.getOrderId() == search).findFirst().orElse(null); + Assert.assertTrue(result != null && result.getOrderId() == search); + }); + return list; +} + + +随后，定义另一个 mapSearch 方法，从一个具有 elementCount 个元素的 Map 中循环 loopCount 次查找随机订单号。Map 的 Key 是订单号，Value 是订单对象： + +private static Object mapSearch(int elementCount, int loopCount) { + + Map map = IntStream.rangeClosed(1, elementCount).boxed().collect(Collectors.toMap(Function.identity(), i -> new Order(i))); + + IntStream.rangeClosed(1, loopCount).forEach(i -> { + int search = ThreadLocalRandom.current().nextInt(elementCount); + Order result = map.get(search); + Assert.assertTrue(result != null && result.getOrderId() == search); + }); + return map; +} + + +我们知道，搜索 ArrayList 的时间复杂度是 O(n)，而 HashMap 的 get 操作的时间复杂度是 O(1)。所以，要对大 List 进行单值搜索的话，可以考虑使用 HashMap，其中 Key 是要搜索的值，Value 是原始对象，会比使用 ArrayList 有非常明显的性能优势。 + +如下代码所示，对 100 万个元素的 ArrayList 和 HashMap，分别调用 listSearch 和 mapSearch 方法进行 1000 次搜索： + +int elementCount = 1000000; + +int loopCount = 1000; + +StopWatch stopWatch = new StopWatch(); +stopWatch.start("listSearch"); + +Object list = listSearch(elementCount, loopCount); +System.out.println(ObjectSizeCalculator.getObjectSize(list)); +stopWatch.stop(); +stopWatch.start("mapSearch"); + +Object map = mapSearch(elementCount, loopCount); +stopWatch.stop(); +System.out.println(ObjectSizeCalculator.getObjectSize(map)); +System.out.println(stopWatch.prettyPrint()); + + +可以看到，仅仅是 1000 次搜索，listSearch 方法耗时 3.3 秒，而 mapSearch 耗时仅仅 108 毫秒。 + +“shell +20861992 +72388672 + +StopWatch “: running time = 3506699764 ns + +ns % Task name + +3398413176 097% listSearch +108286588 003% mapSearch + + +即使我们要搜索的不是单值而是条件区间，也可以尝试使用 HashMap 来进行“搜索性能优化”。如果你的条件区间是固定的话，可以提前把 HashMap 按照条件区间进行分组，Key 就是不同的区间。 + +的确，如果业务代码中有频繁的大 ArrayList 搜索，使用 HashMap 性能会好很多。类似，如果要对大 ArrayList 进行去重操作，也不建议使用 contains 方法，而是可以考虑使用 HashSet 进行去重。说到这里，还有一个问题，使用 HashMap 是否会牺牲空间呢？ + +为此，我们使用 ObjectSizeCalculator 工具打印 ArrayList 和 HashMap 的内存占用，可以看到 ArrayList 占用内存 21M，而 HashMap 占用的内存达到了 72M，是 List 的三倍多。进一步使用 MAT 工具分析堆可以再次证明，ArrayList 在内存占用上性价比很高，77% 是实际的数据（如第 1 个图所示，16000000/20861992），而 HashMap 的“含金量”只有 22%（如第 2 个图所示，16000000/72386640）。 + +![img](assets/1e8492040dd4b1af6114a6eeba06e524.png) + +![img](assets/53d53e3ce2efcb081f8d9fa496cb8ec7.png) + +所以，在应用内存吃紧的情况下，我们需要考虑是否值得使用更多的内存消耗来换取更高的性能。这里我们看到的是平衡的艺术，空间换时间，还是时间换空间，只考虑任何一个方面都是不对的。 + +第二个误区是，过于迷信教科书的大 O 时间复杂度。 + +数据结构中要实现一个列表，有基于连续存储的数组和基于指针串联的链表两种方式。在 Java 中，有代表性的实现是 ArrayList 和 LinkedList，前者背后的数据结构是数组，后者则是（双向）链表。 + +在选择数据结构的时候，我们通常会考虑每种数据结构不同操作的时间复杂度，以及使用场景两个因素。查看这里，你可以看到数组和链表大 O 时间复杂度的显著差异： + +对于数组，随机元素访问的时间复杂度是 O(1)，元素插入操作是 O(n)； + +对于链表，随机元素访问的时间复杂度是 O(n)，元素插入操作是 O(1)。 + +那么，在大量的元素插入、很少的随机访问的业务场景下，是不是就应该使用 LinkedList 呢？接下来，我们写一段代码测试下两者随机访问和插入的性能吧。 + +定义四个参数一致的方法，分别对元素个数为 elementCount 的 LinkedList 和 ArrayList，循环 loopCount 次，进行随机访问和增加元素到随机位置的操作： + +```java +//LinkedList访问 +private static void linkedListGet(int elementCount, int loopCount) { + List list = IntStream.rangeClosed(1, elementCount).boxed().collect(Collectors.toCollection(LinkedList::new)); + IntStream.rangeClosed(1, loopCount).forEach(i -> list.get(ThreadLocalRandom.current().nextInt(elementCount))); +} + +//ArrayList访问 +private static void arrayListGet(int elementCount, int loopCount) { + List list = IntStream.rangeClosed(1, elementCount).boxed().collect(Collectors.toCollection(ArrayList::new)); + IntStream.rangeClosed(1, loopCount).forEach(i -> list.get(ThreadLocalRandom.current().nextInt(elementCount))); +} + +//LinkedList插入 +private static void linkedListAdd(int elementCount, int loopCount) { + List list = IntStream.rangeClosed(1, elementCount).boxed().collect(Collectors.toCollection(LinkedList::new)); + IntStream.rangeClosed(1, loopCount).forEach(i -> list.add(ThreadLocalRandom.current().nextInt(elementCount),1)); +} + +//ArrayList插入 +private static void arrayListAdd(int elementCount, int loopCount) { + List list = IntStream.rangeClosed(1, elementCount).boxed().collect(Collectors.toCollection(ArrayList::new)); + IntStream.rangeClosed(1, loopCount).forEach(i -> list.add(ThreadLocalRandom.current().nextInt(elementCount),1)); +} + + +测试代码如下，10 万个元素，循环 10 万次： + +int elementCount = 100000; + +int loopCount = 100000; + +StopWatch stopWatch = new StopWatch(); +stopWatch.start("linkedListGet"); +linkedListGet(elementCount, loopCount); +stopWatch.stop(); + +stopWatch.start("arrayListGet"); +arrayListGet(elementCount, loopCount); +stopWatch.stop(); +System.out.println(stopWatch.prettyPrint()); + +StopWatch stopWatch2 = new StopWatch(); +stopWatch2.start("linkedListAdd"); +linkedListAdd(elementCount, loopCount); +stopWatch2.stop(); + +stopWatch2.start("arrayListAdd"); +arrayListAdd(elementCount, loopCount); +stopWatch2.stop(); + +System.out.println(stopWatch2.prettyPrint()); + + +运行结果可能会让你大跌眼镜。在随机访问方面，我们看到了 ArrayList 的绝对优势，耗时只有 11 毫秒，而 LinkedList 耗时 6.6 秒，这符合上面我们所说的时间复杂度；但，随机插入操作居然也是 LinkedList 落败，耗时 9.3 秒，ArrayList 只要 1.5 秒： + +--------------------------------------------- +ns % Task name +--------------------------------------------- +6604199591 100% linkedListGet +011494583 000% arrayListGet + +StopWatch '': running time = 10729378832 ns +--------------------------------------------- +ns % Task name +--------------------------------------------- +9253355484 086% linkedListAdd +1476023348 014% arrayListAdd + + +翻看 LinkedList 源码发现，插入操作的时间复杂度是 O(1) 的前提是，你已经有了那个要插入节点的指针。但，在实现的时候，我们需要先通过循环获取到那个节点的 Node，然后再执行插入操作。前者也是有开销的，不可能只考虑插入操作本身的代价： + +public void add(int index, E element) { + + checkPositionIndex(index); + if (index == size) + linkLast(element); + else + linkBefore(element, node(index)); +} + +Node node(int index) { + // assert isElementIndex(index); + if (index < (size >> 1)) { + Node x = first; + for (int i = 0; i < index; i++) + x = x.next; + return x; + } else { + Node x = last; + for (int i = size - 1; i > index; i--) + x = x.prev; + return x; + } +} + + +所以，对于插入操作，LinkedList 的时间复杂度其实也是 O(n)。继续做更多实验的话你会发现，在各种常用场景下，LinkedList 几乎都不能在性能上胜出 ArrayList。 + +讽刺的是，LinkedList 的作者约书亚 · 布洛克（Josh Bloch），在其推特上回复别人时说，虽然 LinkedList 是我写的但我从来不用，有谁会真的用吗？ + + + +这告诉我们，任何东西理论上和实际上是有差距的，请勿迷信教科书的理论，最好在下定论之前实际测试一下。抛开算法层面不谈，由于 CPU 缓存、内存连续性等问题，链表这种数据结构的实现方式对性能并不友好，即使在它最擅长的场景都不一定可以发挥威力。 + +重点回顾 + +今天，我分享了若干和 List 列表相关的错误案例，基本都是由“想当然”导致的。 + +第一，想当然认为，Arrays.asList 和 List.subList 得到的 List 是普通的、独立的 ArrayList，在使用时出现各种奇怪的问题。 + +Arrays.asList 得到的是 Arrays 的内部类 ArrayList，List.subList 得到的是 ArrayList 的内部类 SubList，不能把这两个内部类转换为 ArrayList 使用。 + +Arrays.asList 直接使用了原始数组，可以认为是共享“存储”，而且不支持增删元素；List.subList 直接引用了原始的 List，也可以认为是共享“存储”，而且对原始 List 直接进行结构性修改会导致 SubList 出现异常。 + +对 Arrays.asList 和 List.subList 容易忽略的是，新的 List 持有了原始数据的引用，可能会导致原始数据也无法 GC 的问题，最终导致 OOM。 + +第二，想当然认为，Arrays.asList 一定可以把所有数组转换为正确的 List。当传入基本类型数组的时候，List 的元素是数组本身，而不是数组中的元素。 + +第三，想当然认为，内存中任何集合的搜索都是很快的，结果在搜索超大 ArrayList 的时候遇到性能问题。我们考虑利用 HashMap 哈希表随机查找的时间复杂度为 O(1) 这个特性来优化性能，不过也要考虑 HashMap 存储空间上的代价，要平衡时间和空间。 + +第四，想当然认为，链表适合元素增删的场景，选用 LinkedList 作为数据结构。在真实场景中读写增删一般是平衡的，而且增删不可能只是对头尾对象进行操作，可能在 90% 的情况下都得不到性能增益，建议使用之前通过性能测试评估一下。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +最后，我给你留下与 ArrayList 在删除元素方面的坑有关的两个思考题吧。 + +调用类型是 Integer 的 ArrayList 的 remove 方法删除元素，传入一个 Integer 包装类的数字和传入一个 int 基本类型的数字，结果一样吗？ + +循环遍历 List，调用 remove 方法删除元素，往往会遇到 ConcurrentModificationException 异常，原因是什么，修复方式又是什么呢？ + +你还遇到过与集合类相关的其他坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/11空值处理：分不清楚的null和恼人的空指针.md b/专栏/Java业务开发常见错误100例/11空值处理：分不清楚的null和恼人的空指针.md new file mode 100644 index 0000000..1d9bbff --- /dev/null +++ b/专栏/Java业务开发常见错误100例/11空值处理：分不清楚的null和恼人的空指针.md @@ -0,0 +1,478 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 11 空值处理：分不清楚的null和恼人的空指针 + 今天，我要和你分享的主题是，空值处理：分不清楚的 null 和恼人的空指针。 + +有一天我收到一条短信，内容是“尊敬的 null 你好，XXX”。当时我就笑了，这是程序员都能 Get 的笑点，程序没有获取到我的姓名，然后把空格式化为了 null。很明显，这是没处理好 null。哪怕把 null 替换为贵宾、顾客，也不会引发这样的笑话。 + +程序中的变量是 null，就意味着它没有引用指向或者说没有指针。这时，我们对这个变量进行任何操作，都必然会引发空指针异常，在 Java 中就是 NullPointerException。那么，空指针异常容易在哪些情况下出现，又应该如何修复呢？ + +空指针异常虽然恼人但好在容易定位，更麻烦的是要弄清楚 null 的含义。比如，客户端给服务端的一个数据是 null，那么其意图到底是给一个空值，还是没提供值呢？再比如，数据库中字段的 NULL 值，是否有特殊的含义呢，针对数据库中的 NULL 值，写 SQL 需要特别注意什么呢？ + +今天，就让我们带着这些问题开始 null 的踩坑之旅吧。 + +修复和定位恼人的空指针问题 + +NullPointerException 是 Java 代码中最常见的异常，我将其最可能出现的场景归为以下 5 种： + +参数值是 Integer 等包装类型，使用时因为自动拆箱出现了空指针异常； + +字符串比较出现空指针异常； + +诸如 ConcurrentHashMap 这样的容器不支持 Key 和 Value 为 null，强行 put null 的 Key 或 Value 会出现空指针异常； + +A 对象包含了 B，在通过 A 对象的字段获得 B 之后，没有对字段判空就级联调用 B 的方法出现空指针异常； + +方法或远程服务返回的 List 不是空而是 null，没有进行判空就直接调用 List 的方法出现空指针异常。 + +为模拟说明这 5 种场景，我写了一个 wrongMethod 方法，并用一个 wrong 方法来调用它。wrong 方法的入参 test 是一个由 0 和 1 构成的、长度为 4 的字符串，第几位设置为 1 就代表第几个参数为 null，用来控制 wrongMethod 方法的 4 个入参，以模拟各种空指针情况： + +private List wrongMethod(FooService fooService, Integer i, String s, String t) { + log.info("result {} {} {} {}", i + 1, s.equals("OK"), s.equals(t), + new ConcurrentHashMap().put(null, null)); + if (fooService.getBarService().bar().equals("OK")) + log.info("OK"); + return null; +} + +@GetMapping("wrong") +public int wrong(@RequestParam(value = "test", defaultValue = "1111") String test) { + return wrongMethod(test.charAt(0) == '1' ? null : new FooService(), + test.charAt(1) == '1' ? null : 1, + test.charAt(2) == '1' ? null : "OK", + test.charAt(3) == '1' ? null : "OK").size(); +} + +class FooService { + @Getter + private BarService barService; +} + +class BarService { + String bar() { + return "OK"; + } +} + + +很明显，这个案例出现空指针异常是因为变量是一个空指针，尝试获得变量的值或访问变量的成员会获得空指针异常。但，这个异常的定位比较麻烦。 + +在测试方法 wrongMethod 中，我们通过一行日志记录的操作，在一行代码中模拟了 4 处空指针异常： + +对入参 Integer i 进行 +1 操作； + +对入参 String s 进行比较操作，判断内容是否等于”OK”； + +对入参 String s 和入参 String t 进行比较操作，判断两者是否相等； + +对 new 出来的 ConcurrentHashMap 进行 put 操作，Key 和 Value 都设置为 null。 + +输出的异常信息如下： + +java.lang.NullPointerException: null + at org.geekbang.time.commonmistakes.nullvalue.demo2.AvoidNullPointerExceptionController.wrongMethod(AvoidNullPointerExceptionController.java:37) + at org.geekbang.time.commonmistakes.nullvalue.demo2.AvoidNullPointerExceptionController.wrong(AvoidNullPointerExceptionController.java:20) + + +这段信息确实提示了这行代码出现了空指针异常，但我们很难定位出到底是哪里出现了空指针，可能是把入参 Integer 拆箱为 int 的时候出现的，也可能是入参的两个字符串任意一个为 null，也可能是因为把 null 加入了 ConcurrentHashMap。 + +你可能会想到，要排查这样的问题，只要设置一个断点看一下入参即可。但，在真实的业务场景中，空指针问题往往是在特定的入参和代码分支下才会出现，本地难以重现。如果要排查生产上出现的空指针问题，设置代码断点不现实，通常是要么把代码进行拆分，要么增加更多的日志，但都比较麻烦。 + +在这里，我推荐使用阿里开源的 Java 故障诊断神器Arthas。Arthas 简单易用功能强大，可以定位出大多数的 Java 生产问题。 + +接下来，我就和你演示下如何在 30 秒内知道 wrongMethod 方法的入参，从而定位到空指针到底是哪个入参引起的。如下截图中有三个红框，我先和你分析第二和第三个红框： + +第二个红框表示，Arthas 启动后被附加到了 JVM 进程； + +第三个红框表示，通过 watch 命令监控 wrongMethod 方法的入参。 + + + +watch 命令的参数包括类名表达式、方法表达式和观察表达式。这里，我们设置观察类为 AvoidNullPointerExceptionController，观察方法为 wrongMethod，观察表达式为 params 表示观察入参： + +watch org.geekbang.time.commonmistakes.nullvalue.demo2.AvoidNullPointerExceptionController wrongMethod params + + +开启 watch 后，执行 2 次 wrong 方法分别设置 test 入参为 1111 和 1101，也就是第一次传入 wrongMethod 的 4 个参数都为 null，第二次传入的第 1、2 和 4 个参数为 null。 + +配合图中第一和第四个红框可以看到，第二次调用时，第三个参数是字符串 OK 其他参数是 null，Archas 正确输出了方法的所有入参，这样我们很容易就能定位到空指针的问题了。 + +到这里，如果是简单的业务逻辑的话，你就可以定位到空指针异常了；如果是分支复杂的业务逻辑，你需要再借助 stack 命令来查看 wrongMethod 方法的调用栈，并配合 watch 命令查看各方法的入参，就可以很方便地定位到空指针的根源了。 + +下图演示了通过 stack 命令观察 wrongMethod 的调用路径： + + + +如果你想了解 Arthas 各种命令的详细使用方法，可以点击这里查看。 + +接下来，我们看看如何修复上面出现的 5 种空指针异常。 + +其实，对于任何空指针异常的处理，最直白的方式是先判空后操作。不过，这只能让异常不再出现，我们还是要找到程序逻辑中出现的空指针究竟是来源于入参还是 Bug： + +如果是来源于入参，还要进一步分析入参是否合理等； + +如果是来源于 Bug，那空指针不一定是纯粹的程序 Bug，可能还涉及业务属性和接口调用规范等。 + +在这里，因为是 Demo，所以我们只考虑纯粹的空指针判空这种修复方式。如果要先判空后处理，大多数人会想到使用 if-else 代码块。但，这种方式既增加代码量又会降低易读性，我们可以尝试利用 Java 8 的 Optional 类来消除这样的 if-else 逻辑，使用一行代码进行判空和处理。 + +修复思路如下： + +对于 Integer 的判空，可以使用 Optional.ofNullable 来构造一个 Optional，然后使用 orElse(0) 把 null 替换为默认值再进行 +1 操作。 + +对于 String 和字面量的比较，可以把字面量放在前面，比如”OK”.equals(s)，这样即使 s 是 null 也不会出现空指针异常；而对于两个可能为 null 的字符串变量的 equals 比较，可以使用 Objects.equals，它会做判空处理。 + +对于 ConcurrentHashMap，既然其 Key 和 Value 都不支持 null，修复方式就是不要把 null 存进去。HashMap 的 Key 和 Value 可以存入 null，而 ConcurrentHashMap 看似是 HashMap 的线程安全版本，却不支持 null 值的 Key 和 Value，这是容易产生误区的一个地方。 + +对于类似 fooService.getBarService().bar().equals(“OK”) 的级联调用，需要判空的地方有很多，包括 fooService、getBarService() 方法的返回值，以及 bar 方法返回的字符串。如果使用 if-else 来判空的话可能需要好几行代码，但使用 Optional 的话一行代码就够了。 + +对于 rightMethod 返回的 List，由于不能确认其是否为 null，所以在调用 size 方法获得列表大小之前，同样可以使用 Optional.ofNullable 包装一下返回值，然后通过.orElse(Collections.emptyList()) 实现在 List 为 null 的时候获得一个空的 List，最后再调用 size 方法。 + +private List rightMethod(FooService fooService, Integer i, String s, String t) { + log.info("result {} {} {} {}", Optional.ofNullable(i).orElse(0) + 1, "OK".equals(s), Objects.equals(s, t), new HashMap().put(null, null)); + Optional.ofNullable(fooService) + .map(FooService::getBarService) + .filter(barService -> "OK".equals(barService.bar())) + .ifPresent(result -> log.info("OK")); + return new ArrayList<>(); +} + +@GetMapping("right") +public int right(@RequestParam(value = "test", defaultValue = "1111") String test) { + return Optional.ofNullable(rightMethod(test.charAt(0) == '1' ? null : new FooService(), + test.charAt(1) == '1' ? null : 1, + test.charAt(2) == '1' ? null : "OK", + test.charAt(3) == '1' ? null : "OK")) + .orElse(Collections.emptyList()).size(); +} + + +经过修复后，调用 right 方法传入 1111，也就是给 rightMethod 的 4 个参数都设置为 null，日志中也看不到任何空指针异常了： + +[21:43:40.619] [http-nio-45678-exec-2] [INFO ] [.AvoidNullPointerExceptionController:45 ] - result 1 false true null + + +但是，如果我们修改 right 方法入参为 0000，即传给 rightMethod 方法的 4 个参数都不可能是 null，最后日志中也无法出现 OK 字样。这又是为什么呢，BarService 的 bar 方法不是返回了 OK 字符串吗？ + +我们还是用 Arthas 来定位问题，使用 watch 命令来观察方法 rightMethod 的入参，-x 参数设置为 2 代表参数打印的深度为 2 层： + + + +可以看到，FooService 中的 barService 字段为 null，这样也就可以理解为什么最终出现这个 Bug 了。 + +这又引申出一个问题，使用判空方式或 Optional 方式来避免出现空指针异常，不一定是解决问题的最好方式，空指针没出现可能隐藏了更深的 Bug。因此，解决空指针异常，还是要真正 case by case 地定位分析案例，然后再去做判空处理，而处理时也并不只是判断非空然后进行正常业务流程这么简单，同样需要考虑为空的时候是应该出异常、设默认值还是记录日志等。 + +POJO 中属性的 null 到底代表了什么？ + +在我看来，相比判空避免空指针异常，更容易出错的是 null 的定位问题。对程序来说，null 就是指针没有任何指向，而结合业务逻辑情况就复杂得多，我们需要考虑： + +DTO 中字段的 null 到底意味着什么？是客户端没有传给我们这个信息吗？ + +既然空指针问题很讨厌，那么 DTO 中的字段要设置默认值么？ + +如果数据库实体中的字段有 null，那么通过数据访问框架保存数据是否会覆盖数据库中的既有数据？ + +如果不能明确地回答这些问题，那么写出的程序逻辑很可能会混乱不堪。接下来，我们看一个实际案例吧。 + +有一个 User 的 POJO，同时扮演 DTO 和数据库 Entity 角色，包含用户 ID、姓名、昵称、年龄、注册时间等属性： + +@Data +@Entity +public class User { + + @Id + @GeneratedValue(strategy = IDENTITY) + private Long id; + + private String name; + + private String nickname; + + private Integer age; + + private Date createDate = new Date(); + +} + + +有一个 Post 接口用于更新用户数据，更新逻辑非常简单，根据用户姓名自动设置一个昵称，昵称的规则是“用户类型 + 姓名”，然后直接把客户端在 RequestBody 中使用 JSON 传过来的 User 对象通过 JPA 更新到数据库中，最后返回保存到数据库的数据。 + +@Autowired +private UserRepository userRepository; + +@PostMapping("wrong") +public User wrong(@RequestBody User user) { + user.setNickname(String.format("guest%s", user.getName())); + return userRepository.save(user); +} + +@Repository +public interface UserRepository extends JpaRepository { + +} + + +首先，在数据库中初始化一个用户，age=36、name=zhuye、create_date=2020 年 1 月 4 日、nickname 是 NULL： + + + +然后，使用 cURL 测试一下用户信息更新接口 Post，传入一个 id=1、name=null 的 JSON 字符串，期望把 ID 为 1 的用户姓名设置为空： + +curl -H "Content-Type:application/json" -X POST -d '{ "id":1, "name":null}' http://localhost:45678/pojonull/wrong + +{"id":1,"name":null,"nickname":"guestnull","age":null,"createDate":"2020-01-05T02:01:03.784+0000"}% + + +接口返回的结果和数据库中记录一致： + + + +可以看到，这里存在如下三个问题： + +调用方只希望重置用户名，但 age 也被设置为了 null； + +nickname 是用户类型加姓名，name 重置为 null 的话，访客用户的昵称应该是 guest，而不是 guestnull，重现了文首提到的那个笑点； + +用户的创建时间原来是 1 月 4 日，更新了用户信息后变为了 1 月 5 日。 + +归根结底，这是如下 5 个方面的问题： + +明确 DTO 中 null 的含义。对于 JSON 到 DTO 的反序列化过程，null 的表达是有歧义的，客户端不传某个属性，或者传 null，这个属性在 DTO 中都是 null。但，对于用户信息更新操作，不传意味着客户端不需要更新这个属性，维持数据库原先的值；传了 null，意味着客户端希望重置这个属性。因为 Java 中的 null 就是没有这个数据，无法区分这两种表达，所以本例中的 age 属性也被设置为了 null，或许我们可以借助 Optional 来解决这个问题。 + +POJO 中的字段有默认值。如果客户端不传值，就会赋值为默认值，导致创建时间也被更新到了数据库中。 + +注意字符串格式化时可能会把 null 值格式化为 null 字符串。比如昵称的设置，我们只是进行了简单的字符串格式化，存入数据库变为了 guestnull。显然，这是不合理的，也是开头我们说的笑话的来源，还需要进行判断。 + +DTO 和 Entity 共用了一个 POJO。对于用户昵称的设置是程序控制的，我们不应该把它们暴露在 DTO 中，否则很容易把客户端随意设置的值更新到数据库中。此外，创建时间最好让数据库设置为当前时间，不用程序控制，可以通过在字段上设置 columnDefinition 来实现。 + +数据库字段允许保存 null，会进一步增加出错的可能性和复杂度。因为如果数据真正落地的时候也支持 NULL 的话，可能就有 NULL、空字符串和字符串 null 三种状态。这一点我会在下一小节展开。如果所有属性都有默认值，问题会简单一点。 + +按照这个思路，我们对 DTO 和 Entity 进行拆分，修改后代码如下所示： + +UserDto 中只保留 id、name 和 age 三个属性，且 name 和 age 使用 Optional 来包装，以区分客户端不传数据还是故意传 null。 + +在 UserEntity 的字段上使用 @Column 注解，把数据库字段 name、nickname、age 和 createDate 都设置为 NOT NULL，并设置 createDate 的默认值为 CURRENT_TIMESTAMP，由数据库来生成创建时间。 + +使用 Hibernate 的 @DynamicUpdate 注解实现更新 SQL 的动态生成，实现只更新修改后的字段，不过需要先查询一次实体，让 Hibernate 可以“跟踪”实体属性的当前状态，以确保有效。 + +@Data +public class UserDto { + + private Long id; + + private Optional name; + + private Optional age; + +; + +@Data +@Entity +@DynamicUpdate +public class UserEntity { + + @Id + @GeneratedValue(strategy = IDENTITY) + private Long id; + + @Column(nullable = false) + private String name; + + @Column(nullable = false) + private String nickname; + + @Column(nullable = false) + private Integer age; + + @Column(nullable = false, columnDefinition = "TIMESTAMP DEFAULT CURRENT_TIMESTAMP") + private Date createDate; + +} + + +在重构了 DTO 和 Entity 后，我们重新定义一个 right 接口，以便对更新操作进行更精细化的处理。首先是参数校验： + +对传入的 UserDto 和 ID 属性先判空，如果为空直接抛出 IllegalArgumentException。 + +根据 id 从数据库中查询出实体后进行判空，如果为空直接抛出 IllegalArgumentException。 + +然后，由于 DTO 中已经巧妙使用了 Optional 来区分客户端不传值和传 null 值，那么业务逻辑实现上就可以按照客户端的意图来分别实现逻辑。如果不传值，那么 Optional 本身为 null，直接跳过 Entity 字段的更新即可，这样动态生成的 SQL 就不会包含这个列；如果传了值，那么进一步判断传的是不是 null。 + +下面，我们根据业务需要分别对姓名、年龄和昵称进行更新： + +对于姓名，我们认为客户端传 null 是希望把姓名重置为空，允许这样的操作，使用 Optional 的 orElse 方法一键把空转换为空字符串即可。 + +对于年龄，我们认为如果客户端希望更新年龄就必须传一个有效的年龄，年龄不存在重置操作，可以使用 Optional 的 orElseThrow 方法在值为空的时候抛出 IllegalArgumentException。 + +对于昵称，因为数据库中姓名不可能为 null，所以可以放心地把昵称设置为 guest 加上数据库取出来的姓名。 + +@PostMapping("right") +public UserEntity right(@RequestBody UserDto user) { + + if (user == null || user.getId() == null) + throw new IllegalArgumentException("用户Id不能为空"); + UserEntity userEntity = userEntityRepository.findById(user.getId()) + .orElseThrow(() -> new IllegalArgumentException("用户不存在")); + if (user.getName() != null) { + userEntity.setName(user.getName().orElse("")); + } + + userEntity.setNickname("guest" + userEntity.getName()); + if (user.getAge() != null) { + userEntity.setAge(user.getAge().orElseThrow(() -> new IllegalArgumentException("年龄不能为空"))); + } + return userEntityRepository.save(userEntity); +} + + +假设数据库中已经有这么一条记录，id=1、age=36、create_date=2020 年 1 月 4 日、name=zhuye、nickname=guestzhuye： + + + +使用相同的参数调用 right 接口，再来试试是否解决了所有问题。传入一个 id=1、name=null 的 JSON 字符串，期望把 id 为 1 的用户姓名设置为空： + +curl -H "Content-Type:application/json" -X POST -d '{ "id":1, "name":null}' http://localhost:45678/pojonull/right + +{"id":1,"name":"","nickname":"guest","age":36,"createDate":"2020-01-04T11:09:20.000+0000"}% + + +结果如下： + + + +可以看到，right 接口完美实现了仅重置 name 属性的操作，昵称也不再有 null 字符串，年龄和创建时间字段也没被修改。 + +通过日志可以看到，Hibernate 生成的 SQL 语句只更新了 name 和 nickname 两个字段： + +Hibernate: update user_entity set name=?, nickname=? where id=? + + +接下来，为了测试使用 Optional 是否可以有效区分 JSON 中没传属性还是传了 null，我们在 JSON 中设置了一个 null 的 age，结果是正确得到了年龄不能为空的错误提示： + +curl -H "Content-Type:application/json" -X POST -d '{ "id":1, "age":null}' http://localhost:45678/pojonull/right + +{"timestamp":"2020-01-05T03:14:40.324+0000","status":500,"error":"Internal Server Error","message":"年龄不能为空","path":"/pojonull/right"}% + + +小心 MySQL 中有关 NULL 的三个坑 + +前面提到，数据库表字段允许存 NULL 除了会让我们困惑外，还容易有坑。这里我会结合 NULL 字段，和你着重说明 sum 函数、count 函数，以及 NULL 值条件可能踩的坑。 + +为方便演示，首先定义一个只有 id 和 score 两个字段的实体： + +@Entity +@Data +public class User { + + @Id + @GeneratedValue(strategy = IDENTITY) + private Long id; + + private Long score; +} + + +程序启动的时候，往实体初始化一条数据，其 id 是自增列自动设置的 1，score 是 NULL： + +@Autowired +private UserRepository userRepository; +@PostConstruct +public void init() { + + userRepository.save(new User()); + +} + + +然后，测试下面三个用例，来看看结合数据库中的 null 值可能会出现的坑： + +通过 sum 函数统计一个只有 NULL 值的列的总和，比如 SUM(score)； + +select 记录数量，count 使用一个允许 NULL 的字段，比如 COUNT(score)； + +使用 =NULL 条件查询字段值为 NULL 的记录，比如 score=null 条件。 + +@Repository +public interface UserRepository extends JpaRepository { + + @Query(nativeQuery=true,value = "SELECT SUM(score) FROM `user`") + Long wrong1(); + + @Query(nativeQuery = true, value = "SELECT COUNT(score) FROM `user`") + Long wrong2(); + + @Query(nativeQuery = true, value = "SELECT * FROM `user` WHERE score=null") + List wrong3(); + +} + + +得到的结果，分别是 null、0 和空 List： + +[11:38:50.137] [http-nio-45678-exec-1] [INFO ] [t.c.nullvalue.demo3.DbNullController:26 ] - result: null 0 [] + + +显然，这三条 SQL 语句的执行结果和我们的期望不同： + +虽然记录的 score 都是 NULL，但 sum 的结果应该是 0 才对； + +虽然这条记录的 score 是 NULL，但记录总数应该是 1 才对； + +使用 =NULL 并没有查询到 id=1 的记录，查询条件失效。 + +原因是： + +MySQL 中 sum 函数没统计到任何记录时，会返回 null 而不是 0，可以使用 IFNULL 函数把 null 转换为 0； + +MySQL 中 count 字段不统计 null 值，COUNT(*) 才是统计所有记录数量的正确方式。 + +MySQL 中使用诸如 =、<、> 这样的算数比较操作符比较 NULL 的结果总是 NULL，这种比较就显得没有任何意义，需要使用 IS NULL、IS NOT NULL 或 ISNULL() 函数来比较。 + +修改一下 SQL： + +@Query(nativeQuery = true, value = "SELECT IFNULL(SUM(score),0) FROM `user`") +Long right1(); + +@Query(nativeQuery = true, value = "SELECT COUNT(*) FROM `user`") +Long right2(); + +@Query(nativeQuery = true, value = "SELECT * FROM `user` WHERE score IS NULL") +List right3(); + + +可以得到三个正确结果，分别为 0、1、[User(id=1, score=null)] ： + +[14:50:35.768] [http-nio-45678-exec-1] [INFO ] [t.c.nullvalue.demo3.DbNullController:31 ] - result: 0 1 [User(id=1, score=null)] + + +重点回顾 + +今天，我和你讨论了做好空值处理需要注意的几个问题。 + +我首先总结了业务代码中 5 种最容易出现空指针异常的写法，以及相应的修复方式。针对判空，通过 Optional 配合 Stream 可以避免大多数冗长的 if-else 判空逻辑，实现一行代码优雅判空。另外，要定位和修复空指针异常，除了可以通过增加日志进行排查外，在生产上使用 Arthas 来查看方法的调用栈和入参会更快捷。 + +在我看来，业务系统最基本的标准是不能出现未处理的空指针异常，因为它往往代表了业务逻辑的中断，所以我建议每天查询一次生产日志来排查空指针异常，有条件的话建议订阅空指针异常报警，以便及时发现及时处理。 + +POJO 中字段的 null 定位，从服务端的角度往往很难分清楚，到底是客户端希望忽略这个字段还是有意传了 null，因此我们尝试用 Optional类来区分 null 的定位。同时，为避免把空值更新到数据库中，可以实现动态 SQL，只更新必要的字段。 + +最后，我分享了数据库字段使用 NULL 可能会带来的三个坑（包括 sum 函数、count 函数，以及 NULL 值条件），以及解决方式。 + +总结来讲，null 的正确处理以及避免空指针异常，绝不是判空这么简单，还要根据业务属性从前到后仔细考虑，客户端传入的 null 代表了什么，出现了 null 是否允许使用默认值替代，入库的时候应该传入 null 还是空值，并确保整个逻辑处理的一致性，才能尽量避免 Bug。 + +为处理好 null，作为客户端的开发者，需要和服务端对齐字段 null 的含义以及降级逻辑；而作为服务端的开发者，需要对入参进行前置判断，提前挡掉服务端不可接受的空值，同时在整个业务逻辑过程中进行完善的空值处理。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +ConcurrentHashMap 的 Key 和 Value 都不能为 null，而 HashMap 却可以，你知道这么设计的原因是什么吗？TreeMap、Hashtable 等 Map 的 Key 和 Value 是否支持 null 呢？ + +对于 Hibernate 框架可以使用 @DynamicUpdate 注解实现字段的动态更新，对于 MyBatis 框架如何实现类似的动态 SQL 功能，实现插入和修改 SQL 只包含 POJO 中的非空字段？ + +关于程序和数据库中的 null、空指针问题，你还遇到过什么坑吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/12异常处理：别让自己在出问题的时候变为瞎子.md b/专栏/Java业务开发常见错误100例/12异常处理：别让自己在出问题的时候变为瞎子.md new file mode 100644 index 0000000..2038e36 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/12异常处理：别让自己在出问题的时候变为瞎子.md @@ -0,0 +1,556 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 12 异常处理：别让自己在出问题的时候变为瞎子 + 今天，我来和你聊聊异常处理容易踩的坑。 + +应用程序避免不了出异常，捕获和处理异常是考验编程功力的一个精细活。一些业务项目中，我曾看到开发同学在开发业务逻辑时不考虑任何异常处理，项目接近完成时再采用“流水线”的方式进行异常处理，也就是统一为所有方法打上 try…catch…捕获所有异常记录日志，有些技巧的同学可能会使用 AOP 来进行类似的“统一异常处理”。 + +其实，这种处理异常的方式非常不可取。那么今天，我就和你分享下不可取的原因、与异常处理相关的坑和最佳实践。 + +捕获和处理异常容易犯的错 + +“统一异常处理”方式正是我要说的第一个错：不在业务代码层面考虑异常处理，仅在框架层面粗犷捕获和处理异常。 + +为了理解错在何处，我们先来看看大多数业务应用都采用的三层架构： + +Controller 层负责信息收集、参数校验、转换服务层处理的数据适配前端，轻业务逻辑； + +Service 层负责核心业务逻辑，包括各种外部服务调用、访问数据库、缓存处理、消息处理等； + +Repository 层负责数据访问实现，一般没有业务逻辑。 + + + +每层架构的工作性质不同，且从业务性质上异常可能分为业务异常和系统异常两大类，这就决定了很难进行统一的异常处理。我们从底向上看一下三层架构： + +Repository 层出现异常或许可以忽略，或许可以降级，或许需要转化为一个友好的异常。如果一律捕获异常仅记录日志，很可能业务逻辑已经出错，而用户和程序本身完全感知不到。 + +Service 层往往涉及数据库事务，出现异常同样不适合捕获，否则事务无法自动回滚。此外 Service 层涉及业务逻辑，有些业务逻辑执行中遇到业务异常，可能需要在异常后转入分支业务流程。如果业务异常都被框架捕获了，业务功能就会不正常。 + +如果下层异常上升到 Controller 层还是无法处理的话，Controller 层往往会给予用户友好提示，或是根据每一个 API 的异常表返回指定的异常类型，同样无法对所有异常一视同仁。 + +因此，我不建议在框架层面进行异常的自动、统一处理，尤其不要随意捕获异常。但，框架可以做兜底工作。如果异常上升到最上层逻辑还是无法处理的话，可以以统一的方式进行异常转换，比如通过 @RestControllerAdvice + @ExceptionHandler，来捕获这些“未处理”异常： + +对于自定义的业务异常，以 Warn 级别的日志记录异常以及当前 URL、执行方法等信息后，提取异常中的错误码和消息等信息，转换为合适的 API 包装体返回给 API 调用方； + +对于无法处理的系统异常，以 Error 级别的日志记录异常和上下文信息（比如 URL、参数、用户 ID）后，转换为普适的“服务器忙，请稍后再试”异常信息，同样以 API 包装体返回给调用方。 + +比如，下面这段代码的做法： + +@RestControllerAdvice +@Slf4j +public class RestControllerExceptionHandler { + + private static int GENERIC_SERVER_ERROR_CODE = 2000; + + private static String GENERIC_SERVER_ERROR_MESSAGE = "服务器忙，请稍后再试"; + + @ExceptionHandler + public APIResponse handle(HttpServletRequest req, HandlerMethod method, Exception ex) { + + if (ex instanceof BusinessException) { + BusinessException exception = (BusinessException) ex; + log.warn(String.format("访问 %s -> %s 出现业务异常！", req.getRequestURI(), method.toString()), ex); + return new APIResponse(false, null, exception.getCode(), exception.getMessage()); + } else { + log.error(String.format("访问 %s -> %s 出现系统异常！", req.getRequestURI(), method.toString()), ex); + return new APIResponse(false, null, GENERIC_SERVER_ERROR_CODE, GENERIC_SERVER_ERROR_MESSAGE); + } + } +} + + +出现运行时系统异常后，异常处理程序会直接把异常转换为 JSON 返回给调用方： + + + +要做得更好，你可以把相关出入参、用户信息在脱敏后记录到日志中，方便出现问题时根据上下文进一步排查。 + +第二个错，捕获了异常后直接生吞。在任何时候，我们捕获了异常都不应该生吞，也就是直接丢弃异常不记录、不抛出。这样的处理方式还不如不捕获异常，因为被生吞掉的异常一旦导致 Bug，就很难在程序中找到蛛丝马迹，使得 Bug 排查工作难上加难。 + +通常情况下，生吞异常的原因，可能是不希望自己的方法抛出受检异常，只是为了把异常“处理掉”而捕获并生吞异常，也可能是想当然地认为异常并不重要或不可能产生。但不管是什么原因，不管是你认为多么不重要的异常，都不应该生吞，哪怕是一个日志也好。 + +第三个错，丢弃异常的原始信息。我们来看两个不太合适的异常处理方式，虽然没有完全生吞异常，但也丢失了宝贵的异常信息。 + +比如有这么一个会抛出受检异常的方法 readFile： + +private void readFile() throws IOException { + Files.readAllLines(Paths.get("a_file")); +} + + +像这样调用 readFile 方法，捕获异常后，完全不记录原始异常，直接抛出一个转换后异常，导致出了问题不知道 IOException 具体是哪里引起的： + +@GetMapping("wrong1") +public void wrong1(){ + + try { + readFile(); + } catch (IOException e) { + //原始异常信息丢失 + throw new RuntimeException("系统忙请稍后再试"); + } +} + + +或者是这样，只记录了异常消息，却丢失了异常的类型、栈等重要信息： + +catch (IOException e) { + //只保留了异常消息，栈没有记录 + log.error("文件读取错误, {}", e.getMessage()); + throw new RuntimeException("系统忙请稍后再试"); +} + + +留下的日志是这样的，看完一脸茫然，只知道文件读取错误的文件名，至于为什么读取错误、是不存在还是没权限，完全不知道。 + +[12:57:19.746] [http-nio-45678-exec-1] [ERROR] [.g.t.c.e.d.HandleExceptionController:35 ] - 文件读取错误, a_file + + +这两种处理方式都不太合理，可以改为如下方式： + +catch (IOException e) { + log.error("文件读取错误", e); + throw new RuntimeException("系统忙请稍后再试"); +} + + +或者，把原始异常作为转换后新异常的 cause，原始异常信息同样不会丢： + +catch (IOException e) { + throw new RuntimeException("系统忙请稍后再试", e); +} + + +其实，JDK 内部也会犯类似的错。之前我遇到一个使用 JDK10 的应用偶发启动失败的案例，日志中可以看到出现类似的错误信息： + +Caused by: java.lang.SecurityException: Couldn't parse jurisdiction policy files in: unlimited + at java.base/javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:355) + at java.base/javax.crypto.JceSecurity.access$000(JceSecurity.java:73) + at java.base/javax.crypto.JceSecurity$1.run(JceSecurity.java:109) + at java.base/javax.crypto.JceSecurity$1.run(JceSecurity.java:106) + at java.base/java.security.AccessController.doPrivileged(Native Method) + at java.base/javax.crypto.JceSecurity.(JceSecurity.java:105) + ... 20 more + + +查看 JDK JceSecurity 类 setupJurisdictionPolicies 方法源码，发现异常 e 没有记录，也没有作为新抛出异常的 cause，当时读取文件具体出现什么异常（权限问题又或是 IO 问题）可能永远都无法知道了，对问题定位造成了很大困扰： + + + +第四个错，抛出异常时不指定任何消息。我见过一些代码中的偷懒做法，直接抛出没有 message 的异常： + +throw new RuntimeException(); + + +这么写的同学可能觉得永远不会走到这个逻辑，永远不会出现这样的异常。但，这样的异常却出现了，被 ExceptionHandler 拦截到后输出了下面的日志信息： + +[13:25:18.031] [http-nio-45678-exec-3] [ERROR] [c.e.d.RestControllerExceptionHandler:24 ] - 访问 /handleexception/wrong3 -> org.geekbang.time.commonmistakes.exception.demo1.HandleExceptionController#wrong3(String) 出现系统异常！ +java.lang.RuntimeException: null +... + + +这里的 null 非常容易引起误解。按照空指针问题排查半天才发现，其实是异常的 message 为空。 + +总之，如果你捕获了异常打算处理的话，除了通过日志正确记录异常原始信息外，通常还有三种处理模式： + +转换，即转换新的异常抛出。对于新抛出的异常，最好具有特定的分类和明确的异常消息，而不是随便抛一个无关或没有任何信息的异常，并最好通过 cause 关联老异常。 + +重试，即重试之前的操作。比如远程调用服务端过载超时的情况，盲目重试会让问题更严重，需要考虑当前情况是否适合重试。 + +恢复，即尝试进行降级处理，或使用默认值来替代原始数据。 + +以上，就是通过 catch 捕获处理异常的一些最佳实践。 + +小心 finally 中的异常 + +有些时候，我们希望不管是否遇到异常，逻辑完成后都要释放资源，这时可以使用 finally 代码块而跳过使用 catch 代码块。 + +但要千万小心 finally 代码块中的异常，因为资源释放处理等收尾操作同样也可能出现异常。比如下面这段代码，我们在 finally 中抛出一个异常： + +@GetMapping("wrong") +public void wrong() { + try { + log.info("try"); + //异常丢失 + throw new RuntimeException("try"); + } finally { + log.info("finally"); + throw new RuntimeException("finally"); + } +} + + +最后在日志中只能看到 finally 中的异常，虽然 try 中的逻辑出现了异常，但却被 finally 中的异常覆盖了。这是非常危险的，特别是 finally 中出现的异常是偶发的，就会在部分时候覆盖 try 中的异常，让问题更不明显： + +[13:34:42.247] [http-nio-45678-exec-1] [ERROR] [.a.c.c.C.[.[.[/].[dispatcherServlet]:175 ] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.RuntimeException: finally] with root cause +java.lang.RuntimeException: finally + + +至于异常为什么被覆盖，原因也很简单，因为一个方法无法出现两个异常。修复方式是，finally 代码块自己负责异常捕获和处理： + +@GetMapping("right") +public void right() { + try { + log.info("try"); + throw new RuntimeException("try"); + } finally { + log.info("finally"); + try { + throw new RuntimeException("finally"); + } catch (Exception ex) { + log.error("finally", ex); + } + } +} + + +或者可以把 try 中的异常作为主异常抛出，使用 addSuppressed 方法把 finally 中的异常附加到主异常上： + +@GetMapping("right2") +public void right2() throws Exception { + Exception e = null; + try { + log.info("try"); + throw new RuntimeException("try"); + } catch (Exception ex) { + e = ex; + } finally { + log.info("finally"); + try { + throw new RuntimeException("finally"); + } catch (Exception ex) { + if (e!= null) { + e.addSuppressed(ex); + } else { + e = ex; + } + } + } + throw e; +} + + +运行方法可以得到如下异常信息，其中同时包含了主异常和被屏蔽的异常： + +java.lang.RuntimeException: try + at org.geekbang.time.commonmistakes.exception.finallyissue.FinallyIssueController.right2(FinallyIssueController.java:69) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + ... + Suppressed: java.lang.RuntimeException: finally + at org.geekbang.time.commonmistakes.exception.finallyissue.FinallyIssueController.right2(FinallyIssueController.java:75) + ... 54 common frames omitted + + +其实这正是 try-with-resources 语句的做法，对于实现了 AutoCloseable 接口的资源，建议使用 try-with-resources 来释放资源，否则也可能会产生刚才提到的，释放资源时出现的异常覆盖主异常的问题。比如如下我们定义一个测试资源，其 read 和 close 方法都会抛出异常： + +public class TestResource implements AutoCloseable { + + public void read() throws Exception{ + throw new Exception("read error"); + } + + @Override + public void close() throws Exception { + throw new Exception("close error"); + } +} + + +使用传统的 try-finally 语句，在 try 中调用 read 方法，在 finally 中调用 close 方法： + +@GetMapping("useresourcewrong") +public void useresourcewrong() throws Exception { + + TestResource testResource = new TestResource(); + try { + testResource.read(); + } finally { + testResource.close(); + } +} + + +可以看到，同样出现了 finally 中的异常覆盖了 try 中异常的问题： + +java.lang.Exception: close error + at org.geekbang.time.commonmistakes.exception.finallyissue.TestResource.close(TestResource.java:10) + at org.geekbang.time.commonmistakes.exception.finallyissue.FinallyIssueController.useresourcewrong(FinallyIssueController.java:27) + + +而改为 try-with-resources 模式之后： + +@GetMapping("useresourceright") +public void useresourceright() throws Exception { + try (TestResource testResource = new TestResource()){ + testResource.read(); + } +} + + +try 和 finally 中的异常信息都可以得到保留： + +java.lang.Exception: read error + at org.geekbang.time.commonmistakes.exception.finallyissue.TestResource.read(TestResource.java:6) + ... + Suppressed: java.lang.Exception: close error + at org.geekbang.time.commonmistakes.exception.finallyissue.TestResource.close(TestResource.java:10) + at org.geekbang.time.commonmistakes.exception.finallyissue.FinallyIssueController.useresourceright(FinallyIssueController.java:35) + ... 54 common frames omitted + + +千万别把异常定义为静态变量 + +既然我们通常会自定义一个业务异常类型，来包含更多的异常信息，比如异常错误码、友好的错误提示等，那就需要在业务逻辑各处，手动抛出各种业务异常来返回指定的错误码描述（比如对于下单操作，用户不存在返回 2001，商品缺货返回 2002 等）。 + +对于这些异常的错误代码和消息，我们期望能够统一管理，而不是散落在程序各处定义。这个想法很好，但稍有不慎就可能会出现把异常定义为静态变量的坑。 + +我在救火排查某项目生产问题时，遇到了一件非常诡异的事情：我发现异常堆信息显示的方法调用路径，在当前入参的情况下根本不可能产生，项目的业务逻辑又很复杂，就始终没往异常信息是错的这方面想，总觉得是因为某个分支流程导致业务没有按照期望的流程进行。 + +经过艰难的排查，最终定位到原因是把异常定义为了静态变量，导致异常栈信息错乱，类似于定义一个 Exceptions 类来汇总所有的异常，把异常存放在静态字段中： + +public class Exceptions { + public static BusinessException ORDEREXISTS = new BusinessException("订单已经存在", 3001); +... +} + + +把异常定义为静态变量会导致异常信息固化，这就和异常的栈一定是需要根据当前调用来动态获取相矛盾。 + +我们写段代码来模拟下这个问题：定义两个方法 createOrderWrong 和 cancelOrderWrong 方法，它们内部都会通过 Exceptions 类来获得一个订单不存在的异常；先后调用两个方法，然后抛出。 + +@GetMapping("wrong") +public void wrong() { + + try { + createOrderWrong(); + } catch (Exception ex) { + log.error("createOrder got error", ex); + } + + try { + cancelOrderWrong(); + } catch (Exception ex) { + log.error("cancelOrder got error", ex); + } + +} + +private void createOrderWrong() { + //这里有问题 + throw Exceptions.ORDEREXISTS; +} + +private void cancelOrderWrong() { + //这里有问题 + throw Exceptions.ORDEREXISTS; +} + + +运行程序后看到如下日志，cancelOrder got error 的提示对应了 createOrderWrong 方法。显然，cancelOrderWrong 方法在出错后抛出的异常，其实是 createOrderWrong 方法出错的异常： + +[14:05:25.782] [http-nio-45678-exec-1] [ERROR] [.c.e.d.PredefinedExceptionController:25 ] - cancelOrder got error +org.geekbang.time.commonmistakes.exception.demo2.BusinessException: 订单已经存在 + at org.geekbang.time.commonmistakes.exception.demo2.Exceptions.(Exceptions.java:5) + at org.geekbang.time.commonmistakes.exception.demo2.PredefinedExceptionController.createOrderWrong(PredefinedExceptionController.java:50) + at org.geekbang.time.commonmistakes.exception.demo2.PredefinedExceptionController.wrong(PredefinedExceptionController.java:18) + + +修复方式很简单，改一下 Exceptions 类的实现，通过不同的方法把每一种异常都 new 出来抛出即可： + +public class Exceptions { + + public static BusinessException orderExists(){ + return new BusinessException("订单已经存在", 3001); + } +} + + +提交线程池的任务出了异常会怎么样？ + +在第 3 讲介绍线程池时我提到，线程池常用作异步处理或并行处理。那么，把任务提交到线程池处理，任务本身出现异常时会怎样呢？ + +我们来看一个例子：提交 10 个任务到线程池异步处理，第 5 个任务抛出一个 RuntimeException，每个任务完成后都会输出一行日志： + +@GetMapping("execute") +public void execute() throws InterruptedException { + + String prefix = "test"; + ExecutorService threadPool = Executors.newFixedThreadPool(1, new ThreadFactoryBuilder().setNameFormat(prefix+"%d").get()); + + //提交10个任务到线程池处理，第5个任务会抛出运行时异常 + IntStream.rangeClosed(1, 10).forEach(i -> threadPool.execute(() -> { + if (i == 5) throw new RuntimeException("error"); + log.info("I'm done : {}", i); + })); + + threadPool.shutdown(); + threadPool.awaitTermination(1, TimeUnit.HOURS); +} + + +观察日志可以发现两点： + +... +[14:33:55.990] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:26 ] - I'm done : 4 +Exception in thread "test0" java.lang.RuntimeException: error + at org.geekbang.time.commonmistakes.exception.demo3.ThreadPoolAndExceptionController.lambda$null$0(ThreadPoolAndExceptionController.java:25) + at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) + at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) + at java.lang.Thread.run(Thread.java:748) +[14:33:55.990] [test1] [INFO ] [e.d.ThreadPoolAndExceptionController:26 ] - I'm done : 6 +... + + +任务 1 到 4 所在的线程是 test0，任务 6 开始运行在线程 test1。由于我的线程池通过线程工厂为线程使用统一的前缀 test 加上计数器进行命名，因此从线程名的改变可以知道因为异常的抛出老线程退出了，线程池只能重新创建一个线程。如果每个异步任务都以异常结束，那么线程池可能完全起不到线程重用的作用。 + +因为没有手动捕获异常进行处理，ThreadGroup 帮我们进行了未捕获异常的默认处理，向标准错误输出打印了出现异常的线程名称和异常信息。显然，这种没有以统一的错误日志格式记录错误信息打印出来的形式，对生产级代码是不合适的，ThreadGroup 的相关源码如下所示： + +public void uncaughtException(Thread t, Throwable e) { + if (parent != null) { + parent.uncaughtException(t, e); + } else { + Thread.UncaughtExceptionHandler ueh = + Thread.getDefaultUncaughtExceptionHandler(); + if (ueh != null) { + ueh.uncaughtException(t, e); + } else if (!(e instanceof ThreadDeath)) { + System.err.print("Exception in thread \"" + \+ t.getName() + "\" "); + e.printStackTrace(System.err); + } + } + } + + +修复方式有 2 步： + +以 execute 方法提交到线程池的异步任务，最好在任务内部做好异常处理； + +设置自定义的异常处理程序作为保底，比如在声明线程池时自定义线程池的未捕获异常处理程序： + +new ThreadFactoryBuilder() + .setNameFormat(prefix+"%d") + .setUncaughtExceptionHandler((thread, throwable)-> log.error("ThreadPool {} got exception", thread, throwable)) + .get() + + +或者设置全局的默认未捕获异常处理程序： + +static { + Thread.setDefaultUncaughtExceptionHandler((thread, throwable)-> log.error("Thread {} got exception", thread, throwable)); +} + + +通过线程池 ExecutorService 的 execute 方法提交任务到线程池处理，如果出现异常会导致线程退出，控制台输出中可以看到异常信息。那么，把 execute 方法改为 submit，线程还会退出吗，异常还能被处理程序捕获到吗？ + +修改代码后重新执行程序可以看到如下日志，说明线程没退出，异常也没记录被生吞了： + +[15:44:33.769] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 1 +[15:44:33.770] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 2 +[15:44:33.770] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 3 +[15:44:33.770] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 4 +[15:44:33.770] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 6 +[15:44:33.770] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 7 +[15:44:33.770] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 8 +[15:44:33.771] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 9 +[15:44:33.771] [test0] [INFO ] [e.d.ThreadPoolAndExceptionController:47 ] - I'm done : 10 + + +为什么会这样呢？ + +查看 FutureTask 源码可以发现，在执行任务出现异常之后，异常存到了一个 outcome 字段中，只有在调用 get 方法获取 FutureTask 结果的时候，才会以 ExecutionException 的形式重新抛出异常： + +public void run() { +... + try { + Callable c = callable; + if (c != null && state == NEW) { + V result; + boolean ran; + try { + result = c.call(); + ran = true; + } catch (Throwable ex) { + result = null; + ran = false; + setException(ex); + } +... +} + +protected void setException(Throwable t) { + if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) { + outcome = t; + UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); // final state + finishCompletion(); + } +} + +public V get() throws InterruptedException, ExecutionException { + int s = state; + if (s <= COMPLETING) + s = awaitDone(false, 0L); + return report(s); +} + +private V report(int s) throws ExecutionException { + Object x = outcome; + if (s == NORMAL) + return (V)x; + if (s >= CANCELLED) + throw new CancellationException(); + throw new ExecutionException((Throwable)x); +} + + +修改后的代码如下所示，我们把 submit 返回的 Future 放到了 List 中，随后遍历 List 来捕获所有任务的异常。这么做确实合乎情理。既然是以 submit 方式来提交任务，那么我们应该关心任务的执行结果，否则应该以 execute 来提交任务： + +List tasks = IntStream.rangeClosed(1, 10).mapToObj(i -> threadPool.submit(() -> { + if (i == 5) throw new RuntimeException("error"); + log.info("I'm done : {}", i); +})).collect(Collectors.toList()); + +tasks.forEach(task-> { + try { + task.get(); + } catch (Exception e) { + log.error("Got exception", e); + } +}); + + +执行这段程序可以看到如下的日志输出： + +[15:44:13.543] [http-nio-45678-exec-1] [ERROR] [e.d.ThreadPoolAndExceptionController:69 ] - Got exception +java.util.concurrent.ExecutionException: java.lang.RuntimeException: error + + +重点回顾 + +在今天的文章中，我介绍了处理异常容易犯的几个错和最佳实践。 + +第一，注意捕获和处理异常的最佳实践。首先，不应该用 AOP 对所有方法进行统一异常处理，异常要么不捕获不处理，要么根据不同的业务逻辑、不同的异常类型进行精细化、针对性处理；其次，处理异常应该杜绝生吞，并确保异常栈信息得到保留；最后，如果需要重新抛出异常的话，请使用具有意义的异常类型和异常消息。 + +第二，务必小心 finally 代码块中资源回收逻辑，确保 finally 代码块不出现异常，内部把异常处理完毕，避免 finally 中的异常覆盖 try 中的异常；或者考虑使用 addSuppressed 方法把 finally 中的异常附加到 try 中的异常上，确保主异常信息不丢失。此外，使用实现了 AutoCloseable 接口的资源，务必使用 try-with-resources 模式来使用资源，确保资源可以正确释放，也同时确保异常可以正确处理。 + +第三，虽然在统一的地方定义收口所有的业务异常是一个不错的实践，但务必确保异常是每次 new 出来的，而不能使用一个预先定义的 static 字段存放异常，否则可能会引起栈信息的错乱。 + +第四，确保正确处理了线程池中任务的异常，如果任务通过 execute 提交，那么出现异常会导致线程退出，大量的异常会导致线程重复创建引起性能问题，我们应该尽可能确保任务不出异常，同时设置默认的未捕获异常处理程序来兜底；如果任务通过 submit 提交意味着我们关心任务的执行结果，应该通过拿到的 Future 调用其 get 方法来获得任务运行结果和可能出现的异常，否则异常可能就被生吞了。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +关于在 finally 代码块中抛出异常的坑，如果在 finally 代码块中返回值，你觉得程序会以 try 或 catch 中返回值为准，还是以 finally 中的返回值为准呢？ + +对于手动抛出的异常，不建议直接使用 Exception 或 RuntimeException，通常建议复用 JDK 中的一些标准异常，比如IllegalArgumentException、IllegalStateException、UnsupportedOperationException，你能说说它们的适用场景，并列出更多常用异常吗？ + +不知道针对异常处理，你还遇到过什么坑，还有什么最佳实践的心得吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/13日志：日志记录真没你想象的那么简单.md b/专栏/Java业务开发常见错误100例/13日志：日志记录真没你想象的那么简单.md new file mode 100644 index 0000000..afbf2ac --- /dev/null +++ b/专栏/Java业务开发常见错误100例/13日志：日志记录真没你想象的那么简单.md @@ -0,0 +1,657 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 13 日志：日志记录真没你想象的那么简单 + 今天，我和你分享的是，记录日志可能会踩的坑。 + +一些同学可能要说了，记录日志还不简单，无非是几个常用的 API 方法，比如 debug、info、warn、error；但我就见过不少坑都是记录日志引起的，容易出错主要在于三个方面： + +日志框架众多，不同的类库可能会使用不同的日志框架，如何兼容是一个问题。 + +配置复杂且容易出错。日志配置文件通常很复杂，因此有些开发同学会从其他项目或者网络上复制一份配置文件，但却不知道如何修改，甚至是胡乱修改，造成很多问题。比如，重复记录日志的问题、同步日志的性能问题、异步记录的错误配置问题。 + +日志记录本身就有些误区，比如没考虑到日志内容获取的代价、胡乱使用日志级别等。 + +Logback、Log4j、Log4j2、commons-logging、JDK 自带的 java.util.logging 等，都是 Java 体系的日志框架，确实非常多。而不同的类库，还可能选择使用不同的日志框架。这样一来，日志的统一管理就变得非常困难。为了解决这个问题，就有了 SLF4J（Simple Logging Facade For Java），如下图所示： + + + +SLF4J 实现了三种功能： + +一是提供了统一的日志门面 API，即图中紫色部分，实现了中立的日志记录 API。 + +二是桥接功能，即图中蓝色部分，用来把各种日志框架的 API（图中绿色部分）桥接到 SLF4J API。这样一来，即便你的程序中使用了各种日志 API 记录日志，最终都可以桥接到 SLF4J 门面 API。 + +三是适配功能，即图中红色部分，可以实现 SLF4J API 和实际日志框架（图中灰色部分）的绑定。SLF4J 只是日志标准，我们还是需要一个实际的日志框架。日志框架本身没有实现 SLF4J API，所以需要有一个前置转换。Logback 就是按照 SLF4J API 标准实现的，因此不需要绑定模块做转换。 + +需要理清楚的是，虽然我们可以使用 log4j-over-slf4j 来实现 Log4j 桥接到 SLF4J，也可以使用 slf4j-log4j12 实现 SLF4J 适配到 Log4j，也把它们画到了一列，但是它不能同时使用它们，否则就会产生死循环。jcl 和 jul 也是同样的道理。 + +虽然图中有 4 个灰色的日志实现框架，但我看到的业务系统使用最广泛的是 Logback 和 Log4j，它们是同一人开发的。Logback 可以认为是 Log4j 的改进版本，我更推荐使用。所以，关于日志框架配置的案例，我都会围绕 Logback 展开。 + +Spring Boot 是目前最流行的 Java 框架，它的日志框架也用的是 Logback。那，为什么我们没有手动引入 Logback 的包，就可以直接使用 Logback 了呢？ + +查看 Spring Boot 的 Maven 依赖树，可以发现 spring-boot-starter 模块依赖了 spring-boot-starter-logging 模块，而 spring-boot-starter-logging 模块又帮我们自动引入了 logback-classic（包含了 SLF4J 和 Logback 日志框架）和 SLF4J 的一些适配器。其中，log4j-to-slf4j 用于实现 Log4j2 API 到 SLF4J 的桥接，jul-to-slf4j 则是实现 java.util.logging API 到 SLF4J 的桥接： + + + +接下来，我就用几个实际的案例和你说说日志配置和记录这两大问题，顺便以 Logback 为例复习一下常见的日志配置。 + +为什么我的日志会重复记录？ + +日志重复记录在业务上非常常见，不但给查看日志和统计工作带来不必要的麻烦，还会增加磁盘和日志收集系统的负担。接下来，我和你分享两个重复记录的案例，同时帮助你梳理 Logback 配置的基本结构。 + +第一个案例是，logger 配置继承关系导致日志重复记录。首先，定义一个方法实现 debug、info、warn 和 error 四种日志的记录： + +@Log4j2 +@RequestMapping("logging") +@RestController +public class LoggingController { + + @GetMapping("log") + public void log() { + log.debug("debug"); + log.info("info"); + log.warn("warn"); + log.error("error"); + } +} + + +然后，使用下面的 Logback 配置： + +第 11 和 12 行设置了全局的日志级别为 INFO，日志输出使用 CONSOLE Appender。 + +第 3 到 7 行，首先将 CONSOLE Appender 定义为 ConsoleAppender，也就是把日志输出到控制台（System.out/System.err）；然后通过 PatternLayout 定义了日志的输出格式。关于格式化字符串的各种使用方式，你可以进一步查阅官方文档。 + +第 8 到 10 行实现了一个 Logger 配置，将应用包的日志级别设置为 DEBUG、日志输出同样使用 CONSOLE Appender。 + + + + + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + + + + + + + + + + + +这段配置看起来没啥问题，但执行方法后出现了日志重复记录的问题： + + + +从配置文件的第 9 和 12 行可以看到，CONSOLE 这个 Appender 同时挂载到了两个 Logger 上，一个是我们定义的 ，一个是 ，由于我们定义的 继承自 ，所以同一条日志既会通过 logger 记录，也会发送到 root 记录，因此应用 package 下的日志出现了重复记录。 + +后来我了解到，这个同学如此配置的初衷是实现自定义的 logger 配置，让应用内的日志暂时开启 DEBUG 级别的日志记录。其实，他完全不需要重复挂载 Appender，去掉 下挂载的 Appender 即可： + + + + +如果自定义的 需要把日志输出到不同的 Appender，比如将应用的日志输出到文件 app.log、把其他框架的日志输出到控制台，可以设置 的 additivity 属性为 false，这样就不会继承 的 Appender 了： + + + + + + app.log + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + + + + + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + + + + + + + + + + + + + +第二个案例是，错误配置 LevelFilter 造成日志重复记录。 + +一般互联网公司都会使用 ELK 三件套来统一收集日志，有一次我们发现 Kibana 上展示的日志有部分重复，一直怀疑是 Logstash 配置错误，但最后发现还是 Logback 的配置错误引起的。 + +这个项目的日志是这样配置的：在记录日志到控制台的同时，把日志记录按照不同的级别记录到两个文件中： + + + + + + + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + + + + + ${logDir}/${app.name}_info.log + + INFO + + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + UTF-8 + + + + + ${logDir}/${app.name}_error.log + + WARN + + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + UTF-8 + + + + + + + + + + + + +这个配置文件比较长，我带着你一段一段地看： + +第 31 到 35 行定义的 root 引用了三个 Appender。 + +第 5 到 9 行是第一个 ConsoleAppender，用于把所有日志输出到控制台。 + +第 10 到 19 行定义了一个 FileAppender，用于记录文件日志，并定义了文件名、记录日志的格式和编码等信息。最关键的是，第 12 到 14 行定义的 LevelFilter 过滤日志，将过滤级别设置为 INFO，目的是希望 _info.log 文件中可以记录 INFO 级别的日志。 + +第 20 到 30 行定义了一个类似的 FileAppender，并使用 ThresholdFilter 来过滤日志，过滤级别设置为 WARN，目的是把 WARN 以上级别的日志记录到另一个 _error.log 文件中。 + +运行一下测试程序： + + + +可以看到，_info.log 中包含了 INFO、WARN 和 ERROR 三个级别的日志，不符合我们的预期；error.log 包含了 WARN 和 ERROR 两个级别的日志。因此，造成了日志的重复收集。 + +你可能会问，这么明显的日志重复为什么没有及时发现？一些公司使用自动化的 ELK 方案收集日志，日志会同时输出到控制台和文件，开发人员在本机测试时不太会关心文件中记录的日志，而在测试和生产环境又因为开发人员没有服务器访问权限，所以原始日志文件中的重复问题并不容易发现。 + +为了分析日志重复的原因，我们来复习一下 ThresholdFilter 和 LevelFilter 的配置方式。 + +分析 ThresholdFilter 的源码发现，当日志级别大于等于配置的级别时返回 NEUTRAL，继续调用过滤器链上的下一个过滤器；否则，返回 DENY 直接拒绝记录日志： + +public class ThresholdFilter extends Filter { + + public FilterReply decide(ILoggingEvent event) { + if (!isStarted()) { + return FilterReply.NEUTRAL; + } + + if (event.getLevel().isGreaterOrEqual(level)) { + return FilterReply.NEUTRAL; + } else { + return FilterReply.DENY; + } + } +} + + +在这个案例中，把 ThresholdFilter 设置为 WARN，可以记录 WARN 和 ERROR 级别的日志。 + +LevelFilter 用来比较日志级别，然后进行相应处理：如果匹配就调用 onMatch 定义的处理方式，默认是交给下一个过滤器处理（AbstractMatcherFilter 基类中定义的默认值）；否则，调用 onMismatch 定义的处理方式，默认也是交给下一个过滤器处理。 + +public class LevelFilter extends AbstractMatcherFilter { + + public FilterReply decide(ILoggingEvent event) { + if (!isStarted()) { + return FilterReply.NEUTRAL; + } + + if (event.getLevel().equals(level)) { + return onMatch; + } else { + return onMismatch; + } + } +} + +public abstract class AbstractMatcherFilter extends Filter { + protected FilterReply onMatch = FilterReply.NEUTRAL; + protected FilterReply onMismatch = FilterReply.NEUTRAL; +} + + +和 ThresholdFilter 不同的是，LevelFilter 仅仅配置 level 是无法真正起作用的。由于没有配置 onMatch 和 onMismatch 属性，所以相当于这个过滤器是无用的，导致 INFO 以上级别的日志都记录了。 + +定位到问题后，修改方式就很明显了：配置 LevelFilter 的 onMatch 属性为 ACCEPT，表示接收 INFO 级别的日志；配置 onMismatch 属性为 DENY，表示除了 INFO 级别都不记录： + + + ${logDir}/${app.name}_info.log + + INFO + ACCEPT + DENY + + ... + + + +这样修改后，_info.log 文件中只会有 INFO 级别的日志，不会出现日志重复的问题了。 + +使用异步日志改善性能的坑 + +掌握了把日志输出到文件中的方法后，我们接下来面临的问题是，如何避免日志记录成为应用的性能瓶颈。这可以帮助我们解决，磁盘（比如机械磁盘）IO 性能较差、日志量又很大的情况下，如何记录日志的问题。 + +我们先来测试一下，记录日志的性能问题，定义如下的日志配置，一共有两个 Appender： + +FILE 是一个 FileAppender，用于记录所有的日志； + +CONSOLE 是一个 ConsoleAppender，用于记录带有 time 标记的日志。 + + + + + + app.log + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + + + + + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + + + + time + + DENY + ACCEPT + + + + + + + + + + + +不知道你有没有注意到，这段代码中有个 EvaluatorFilter（求值过滤器），用于判断日志是否符合某个条件。 + +在后续的测试代码中，我们会把大量日志输出到文件中，日志文件会非常大，如果性能测试结果也混在其中的话，就很难找到那条日志。所以，这里我们使用 EvaluatorFilter 对日志按照标记进行过滤，并将过滤出的日志单独输出到控制台上。在这个案例中，我们给输出测试结果的那条日志上做了 time 标记。 + +配合使用标记和 EvaluatorFilter，实现日志的按标签过滤，是一个不错的小技巧。 + +如下测试代码中，实现了记录指定次数的大日志，每条日志包含 1MB 字节的模拟数据，最后记录一条以 time 为标记的方法执行耗时日志： + +@GetMapping("performance") +public void performance(@RequestParam(name = "count", defaultValue = "1000") int count) { + + long begin = System.currentTimeMillis(); + String payload = IntStream.rangeClosed(1, 1000000) + .mapToObj(__ -> "a") + .collect(Collectors.joining("")) + UUID.randomUUID().toString(); + IntStream.rangeClosed(1, count).forEach(i -> log.info("{} {}", i, payload)); + Marker timeMarker = MarkerFactory.getMarker("time"); + log.info(timeMarker, "took {} ms", System.currentTimeMillis() - begin); +} + + +执行程序后可以看到，记录 1000 次日志和 10000 次日志的调用耗时，分别是 6.3 秒和 44.5 秒： + + + +对于只记录文件日志的代码了来说，这个耗时挺长的。为了分析其中原因，我们需要分析下 FileAppender 的源码。 + +FileAppender 继承自 OutputStreamAppender，查看 OutputStreamAppender 源码的第 30 到 33 行发现，在追加日志的时候，是直接把日志写入 OutputStream 中，属于同步记录日志： + +public class OutputStreamAppender extends UnsynchronizedAppenderBase { + + private OutputStream outputStream; + boolean immediateFlush = true; + + @Override + protected void append(E eventObject) { + if (!isStarted()) { + return; + } + subAppend(eventObject); + } + + protected void subAppend(E event) { + if (!isStarted()) { + return; + } + + try { + //编码LoggingEvent + byte[] byteArray = this.encoder.encode(event); + //写字节流 + writeBytes(byteArray); + } catch (IOException ioe) { + ... + } + } + + private void writeBytes(byte[] byteArray) throws IOException { + if(byteArray == null || byteArray.length == 0) + return; + + lock.lock(); + try { + //这个OutputStream其实是一个ResilientFileOutputStream，其内部使用的是带缓冲的BufferedOutputStream + this.outputStream.write(byteArray); + if (immediateFlush) { + this.outputStream.flush();//刷入OS + } + } finally { + lock.unlock(); + } + } +} + + +分析到这里，我们就明白为什么日志大量写入时会耗时这么久了。那，有没有办法实现大量日志写入时，不会过多影响业务逻辑执行耗时，影响吞吐量呢？ + +办法当然有了，使用 Logback 提供的 AsyncAppender 即可实现异步的日志记录。AsyncAppende 类似装饰模式，也就是在不改变类原有基本功能的情况下为其增添新功能。这样，我们就可以把 AsyncAppender 附加在其他的 Appender 上，将其变为异步的。 + +定义一个异步 Appender ASYNCFILE，包装之前的同步文件日志记录的 FileAppender，就可以实现异步记录日志到文件： + + + + + + + + + + + +测试一下可以发现，记录 1000 次日志和 10000 次日志的调用耗时，分别是 735 毫秒和 668 毫秒： + + + +性能居然这么好，你觉得其中有什么问题吗？异步日志真的如此神奇和万能吗？当然不是，因为这样并没有记录下所有日志。我之前就遇到过很多关于 AsyncAppender 异步日志的坑，这些坑可以归结为三类： + +记录异步日志撑爆内存； + +记录异步日志出现日志丢失； + +记录异步日志出现阻塞。 + +为了解释这三种坑，我来模拟一个慢日志记录场景：首先，自定义一个继承自 ConsoleAppender 的 MySlowAppender，作为记录到控制台的输出器，写入日志时休眠 1 秒。 + +public class MySlowAppender extends ConsoleAppender { + + @Override + protected void subAppend(Object event) { + try { + // 模拟慢日志 + TimeUnit.MILLISECONDS.sleep(1); + } catch (InterruptedException e) { + e.printStackTrace(); + } + + super.subAppend(event); + } +} + + +然后，在配置文件中使用 AsyncAppender，将 MySlowAppender 包装为异步日志记录： + + + + + + + [%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] [%-5level] [%logger{40}:%line] - %msg%n + + + + + + + + + + + + + +定义一段测试代码，循环记录一定次数的日志，最后输出方法执行耗时： + +@GetMapping("manylog") +public void manylog(@RequestParam(name = "count", defaultValue = "1000") int count) { + + long begin = System.currentTimeMillis(); + IntStream.rangeClosed(1, count).forEach(i -> log.info("log-{}", i)); + System.out.println("took " + (System.currentTimeMillis() - begin) + " ms"); +} + + +执行方法后发现，耗时很短但出现了日志丢失：我们要记录 1000 条日志，最终控制台只能搜索到 215 条日志，而且日志的行号变为了一个问号。 + + + +出现这个问题的原因在于，AsyncAppender 提供了一些配置参数，而我们没用对。我们结合相关源码分析一下： + +includeCallerData 用于控制是否收集调用方数据，默认是 false，此时方法行号、方法名等信息将不能显示（源码第 2 行以及 7 到 11 行）。 + +queueSize 用于控制阻塞队列大小，使用的 ArrayBlockingQueue 阻塞队列（源码第 15 到 17 行），默认大小是 256，即内存中最多保存 256 条日志。 + +discardingThreshold 是控制丢弃日志的阈值，主要是防止队列满后阻塞。默认情况下，队列剩余量低于队列长度的 20%，就会丢弃 TRACE、DEBUG 和 INFO 级别的日志。（参见源码第 3 到 6 行、18 到 19 行、26 到 27 行、33 到 34 行、40 到 42 行） + +neverBlock 用于控制队列满的时候，加入的数据是否直接丢弃，不会阻塞等待，默认是 false（源码第 44 到 68 行）。这里需要注意一下 offer 方法和 put 方法的区别，当队列满的时候 offer 方法不阻塞，而 put 方法会阻塞；neverBlock 为 true 时，使用 offer 方法。 + +public class AsyncAppender extends AsyncAppenderBase { + + boolean includeCallerData = false;//是否收集调用方数据 + protected boolean isDiscardable(ILoggingEvent event) { + Level level = event.getLevel(); + return level.toInt() <= Level.INFO_INT;//丢弃<=INFO级别的日志 + } + + protected void preprocess(ILoggingEvent eventObject) { + eventObject.prepareForDeferredProcessing(); + if (includeCallerData) + eventObject.getCallerData(); + } +} + +public class AsyncAppenderBase extends UnsynchronizedAppenderBase implements AppenderAttachable { + BlockingQueue blockingQueue;//异步日志的关键，阻塞队列 + public static final int DEFAULT_QUEUE_SIZE = 256;//默认队列大小 + int queueSize = DEFAULT_QUEUE_SIZE; + static final int UNDEFINED = -1; + int discardingThreshold = UNDEFINED; + boolean neverBlock = false;//控制队列满的时候加入数据时是否直接丢弃，不会阻塞等待 + + @Override + public void start() { + ... + blockingQueue = new ArrayBlockingQueue(queueSize); + if (discardingThreshold == UNDEFINED) + discardingThreshold = queueSize / 5;//默认丢弃阈值是队列剩余量低于队列长度的20%，参见isQueueBelowDiscardingThreshold方法 + ... + } + + @Override + protected void append(E eventObject) { + if (isQueueBelowDiscardingThreshold() && isDiscardable(eventObject)) { //判断是否可以丢数据 + return; + } + preprocess(eventObject); + put(eventObject); + } + + private boolean isQueueBelowDiscardingThreshold() { + return (blockingQueue.remainingCapacity() < discardingThreshold); + } + + private void put(E eventObject) { + if (neverBlock) { //根据neverBlock决定使用不阻塞的offer还是阻塞的put方法 + blockingQueue.offer(eventObject); + } else { + putUninterruptibly(eventObject); + } + } + + //以阻塞方式添加数据到队列 + private void putUninterruptibly(E eventObject) { + boolean interrupted = false; + try { + while (true) { + try { + blockingQueue.put(eventObject); + break; + } catch (InterruptedException e) { + interrupted = true; + } + } + } finally { + if (interrupted) { + Thread.currentThread().interrupt(); + } + } + } +} + + +看到默认队列大小为 256，达到 80% 容量后开始丢弃 <=INFO 级别的日志后，我们就可以理解日志中为什么只有 215 条 INFO 日志了。 + +我们可以继续分析下异步记录日志出现坑的原因。 + +queueSize 设置得特别大，就可能会导致 OOM。 + +queueSize 设置得比较小（默认值就非常小），且 discardingThreshold 设置为大于 0 的值（或者为默认值），队列剩余容量少于 discardingThreshold 的配置就会丢弃 <=INFO 的日志。这里的坑点有两个。一是，因为 discardingThreshold 的存在，设置 queueSize 时容易踩坑。比如，本例中最大日志并发是 1000，即便设置 queueSize 为 1000 同样会导致日志丢失。二是，discardingThreshold 参数容易有歧义，它不是百分比，而是日志条数。对于总容量 10000 的队列，如果希望队列剩余容量少于 1000 条的时候丢弃，需要配置为 1000。 + +neverBlock 默认为 false，意味着总可能会出现阻塞。如果 discardingThreshold 为 0，那么队列满时再有日志写入就会阻塞；如果 discardingThreshold 不为 0，也只会丢弃 <=INFO 级别的日志，那么出现大量错误日志时，还是会阻塞程序。 + +可以看出 queueSize、discardingThreshold 和 neverBlock 这三个参数息息相关，务必按需进行设置和取舍，到底是性能为先，还是数据不丢为先： + +如果考虑绝对性能为先，那就设置 neverBlock 为 true，永不阻塞。 + +如果考虑绝对不丢数据为先，那就设置 discardingThreshold 为 0，即使是 <=INFO 的级别日志也不会丢，但最好把 queueSize 设置大一点，毕竟默认的 queueSize 显然太小，太容易阻塞。 + +如果希望兼顾两者，可以丢弃不重要的日志，把 queueSize 设置大一点，再设置一个合理的 discardingThreshold。 + +以上就是日志配置最常见的两个误区了。接下来，我们再看一个日志记录本身的误区。 + +使用日志占位符就不需要进行日志级别判断了？ + +不知道你有没有听人说过：SLF4J 的{}占位符语法，到真正记录日志时才会获取实际参数，因此解决了日志数据获取的性能问题。你觉得，这种说法对吗？ + +为了验证这个问题，我们写一段测试代码：有一个 slowString 方法，返回结果耗时 1 秒： + +private String slowString(String s) { + System.out.println("slowString called via " + s); + try { + TimeUnit.SECONDS.sleep(1); + } catch (InterruptedException e) { + } + return "OK"; +} + + +如果我们记录 DEBUG 日志，并设置只记录 >=INFO 级别的日志，程序是否也会耗时 1 秒呢？我们使用三种方法来测试： + +拼接字符串方式记录 slowString； + +使用占位符方式记录 slowString； + +先判断日志级别是否启用 DEBUG。 + +StopWatch stopWatch = new StopWatch(); +stopWatch.start("debug1"); +log.debug("debug1:" + slowString("debug1")); +stopWatch.stop(); + +stopWatch.start("debug2"); +log.debug("debug2:{}", slowString("debug2")); +stopWatch.stop(); + +stopWatch.start("debug3"); +if (log.isDebugEnabled()) + log.debug("debug3:{}", slowString("debug3")); +stopWatch.stop(); + + +可以看到，前两种方式都调用了 slowString 方法，所以耗时都是 1 秒： + + + +使用占位符方式记录 slowString 的方式，同样需要耗时 1 秒，是因为这种方式虽然允许我们传入 Object，不用拼接字符串，但也只是延迟（如果日志不记录那么就是省去）了日志参数对象.toString() 和字符串拼接的耗时。 + +在这个案例中，除非事先判断日志级别，否则必然会调用 slowString 方法。回到之前提的问题，使用{}占位符语法不能通过延迟参数值获取，来解决日志数据获取的性能问题。 + +除了事先判断日志级别，我们还可以通过 lambda 表达式进行延迟参数内容获取。但，SLF4J 的 API 还不支持 lambda，因此需要使用 Log4j2 日志 API，把 Lombok 的 @Slf4j 注解替换为 @Log4j2 注解，这样就可以提供一个 lambda 表达式作为提供参数数据的方法： + +@Log4j2 +public class LoggingController { +... +log.debug("debug4:{}", ()->slowString("debug4")); + + +像这样调用 debug 方法，签名是 Supplier，参数会延迟到真正需要记录日志时再获取： + +void debug(String message, Supplier... paramSuppliers); + +public void logIfEnabled(final String fqcn, final Level level, final Marker marker, final String message, + final Supplier... paramSuppliers) { + if (isEnabled(level, marker, message)) { + logMessage(fqcn, level, marker, message, paramSuppliers); + } +} + +protected void logMessage(final String fqcn, final Level level, final Marker marker, final String message, + final Supplier... paramSuppliers) { + final Message msg = messageFactory.newMessage(message, LambdaUtil.getAll(paramSuppliers)); + logMessageSafely(fqcn, level, marker, msg, msg.getThrowable()); +} + + +修改后再次运行测试，可以看到这次 debug4 并不会调用 slowString 方法： + + + +其实，我们只是换成了 Log4j2 API，真正的日志记录还是走的 Logback 框架。没错，这就是 SLF4J 适配的一个好处。 + +重点回顾 + +我将记录日志的坑，总结为框架使用配置和记录本身两个方面。 + +Java 的日志框架众多，SLF4J 实现了这些框架记录日志的统一。在使用 SLF4J 时，我们需要理清楚其桥接 API 和绑定这两个模块。如果程序启动时出现 SLF4J 的错误提示，那很可能是配置出现了问题，可以使用 Maven 的 dependency:tree 命令梳理依赖关系。 + +Logback 是 Java 最常用的日志框架，其配置比较复杂，你可以参考官方文档中关于 Appender、Layout、Filter 的配置，切记不要随意从其他地方复制别人的配置，避免出现错误或与当前需求不符。 + +使用异步日志解决性能问题，是用空间换时间。但空间毕竟有限，当空间满了之后，我们要考虑是阻塞等待，还是丢弃日志。如果更希望不丢弃重要日志，那么选择阻塞等待；如果更希望程序不要因为日志记录而阻塞，那么就需要丢弃日志。 + +最后，我强调的是，日志框架提供的参数化日志记录方式不能完全取代日志级别的判断。如果你的日志量很大，获取日志参数代价也很大，就要进行相应日志级别的判断，避免不记录日志也要花费时间获取日志参数的问题。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在第一小节的案例中，我们把 INFO 级别的日志存放到 _info.log 中，把 WARN 和 ERROR 级别的日志存放到 _error.log 中。如果现在要把 INFO 和 WARN 级别的日志存放到 _info.log 中，把 ERROR 日志存放到 _error.log 中，应该如何配置 Logback 呢？ + +生产级项目的文件日志肯定需要按时间和日期进行分割和归档处理，以避免单个文件太大，同时保留一定天数的历史日志，你知道如何配置吗？可以在官方文档找到答案。 + +针对日志记录和配置，你还遇到过其他坑吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/14文件IO：实现高效正确的文件读写并非易事.md b/专栏/Java业务开发常见错误100例/14文件IO：实现高效正确的文件读写并非易事.md new file mode 100644 index 0000000..b0505d5 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/14文件IO：实现高效正确的文件读写并非易事.md @@ -0,0 +1,425 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 14 文件IO：实现高效正确的文件读写并非易事 + 今天，我们来聊聊如何实现高效、正确的文件操作。 + +随着数据库系统的成熟和普及，需要直接做文件 IO 操作的需求越来越少，这就导致我们对相关 API 不够熟悉，以至于遇到类似文件导出、三方文件对账等需求时，只能临时抱佛脚，随意搜索一些代码完成需求，出现性能问题或者 Bug 后不知从何处入手。 + +今天这篇文章，我就会从字符编码、缓冲区和文件句柄释放这 3 个常见问题出发，和你分享如何解决与文件操作相关的性能问题或者 Bug。如果你对文件操作相关的 API 不够熟悉，可以查看Oracle 官网的介绍。 + +文件读写需要确保字符编码一致 + +有一个项目需要读取三方的对账文件定时对账，原先一直是单机处理的，没什么问题。后来为了提升性能，使用双节点同时处理对账，每一个节点处理部分对账数据，但新增的节点在处理文件中中文的时候总是读取到乱码。 + +程序代码都是一致的，为什么老节点就不会有问题呢？我们知道，这很可能是写代码时没有注意编码问题导致的。接下来，我们就分析下这个问题吧。 + +为模拟这个场景，我们使用 GBK 编码把“你好 hi”写入一个名为 hello.txt 的文本文件，然后直接以字节数组形式读取文件内容，转换为十六进制字符串输出到日志中： + +Files.deleteIfExists(Paths.get("hello.txt")); +Files.write(Paths.get("hello.txt"), "你好hi".getBytes(Charset.forName("GBK"))); +log.info("bytes:{}", Hex.encodeHexString(Files.readAllBytes(Paths.get("hello.txt"))).toUpperCase()); + + +输出如下： + +13:06:28.955 [main] INFO org.geekbang.time.commonmistakes.io.demo3.FileBadEncodingIssueApplication - bytes:C4E3BAC36869 + + +虽然我们打开文本文件时看到的是“你好 hi”，但不管是什么文字，计算机中都是按照一定的规则将其以二进制保存的。这个规则就是字符集，字符集枚举了所有支持的字符映射成二进制的映射表。在处理文件读写的时候，如果是在字节层面进行操作，那么不会涉及字符编码问题；而如果需要在字符层面进行读写的话，就需要明确字符的编码方式也就是字符集了。 + +当时出现问题的文件读取代码是这样的： + +char[] chars = new char[10]; +String content = ""; +try (FileReader fileReader = new FileReader("hello.txt")) { + int count; + while ((count = fileReader.read(chars)) != -1) { + content += new String(chars, 0, count); + } +} +log.info("result:{}", content); + + +可以看到，是使用了 FileReader 类以字符方式进行文件读取，日志中读取出来的“你好”变为了乱码： + +13:06:28.961 [main] INFO org.geekbang.time.commonmistakes.io.demo3.FileBadEncodingIssueApplication - result:���hi + + +显然，这里并没有指定以什么字符集来读取文件中的字符。查看JDK 文档可以发现，FileReader 是以当前机器的默认字符集来读取文件的，如果希望指定字符集的话，需要直接使用 InputStreamReader 和 FileInputStream。 + +到这里我们就明白了，FileReader 虽然方便但因为使用了默认字符集对环境产生了依赖，这就是为什么老的机器上程序可以正常运作，在新节点上读取中文时却产生了乱码。 + +那，怎么确定当前机器的默认字符集呢？写一段代码输出当前机器的默认字符集，以及 UTF-8 方式编码的“你好 hi”的十六进制字符串： + +log.info("charset: {}", Charset.defaultCharset()); +Files.write(Paths.get("hello2.txt"), "你好hi".getBytes(Charsets.UTF_8)); +log.info("bytes:{}", Hex.encodeHexString(Files.readAllBytes(Paths.get("hello2.txt"))).toUpperCase()); + + +输出结果如下： + +13:06:28.961 [main] INFO org.geekbang.time.commonmistakes.io.demo3.FileBadEncodingIssueApplication - charset: UTF-8 +13:06:28.962 [main] INFO org.geekbang.time.commonmistakes.io.demo3.FileBadEncodingIssueApplication - bytes:E4BDA0E5A5BD6869 + + +可以看到，当前机器默认字符集是 UTF-8，当然无法读取 GBK 编码的汉字。UTF-8 编码的“你好”的十六进制是 E4BDA0E5A5BD，每一个汉字需要三个字节；而 GBK 编码的汉字，每一个汉字两个字节。字节长度都不一样，以 GBK 编码后保存的汉字，以 UTF8 进行解码读取，必然不会成功。 + +定位到问题后，修复就很简单了。按照文档所说，直接使用 FileInputStream 拿文件流，然后使用 InputStreamReader 读取字符流，并指定字符集为 GBK： + +private static void right1() throws IOException { + + char[] chars = new char[10]; + String content = ""; + + try (FileInputStream fileInputStream = new FileInputStream("hello.txt"); + InputStreamReader inputStreamReader = new InputStreamReader(fileInputStream, Charset.forName("GBK"))) { + int count; + while ((count = inputStreamReader.read(chars)) != -1) { + content += new String(chars, 0, count); + } + } + + log.info("result: {}", content); +} + + +从日志中看到，修复后的代码正确读取到了“你好 Hi”。 + +13:06:28.963 [main] INFO org.geekbang.time.commonmistakes.io.demo3.FileBadEncodingIssueApplication - result: 你好hi + + +如果你觉得这种方式比较麻烦的话，使用 JDK1.7 推出的 Files 类的 readAllLines 方法，可以很方便地用一行代码完成文件内容读取： + +log.info("result: {}", Files.readAllLines(Paths.get("hello.txt"), Charset.forName("GBK")).stream().findFirst().orElse("")); + + +但这种方式有个问题是，读取超出内存大小的大文件时会出现 OOM。为什么呢？ + +打开 readAllLines 方法的源码可以看到，readAllLines 读取文件所有内容后，放到一个 List 中返回，如果内存无法容纳这个 List，就会 OOM： + +public static List readAllLines(Path path, Charset cs) throws IOException { + + try (BufferedReader reader = newBufferedReader(path, cs)) { + List result = new ArrayList<>(); + for (;;) { + String line = reader.readLine(); + if (line == null) + break; + result.add(line); + } + return result; + } +} + + +那么，有没有办法实现按需的流式读取呢？比如，需要消费某行数据时再读取，而不是把整个文件一次性读取到内存？ + +当然有，解决方案就是 File 类的 lines 方法。接下来，我就与你说说使用 lines 方法时需要注意的一些问题。 + +使用 Files 类静态方法进行文件操作注意释放文件句柄 + +与 readAllLines 方法返回 List 不同，lines 方法返回的是 Stream。这，使得我们在需要时可以不断读取、使用文件中的内容，而不是一次性地把所有内容都读取到内存中，因此避免了 OOM。 + +接下来，我通过一段代码测试一下。我们尝试读取一个 1 亿 1 万行的文件，文件占用磁盘空间超过 4GB。如果使用 -Xmx512m -Xms512m 启动 JVM 控制最大堆内存为 512M 的话，肯定无法一次性读取这样的大文件，但通过 Files.lines 方法就没问题。 + +在下面的代码中，首先输出这个文件的大小，然后计算读取 20 万行数据和 200 万行数据的耗时差异，最后逐行读取文件，统计文件的总行数： + +//输出文件大小 +log.info("file size:{}", Files.size(Paths.get("test.txt"))); +StopWatch stopWatch = new StopWatch(); +stopWatch.start("read 200000 lines"); + +//使用Files.lines方法读取20万行数据 +log.info("lines {}", Files.lines(Paths.get("test.txt")).limit(200000).collect(Collectors.toList()).size()); +stopWatch.stop(); +stopWatch.start("read 2000000 lines"); + +//使用Files.lines方法读取200万行数据 +log.info("lines {}", Files.lines(Paths.get("test.txt")).limit(2000000).collect(Collectors.toList()).size()); +stopWatch.stop(); +log.info(stopWatch.prettyPrint()); +AtomicLong atomicLong = new AtomicLong(); + +//使用Files.lines方法统计文件总行数 +Files.lines(Paths.get("test.txt")).forEach(line->atomicLong.incrementAndGet()); +log.info("total lines {}", atomicLong.get()); + + +输出结果如下： + + + +可以看到，实现了全文件的读取、统计了整个文件的行数，并没有出现 OOM；读取 200 万行数据耗时 760ms，读取 20 万行数据仅需 267ms。这些都可以说明，File.lines 方法并不是一次性读取整个文件的，而是按需读取。 + +到这里，你觉得这段代码有什么问题吗？ + +问题在于读取完文件后没有关闭。我们通常会认为静态方法的调用不涉及资源释放，因为方法调用结束自然代表资源使用完成，由 API 释放资源，但对于 Files 类的一些返回 Stream 的方法并不是这样。这，是一个很容易被忽略的严重问题。 + +我就曾遇到过一个案例：程序在生产上运行一段时间后就会出现 too many files 的错误，我们想当然地认为是 OS 设置的最大文件句柄太小了，就让运维放开这个限制，但放开后还是会出现这样的问题。经排查发现，其实是文件句柄没有释放导致的，问题就出在 Files.lines 方法上。 + +我们来重现一下这个问题，随便写入 10 行数据到一个 demo.txt 文件中： + +Files.write(Paths.get("demo.txt"), +IntStream.rangeClosed(1, 10).mapToObj(i -> UUID.randomUUID().toString()).collect(Collectors.toList()) +, UTF_8, CREATE, TRUNCATE_EXISTING); + + +然后使用 Files.lines 方法读取这个文件 100 万次，每读取一行计数器 +1： + +LongAdder longAdder = new LongAdder(); +IntStream.rangeClosed(1, 1000000).forEach(i -> { + try { + Files.lines(Paths.get("demo.txt")).forEach(line -> longAdder.increment()); + } catch (IOException e) { + e.printStackTrace(); + } +}); + +log.info("total : {}", longAdder.longValue()); + + +运行后马上可以在日志中看到如下错误： + +java.nio.file.FileSystemException: demo.txt: Too many open files +at sun.nio.fs.UnixException.translateToIOException(UnixException.java:91) +at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) +at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) + + +使用 lsof 命令查看进程打开的文件，可以看到打开了 1 万多个 demo.txt： + +lsof -p 63937 +... +java 63902 zhuye *238r REG 1,4 370 12934160647 /Users/zhuye/Documents/common-mistakes/demo.txt +java 63902 zhuye *239r REG 1,4 370 12934160647 /Users/zhuye/Documents/common-mistakes/demo.txt +... +lsof -p 63937 | grep demo.txt | wc -l + 10007 + + +其实，在JDK 文档中有提到，注意使用 try-with-resources 方式来配合，确保流的 close 方法可以调用释放资源。 + +这也很容易理解，使用流式处理，如果不显式地告诉程序什么时候用完了流，程序又如何知道呢，它也不能帮我们做主何时关闭文件。 + +修复方式很简单，使用 try 来包裹 Stream 即可： + +LongAdder longAdder = new LongAdder(); +IntStream.rangeClosed(1, 1000000).forEach(i -> { + try (Stream lines = Files.lines(Paths.get("demo.txt"))) { + lines.forEach(line -> longAdder.increment()); + } catch (IOException e) { + e.printStackTrace(); + } +}); + +log.info("total : {}", longAdder.longValue()); + + +修改后的代码不再出现错误日志，因为读取了 100 万次包含 10 行数据的文件，所以最终正确输出了 1000 万： + +14:19:29.410 [main] INFO org.geekbang.time.commonmistakes.io.demo2.FilesStreamOperationNeedCloseApplication - total : 10000000 + + +查看 lines 方法源码可以发现，Stream 的 close 注册了一个回调，来关闭 BufferedReader 进行资源释放： + +public static Stream lines(Path path, Charset cs) throws IOException { + + BufferedReader br = Files.newBufferedReader(path, cs); + try { + return br.lines().onClose(asUncheckedRunnable(br)); + } catch (Error|RuntimeException e) { + try { + br.close(); + } catch (IOException ex) { + try { + e.addSuppressed(ex); + } catch (Throwable ignore) {} + } + throw e; + } +} + +private static Runnable asUncheckedRunnable(Closeable c) { + return () -> { + try { + c.close(); + } catch (IOException e) { + throw new UncheckedIOException(e); + } + }; +} + + +从命名上可以看出，使用 BufferedReader 进行字符流读取时，用到了缓冲。这里缓冲 Buffer 的意思是，使用一块内存区域作为直接操作的中转。 + +比如，读取文件操作就是一次性读取一大块数据（比如 8KB）到缓冲区，后续的读取可以直接从缓冲区返回数据，而不是每次都直接对应文件 IO。写操作也是类似。如果每次写几十字节到文件都对应一次 IO 操作，那么写一个几百兆的大文件可能就需要千万次的 IO 操作，耗时会非常久。 + +接下来，我就通过几个实验，和你说明使用缓冲 Buffer 的重要性，并对比下不同使用方式的文件读写性能，来帮助你用对、用好 Buffer。 + +注意读写文件要考虑设置缓冲区 + +我曾遇到过这么一个案例，一段先进行文件读入再简单处理后写入另一个文件的业务代码，由于开发人员使用了单字节的读取写入方式，导致执行得巨慢，业务量上来后需要数小时才能完成。 + +我们来模拟一下相关实现。创建一个文件随机写入 100 万行数据，文件大小在 35MB 左右： + +Files.write(Paths.get("src.txt"), +IntStream.rangeClosed(1, 1000000).mapToObj(i -> UUID.randomUUID().toString()).collect(Collectors.toList()) +, UTF_8, CREATE, TRUNCATE_EXISTING); + + +当时开发人员写的文件处理代码大概是这样的：使用 FileInputStream 获得一个文件输入流，然后调用其 read 方法每次读取一个字节，最后通过一个 FileOutputStream 文件输出流把处理后的结果写入另一个文件。 + +为了简化逻辑便于理解，这里我们不对数据进行处理，直接把原文件数据写入目标文件，相当于文件复制： + +private static void perByteOperation() throws IOException { + + try (FileInputStream fileInputStream = new FileInputStream("src.txt"); + FileOutputStream fileOutputStream = new FileOutputStream("dest.txt")) { + int i; + while ((i = fileInputStream.read()) != -1) { + fileOutputStream.write(i); + } + } +} + + +这样的实现，复制一个 35MB 的文件居然耗时 190 秒。 + +显然，每读取一个字节、每写入一个字节都进行一次 IO 操作，代价太大了。解决方案就是，考虑使用缓冲区作为过渡，一次性从原文件读取一定数量的数据到缓冲区，一次性写入一定数量的数据到目标文件。 + +改良后，使用 100 字节作为缓冲区，使用 FileInputStream 的 byte[]的重载来一次性读取一定字节的数据，同时使用 FileOutputStream 的 byte[]的重载实现一次性从缓冲区写入一定字节的数据到文件： + +private static void bufferOperationWith100Buffer() throws IOException { + + try (FileInputStream fileInputStream = new FileInputStream("src.txt"); + FileOutputStream fileOutputStream = new FileOutputStream("dest.txt")) { + byte[] buffer = new byte[100]; + int len = 0; + while ((len = fileInputStream.read(buffer)) != -1) { + fileOutputStream.write(buffer, 0, len); + } + } +} + + +仅仅使用了 100 个字节的缓冲区作为过渡，完成 35M 文件的复制耗时缩短到了 26 秒，是无缓冲时性能的 7 倍；如果把缓冲区放大到 1000 字节，耗时可以进一步缩短到 342 毫秒。可以看到，在进行文件 IO 处理的时候，使用合适的缓冲区可以明显提高性能。 + +你可能会说，实现文件读写还要自己 new 一个缓冲区出来，太麻烦了，不是有一个 BufferedInputStream 和 BufferedOutputStream 可以实现输入输出流的缓冲处理吗？ + +是的，它们在内部实现了一个默认 8KB 大小的缓冲区。但是，在使用 BufferedInputStream 和 BufferedOutputStream 时，我还是建议你再使用一个缓冲进行读写，不要因为它们实现了内部缓冲就进行逐字节的操作。 + +接下来，我写一段代码比较下使用下面三种方式读写一个字节的性能： + +直接使用 BufferedInputStream 和 BufferedOutputStream； + +额外使用一个 8KB 缓冲，使用 BufferedInputStream 和 BufferedOutputStream； + +直接使用 FileInputStream 和 FileOutputStream，再使用一个 8KB 的缓冲。 + +//使用BufferedInputStream和BufferedOutputStream +private static void bufferedStreamByteOperation() throws IOException { + try (BufferedInputStream bufferedInputStream = new BufferedInputStream(new FileInputStream("src.txt")); + BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(new FileOutputStream("dest.txt"))) { + int i; + while ((i = bufferedInputStream.read()) != -1) { + bufferedOutputStream.write(i); + } + } +} + +//额外使用一个8KB缓冲，再使用BufferedInputStream和BufferedOutputStream +private static void bufferedStreamBufferOperation() throws IOException { + + try (BufferedInputStream bufferedInputStream = new BufferedInputStream(new FileInputStream("src.txt")); + BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(new FileOutputStream("dest.txt"))) { + byte[] buffer = new byte[8192]; + int len = 0; + while ((len = bufferedInputStream.read(buffer)) != -1) { + bufferedOutputStream.write(buffer, 0, len); + } + } +} + +//直接使用FileInputStream和FileOutputStream，再使用一个8KB的缓冲 +private static void largerBufferOperation() throws IOException { + try (FileInputStream fileInputStream = new FileInputStream("src.txt"); + FileOutputStream fileOutputStream = new FileOutputStream("dest.txt")) { + byte[] buffer = new byte[8192]; + int len = 0; + while ((len = fileInputStream.read(buffer)) != -1) { + fileOutputStream.write(buffer, 0, len); + } + } +} + + +结果如下： + +--------------------------------------------- +ns % Task name +--------------------------------------------- +1424649223 086% bufferedStreamByteOperation +117807808 007% bufferedStreamBufferOperation +112153174 007% largerBufferOperation + + +可以看到，第一种方式虽然使用了缓冲流，但逐字节的操作因为方法调用次数实在太多还是慢，耗时 1.4 秒；后面两种方式的性能差不多，耗时 110 毫秒左右。虽然第三种方式没有使用缓冲流，但使用了 8KB 大小的缓冲区，和缓冲流默认的缓冲区大小相同。 + +看到这里，你可能会疑惑了，既然这样使用 BufferedInputStream 和 BufferedOutputStream 有什么意义呢？ + +其实，这里我是为了演示所以示例三使用了固定大小的缓冲区，但在实际代码中每次需要读取的字节数很可能不是固定的，有的时候读取几个字节，有的时候读取几百字节，这个时候有一个固定大小较大的缓冲，也就是使用 BufferedInputStream 和 BufferedOutputStream 做为后备的稳定的二次缓冲，就非常有意义了。 + +最后我要补充说明的是，对于类似的文件复制操作，如果希望有更高性能，可以使用 FileChannel 的 transfreTo 方法进行流的复制。在一些操作系统（比如高版本的 Linux 和 UNIX）上可以实现 DMA（直接内存访问），也就是数据从磁盘经过总线直接发送到目标文件，无需经过内存和 CPU 进行数据中转： + +private static void fileChannelOperation() throws IOException { + FileChannel in = FileChannel.open(Paths.get("src.txt"), StandardOpenOption.READ); + FileChannel out = FileChannel.open(Paths.get("dest.txt"), CREATE, WRITE); + in.transferTo(0, in.size(), out); +} + + +你可以通过这篇文章，了解 transferTo 方法的更多细节。 + +在测试 FileChannel 性能的同时，我再运行一下这一小节中的所有实现，比较一下读写 35MB 文件的耗时。 + +--------------------------------------------- +ns % Task name +--------------------------------------------- +183673362265 098% perByteOperation +2034504694 001% bufferOperationWith100Buffer +749967898 000% bufferedStreamByteOperation +110602155 000% bufferedStreamBufferOperation +114542834 000% largerBufferOperation +050068602 000% fileChannelOperation + + +可以看到，最慢的是单字节读写文件流的方式，耗时 183 秒，最快的是 FileChannel.transferTo 方式进行流转发的方式，耗时 50 毫秒。两者耗时相差达到 3600 倍！ + +重点回顾 + +今天，我通过三个案例和你分享了文件读写操作中最重要的几个方面。 + +第一，如果需要读写字符流，那么需要确保文件中字符的字符集和字符流的字符集是一致的，否则可能产生乱码。 + +第二，使用 Files 类的一些流式处理操作，注意使用 try-with-resources 包装 Stream，确保底层文件资源可以释放，避免产生 too many open files 的问题。 + +第三，进行文件字节流操作的时候，一般情况下不考虑进行逐字节操作，使用缓冲区进行批量读写减少 IO 次数，性能会好很多。一般可以考虑直接使用缓冲输入输出流 BufferedXXXStream，追求极限性能的话可以考虑使用 FileChannel 进行流转发。 + +最后我要强调的是，文件操作因为涉及操作系统和文件系统的实现，JDK 并不能确保所有 IO API 在所有平台的逻辑一致性，代码迁移到新的操作系统或文件系统时，要重新进行功能测试和性能测试。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +Files.lines 方法进行流式处理，需要使用 try-with-resources 进行资源释放。那么，使用 Files 类中其他返回 Stream 包装对象的方法进行流式处理，比如 newDirectoryStream 方法返回 DirectoryStream，list、walk 和 find 方法返回 Stream，也同样有资源释放问题吗？ + +Java 的 File 类和 Files 类提供的文件复制、重命名、删除等操作，是原子性的吗？ + +对于文件操作，你还遇到过什么坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/15序列化：一来一回你还是原来的你吗？.md b/专栏/Java业务开发常见错误100例/15序列化：一来一回你还是原来的你吗？.md new file mode 100644 index 0000000..6ced533 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/15序列化：一来一回你还是原来的你吗？.md @@ -0,0 +1,749 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 15 序列化：一来一回你还是原来的你吗？ + 今天，我来和你聊聊序列化相关的坑和最佳实践。 + +序列化是把对象转换为字节流的过程，以方便传输或存储。反序列化，则是反过来把字节流转换为对象的过程。在介绍文件 IO的时候，我提到字符编码是把字符转换为二进制的过程，至于怎么转换需要由字符集制定规则。同样地，对象的序列化和反序列化，也需要由序列化算法制定规则。 + +关于序列化算法，几年前常用的有 JDK（Java）序列化、XML 序列化等，但前者不能跨语言，后者性能较差（时间空间开销大）；现在 RESTful 应用最常用的是 JSON 序列化，追求性能的 RPC 框架（比如 gRPC）使用 protobuf 序列化，这 2 种方法都是跨语言的，而且性能不错，应用广泛。 + +在架构设计阶段，我们可能会重点关注算法选型，在性能、易用性和跨平台性等中权衡，不过这里的坑比较少。通常情况下，序列化问题常见的坑会集中在业务场景中，比如 Redis、参数和响应序列化反序列化。 + +今天，我们就一起聊聊开发中序列化常见的一些坑吧。 + +序列化和反序列化需要确保算法一致 + +业务代码中涉及序列化时，很重要的一点是要确保序列化和反序列化的算法一致性。有一次我要排查缓存命中率问题，需要运维同学帮忙拉取 Redis 中的 Key，结果他反馈 Redis 中存的都是乱码，怀疑 Redis 被攻击了。其实呢，这个问题就是序列化算法导致的，我们来看下吧。 + +在这个案例中，开发同学使用 RedisTemplate 来操作 Redis 进行数据缓存。因为相比于 Jedis，使用 Spring 提供的 RedisTemplate 操作 Redis，除了无需考虑连接池、更方便外，还可以与 Spring Cache 等其他组件无缝整合。如果使用 Spring Boot 的话，无需任何配置就可以直接使用。 + +数据（包含 Key 和 Value）要保存到 Redis，需要经过序列化算法来序列化成字符串。虽然 Redis 支持多种数据结构，比如 Hash，但其每一个 field 的 Value 还是字符串。如果 Value 本身也是字符串的话，能否有便捷的方式来使用 RedisTemplate，而无需考虑序列化呢？ + +其实是有的，那就是 StringRedisTemplate。 + +那 StringRedisTemplate 和 RedisTemplate 的区别是什么呢？开头提到的乱码又是怎么回事呢？带着这些问题让我们来研究一下吧。 + +写一段测试代码，在应用初始化完成后向 Redis 设置两组数据，第一次使用 RedisTemplate 设置 Key 为 redisTemplate、Value 为 User 对象，第二次使用 StringRedisTemplate 设置 Key 为 stringRedisTemplate、Value 为 JSON 序列化后的 User 对象： + +@Autowired +private RedisTemplate redisTemplate; + +@Autowired +private StringRedisTemplate stringRedisTemplate; + +@Autowired +private ObjectMapper objectMapper; + +@PostConstruct +public void init() throws JsonProcessingException { + redisTemplate.opsForValue().set("redisTemplate", new User("zhuye", 36)); + stringRedisTemplate.opsForValue().set("stringRedisTemplate", objectMapper.writeValueAsString(new User("zhuye", 36))); +} + + +如果你认为，StringRedisTemplate 和 RedisTemplate 的区别，无非是读取的 Value 是 String 和 Object，那就大错特错了，因为使用这两种方式存取的数据完全无法通用。 + +我们做个小实验，通过 RedisTemplate 读取 Key 为 stringRedisTemplate 的 Value，使用 StringRedisTemplate 读取 Key 为 redisTemplate 的 Value： + +log.info("redisTemplate get {}", redisTemplate.opsForValue().get("stringRedisTemplate")); +log.info("stringRedisTemplate get {}", stringRedisTemplate.opsForValue().get("redisTemplate")); + + +结果是，两次都无法读取到 Value： + +[11:49:38.478] [http-nio-45678-exec-1] [INFO ] [.t.c.s.demo1.RedisTemplateController:38 ] - redisTemplate get null +[11:49:38.481] [http-nio-45678-exec-1] [INFO ] [.t.c.s.demo1.RedisTemplateController:39 ] - stringRedisTemplate get null + + +通过 redis-cli 客户端工具连接到 Redis，你会发现根本就没有叫作 redisTemplate 的 Key，所以 StringRedisTemplate 无法查到数据： + + + +查看 RedisTemplate 的源码发现，默认情况下 RedisTemplate 针对 Key 和 Value 使用了 JDK 序列化： + +public void afterPropertiesSet() { + ... + if (defaultSerializer == null) { + defaultSerializer = new JdkSerializationRedisSerializer( + classLoader != null ? classLoader : this.getClass().getClassLoader()); + } + + if (enableDefaultSerializer) { + if (keySerializer == null) { + keySerializer = defaultSerializer; + defaultUsed = true; + } + + if (valueSerializer == null) { + valueSerializer = defaultSerializer; + defaultUsed = true; + } + + if (hashKeySerializer == null) { + hashKeySerializer = defaultSerializer; + defaultUsed = true; + } + + if (hashValueSerializer == null) { + hashValueSerializer = defaultSerializer; + defaultUsed = true; + } + } + ... +} + + +redis-cli 看到的类似一串乱码的”\xac\xed\x00\x05t\x00\rredisTemplate”字符串，其实就是字符串 redisTemplate 经过 JDK 序列化后的结果。这就回答了之前提到的乱码问题。而 RedisTemplate 尝试读取 Key 为 stringRedisTemplate 数据时，也会对这个字符串进行 JDK 序列化处理，所以同样无法读取到数据。 + +而 StringRedisTemplate 对于 Key 和 Value，使用的是 String 序列化方式，Key 和 Value 只能是 String： + +public class StringRedisTemplate extends RedisTemplate { + + public StringRedisTemplate() { + setKeySerializer(RedisSerializer.string()); + setValueSerializer(RedisSerializer.string()); + setHashKeySerializer(RedisSerializer.string()); + setHashValueSerializer(RedisSerializer.string()); + } +} + +public class StringRedisSerializer implements RedisSerializer { + + @Override + public String deserialize(@Nullable byte[] bytes) { + return (bytes == null ? null : new String(bytes, charset)); + } + + @Override + public byte[] serialize(@Nullable String string) { + return (string == null ? null : string.getBytes(charset)); + } +} + + +看到这里，我们应该知道 RedisTemplate 和 StringRedisTemplate 保存的数据无法通用。修复方式就是，让它们读取自己存的数据： + +使用 RedisTemplate 读出的数据，由于是 Object 类型的，使用时可以先强制转换为 User 类型； + +使用 StringRedisTemplate 读取出的字符串，需要手动将 JSON 反序列化为 User 类型。 + +//使用RedisTemplate获取Value，无需反序列化就可以拿到实际对象，虽然方便，但是Redis中保存的Key和Value不易读 +User userFromRedisTemplate = (User) redisTemplate.opsForValue().get("redisTemplate"); +log.info("redisTemplate get {}", userFromRedisTemplate); + +//使用StringRedisTemplate，虽然Key正常，但是Value存取需要手动序列化成字符串 +User userFromStringRedisTemplate = objectMapper.readValue(stringRedisTemplate.opsForValue().get("stringRedisTemplate"), User.class); +log.info("stringRedisTemplate get {}", userFromStringRedisTemplate); + + +这样就可以得到正确输出： + +[13:32:09.087] [http-nio-45678-exec-6] [INFO ] [.t.c.s.demo1.RedisTemplateController:45 ] - redisTemplate get User(name=zhuye, age=36) +[13:32:09.092] [http-nio-45678-exec-6] [INFO ] [.t.c.s.demo1.RedisTemplateController:47 ] - stringRedisTemplate get User(name=zhuye, age=36) + + +看到这里你可能会说，使用 RedisTemplate 获取 Value 虽然方便，但是 Key 和 Value 不易读；而使用 StringRedisTemplate 虽然 Key 是普通字符串，但是 Value 存取需要手动序列化成字符串，有没有两全其美的方式呢？ + +当然有，自己定义 RedisTemplate 的 Key 和 Value 的序列化方式即可：Key 的序列化使用 RedisSerializer.string()（也就是 StringRedisSerializer 方式）实现字符串序列化，而 Value 的序列化使用 Jackson2JsonRedisSerializer： + +@Bean +public RedisTemplate redisTemplate(RedisConnectionFactory redisConnectionFactory) { + + RedisTemplate redisTemplate = new RedisTemplate<>(); + + redisTemplate.setConnectionFactory(redisConnectionFactory); + + Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class); + + redisTemplate.setKeySerializer(RedisSerializer.string()); + + redisTemplate.setValueSerializer(jackson2JsonRedisSerializer); + + redisTemplate.setHashKeySerializer(RedisSerializer.string()); + + redisTemplate.setHashValueSerializer(jackson2JsonRedisSerializer); + + redisTemplate.afterPropertiesSet(); + + return redisTemplate; +} + + +写代码测试一下存取，直接注入类型为 RedisTemplate 的 userRedisTemplate 字段，然后在 right2 方法中，使用注入的 userRedisTemplate 存入一个 User 对象，再分别使用 userRedisTemplate 和 StringRedisTemplate 取出这个对象： + +@Autowired +private RedisTemplate userRedisTemplate; + +@GetMapping("right2") +public void right2() { + + User user = new User("zhuye", 36); + + userRedisTemplate.opsForValue().set(user.getName(), user); + + Object userFromRedis = userRedisTemplate.opsForValue().get(user.getName()); + + log.info("userRedisTemplate get {} {}", userFromRedis, userFromRedis.getClass()); + log.info("stringRedisTemplate get {}", stringRedisTemplate.opsForValue().get(user.getName())); +} + + +乍一看没啥问题，StringRedisTemplate 成功查出了我们存入的数据： + +[14:07:41.315] [http-nio-45678-exec-1] [INFO ] [.t.c.s.demo1.RedisTemplateController:55 ] - userRedisTemplate get {name=zhuye, age=36} class java.util.LinkedHashMap +[14:07:41.318] [http-nio-45678-exec-1] [INFO ] [.t.c.s.demo1.RedisTemplateController:56 ] - stringRedisTemplate get {"name":"zhuye","age":36} + + +Redis 里也可以查到 Key 是纯字符串，Value 是 JSON 序列化后的 User 对象： + + + +但值得注意的是，这里有一个坑。第一行的日志输出显示，userRedisTemplate 获取到的 Value，是 LinkedHashMap 类型的，完全不是泛型的 RedisTemplate 设置的 User 类型。 + +如果我们把代码里从 Redis 中获取到的 Value 变量类型由 Object 改为 User，编译不会出现问题，但会出现 ClassCastException： + +java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to org.geekbang.time.commonmistakes.serialization.demo1.User + + +修复方式是，修改自定义 RestTemplate 的代码，把 new 出来的 Jackson2JsonRedisSerializer 设置一个自定义的 ObjectMapper，启用 activateDefaultTyping 方法把类型信息作为属性写入序列化后的数据中（当然了，你也可以调整 JsonTypeInfo.As 枚举以其他形式保存类型信息）： + +... +Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class); +ObjectMapper objectMapper = new ObjectMapper(); + +//把类型信息作为属性写入Value +objectMapper.activateDefaultTyping(objectMapper.getPolymorphicTypeValidator(), ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY); +jackson2JsonRedisSerializer.setObjectMapper(objectMapper); +... + + +或者，直接使用 RedisSerializer.json() 快捷方法，它内部使用的 GenericJackson2JsonRedisSerializer 直接设置了把类型作为属性保存到 Value 中： + +redisTemplate.setKeySerializer(RedisSerializer.string()); + +redisTemplate.setValueSerializer(RedisSerializer.json()); + +redisTemplate.setHashKeySerializer(RedisSerializer.string()); + +redisTemplate.setHashValueSerializer(RedisSerializer.json()); + + +重启程序调用 right2 方法进行测试，可以看到，从自定义的 RedisTemplate 中获取到的 Value 是 User 类型的（第一行日志），而且 Redis 中实际保存的 Value 包含了类型完全限定名（第二行日志）： + +[15:10:50.396] [http-nio-45678-exec-1] [INFO ] [.t.c.s.demo1.RedisTemplateController:55 ] - userRedisTemplate get User(name=zhuye, age=36) class org.geekbang.time.commonmistakes.serialization.demo1.User +[15:10:50.399] [http-nio-45678-exec-1] [INFO ] [.t.c.s.demo1.RedisTemplateController:56 ] - stringRedisTemplate get ["org.geekbang.time.commonmistakes.serialization.demo1.User",{"name":"zhuye","age":36}] + + +因此，反序列化时可以直接得到 User 类型的 Value。 + +通过对 RedisTemplate 组件的分析，可以看到，当数据需要序列化后保存时，读写数据使用一致的序列化算法的必要性，否则就像对牛弹琴。 + +这里，我再总结下 Spring 提供的 4 种 RedisSerializer（Redis 序列化器）： + +默认情况下，RedisTemplate 使用 JdkSerializationRedisSerializer，也就是 JDK 序列化，容易产生 Redis 中保存了乱码的错觉。 + +通常考虑到易读性，可以设置 Key 的序列化器为 StringRedisSerializer。但直接使用 RedisSerializer.string()，相当于使用了 UTF_8 编码的 StringRedisSerializer，需要注意字符集问题。 + +如果希望 Value 也是使用 JSON 序列化的话，可以把 Value 序列化器设置为 Jackson2JsonRedisSerializer。默认情况下，不会把类型信息保存在 Value 中，即使我们定义 RedisTemplate 的 Value 泛型为实际类型，查询出的 Value 也只能是 LinkedHashMap 类型。如果希望直接获取真实的数据类型，你可以启用 Jackson ObjectMapper 的 activateDefaultTyping 方法，把类型信息一起序列化保存在 Value 中。 + +如果希望 Value 以 JSON 保存并带上类型信息，更简单的方式是，直接使用 RedisSerializer.json() 快捷方法来获取序列化器。 + +注意 Jackson JSON 反序列化对额外字段的处理 + +前面我提到，通过设置 JSON 序列化工具 Jackson 的 activateDefaultTyping 方法，可以在序列化数据时写入对象类型。其实，Jackson 还有很多参数可以控制序列化和反序列化，是一个功能强大而完善的序列化工具。因此，很多框架都将 Jackson 作为 JDK 序列化工具，比如 Spring Web。但也正是这个原因，我们使用时要小心各个参数的配置。 + +比如，在开发 Spring Web 应用程序时，如果自定义了 ObjectMapper，并把它注册成了 Bean，那很可能会导致 Spring Web 使用的 ObjectMapper 也被替换，导致 Bug。 + +我们来看一个案例。程序一开始是正常的，某一天开发同学希望修改一下 ObjectMapper 的行为，让枚举序列化为索引值而不是字符串值，比如默认情况下序列化一个 Color 枚举中的 Color.BLUE 会得到字符串 BLUE： + +@Autowired +private ObjectMapper objectMapper; + +@GetMapping("test") +public void test() throws JsonProcessingException { + log.info("color:{}", objectMapper.writeValueAsString(Color.BLUE)); +} + +enum Color { + RED, BLUE +} + + +于是，这位同学就重新定义了一个 ObjectMapper Bean，开启了 WRITE_ENUMS_USING_INDEX 功能特性： + +@Bean +public ObjectMapper objectMapper(){ + + ObjectMapper objectMapper=new ObjectMapper(); + + objectMapper.configure(SerializationFeature.WRITE_ENUMS_USING_INDEX,true); + + return objectMapper; +} + + +开启这个特性后，Color.BLUE 枚举序列化成索引值 1： + +[16:11:37.382] [http-nio-45678-exec-1] [INFO ] [c.s.d.JsonIgnorePropertiesController:19 ] - color:1 + + +修改后处理枚举序列化的逻辑是满足了要求，但线上爆出了大量 400 错误，日志中也出现了很多 UnrecognizedPropertyException： + +JSON parse error: Unrecognized field \"ver\" (class org.geekbang.time.commonmistakes.serialization.demo4.UserWrong), not marked as ignorable; nested exception is com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field \"version\" (class org.geekbang.time.commonmistakes.serialization.demo4.UserWrong), not marked as ignorable (one known property: \"name\"])\n at [Source: (PushbackInputStream); line: 1, column: 22] (through reference chain: org.geekbang.time.commonmistakes.serialization.demo4.UserWrong[\"ver\"]) + + +从异常信息中可以看到，这是因为反序列化的时候，原始数据多了一个 version 属性。进一步分析发现，我们使用了 UserWrong 类型作为 Web 控制器 wrong 方法的入参，其中只有一个 name 属性： + +@Data +public class UserWrong { + + private String name; + +} + +@PostMapping("wrong") +public UserWrong wrong(@RequestBody UserWrong user) { + + return user; + +} + + +而客户端实际传过来的数据多了一个 version 属性。那，为什么之前没这个问题呢？ + +问题就出在，自定义 ObjectMapper 启用 WRITE_ENUMS_USING_INDEX 序列化功能特性时，覆盖了 Spring Boot 自动创建的 ObjectMapper；而这个自动创建的 ObjectMapper 设置过 FAIL_ON_UNKNOWN_PROPERTIES 反序列化特性为 false，以确保出现未知字段时不要抛出异常。源码如下： + +public MappingJackson2HttpMessageConverter() { + this(Jackson2ObjectMapperBuilder.json().build()); +} + +public class Jackson2ObjectMapperBuilder { +... + private void customizeDefaultFeatures(ObjectMapper objectMapper) { + + if (!this.features.containsKey(MapperFeature.DEFAULT_VIEW_INCLUSION)) { + configureFeature(objectMapper, MapperFeature.DEFAULT_VIEW_INCLUSION, false); + } + + if (!this.features.containsKey(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)) { + configureFeature(objectMapper, DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); + } + } +} + + +要修复这个问题，有三种方式： + +第一种，同样禁用自定义的 ObjectMapper 的 FAIL_ON_UNKNOWN_PROPERTIES： + +@Bean +public ObjectMapper objectMapper(){ + + ObjectMapper objectMapper=new ObjectMapper(); + + objectMapper.configure(SerializationFeature.WRITE_ENUMS_USING_INDEX,true); + + objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES,false); + + return objectMapper; + +} + + +第二种，设置自定义类型，加上 @JsonIgnoreProperties 注解，开启 ignoreUnknown 属性，以实现反序列化时忽略额外的数据： + +@Data +@JsonIgnoreProperties(ignoreUnknown = true) +public class UserRight { + + private String name; + +} + + +第三种，不要自定义 ObjectMapper，而是直接在配置文件设置相关参数，来修改 Spring 默认的 ObjectMapper 的功能。比如，直接在配置文件启用把枚举序列化为索引号： + +spring.jackson.serialization.write_enums_using_index=true + + +或者可以直接定义 Jackson2ObjectMapperBuilderCustomizer Bean 来启用新特性： + +@Bean +public Jackson2ObjectMapperBuilderCustomizer customizer(){ + return builder -> builder.featuresToEnable(SerializationFeature.WRITE_ENUMS_USING_INDEX); +} + + +这个案例告诉我们两点： + +Jackson 针对序列化和反序列化有大量的细节功能特性，我们可以参考 Jackson 官方文档来了解这些特性，详见SerializationFeature、DeserializationFeature和MapperFeature。 + +忽略多余字段，是我们写业务代码时最容易遇到的一个配置项。Spring Boot 在自动配置时贴心地做了全局设置。如果需要设置更多的特性，可以直接修改配置文件 spring.jackson.** 或设置 Jackson2ObjectMapperBuilderCustomizer 回调接口，来启用更多设置，无需重新定义 ObjectMapper Bean。 + +反序列化时要小心类的构造方法 + +使用 Jackson 反序列化时，除了要注意忽略额外字段的问题外，还要小心类的构造方法。我们看一个实际的踩坑案例吧。 + +有一个 APIResult 类包装了 REST 接口的返回体（作为 Web 控制器的出参），其中 boolean 类型的 success 字段代表是否处理成功、int 类型的 code 字段代表处理状态码。 + +开始时，在返回 APIResult 的时候每次都根据 code 来设置 success。如果 code 是 2000，那么 success 是 true，否则是 false。后来为了减少重复代码，把这个逻辑放到了 APIResult 类的构造方法中处理： + +@Data +public class APIResultWrong { + + private boolean success; + + private int code; + + public APIResultWrong() { + + } + + public APIResultWrong(int code) { + this.code = code; + if (code == 2000) success = true; + else success = false; + } +} + + +经过改动后发现，即使 code 为 2000，返回 APIResult 的 success 也是 false。比如，我们反序列化两次 APIResult，一次使用 code==1234，一次使用 code==2000： + +@Autowired +ObjectMapper objectMapper; + +@GetMapping("wrong") +public void wrong() throws JsonProcessingException { + log.info("result :{}", objectMapper.readValue("{\"code\":1234}", APIResultWrong.class)); + log.info("result :{}", objectMapper.readValue("{\"code\":2000}", APIResultWrong.class)); +} + + +日志输出如下： + +[17:36:14.591] [http-nio-45678-exec-1] [INFO ] [DeserializationConstructorController:20 ] - result :APIResultWrong(success=false, code=1234) +[17:36:14.591] [http-nio-45678-exec-1] [INFO ] [DeserializationConstructorController:21 ] - result :APIResultWrong(success=false, code=2000) + + +可以看到，两次的 APIResult 的 success 字段都是 false。 + +出现这个问题的原因是，默认情况下，在反序列化的时候，Jackson 框架只会调用无参构造方法创建对象。如果走自定义的构造方法创建对象，需要通过 @JsonCreator 来指定构造方法，并通过 @JsonProperty 设置构造方法中参数对应的 JSON 属性名： + +@Data +public class APIResultRight { + ... + @JsonCreator + public APIResultRight(@JsonProperty("code") int code) { + this.code = code; + if (code == 2000) success = true; + else success = false; + } +} + + +重新运行程序，可以得到正确输出： + +[17:41:23.188] [http-nio-45678-exec-1] [INFO ] [DeserializationConstructorController:26 ] - result :APIResultRight(success=false, code=1234) +[17:41:23.188] [http-nio-45678-exec-1] [INFO ] [DeserializationConstructorController:27 ] - result :APIResultRight(success=true, code=2000) + + +可以看到，这次传入 code==2000 时，success 可以设置为 true。 + +枚举作为 API 接口参数或返回值的两个大坑 + +在前面的例子中，我演示了如何把枚举序列化为索引值。但对于枚举，我建议尽量在程序内部使用，而不是作为 API 接口的参数或返回值，原因是枚举涉及序列化和反序列化时会有两个大坑。 + +第一个坑是，客户端和服务端的枚举定义不一致时，会出异常。比如，客户端版本的枚举定义了 4 个枚举值： + +@Getter +enum StatusEnumClient { + + CREATED(1, "已创建"), + + PAID(2, "已支付"), + + DELIVERED(3, "已送到"), + + FINISHED(4, "已完成"); + + private final int status; + + private final String desc; + + StatusEnumClient(Integer status, String desc) { + this.status = status; + this.desc = desc; + } +} + + +服务端定义了 5 个枚举值： + +@Getter +enum StatusEnumServer { + + ... + + CANCELED(5, "已取消"); + + private final int status; + + private final String desc; + + StatusEnumServer(Integer status, String desc) { + this.status = status; + this.desc = desc; + } +} + + +写代码测试一下，使用 RestTemplate 来发起请求，让服务端返回客户端不存在的枚举值： + +@GetMapping("getOrderStatusClient") +public void getOrderStatusClient() { + + StatusEnumClient result = restTemplate.getForObject("http://localhost:45678/enumusedinapi/getOrderStatus", StatusEnumClient.class); + log.info("result {}", result); + +} + +@GetMapping("getOrderStatus") +public StatusEnumServer getOrderStatus() { + + return StatusEnumServer.CANCELED; + +} + + +访问接口会出现如下异常信息，提示在枚举 StatusEnumClient 中找不到 CANCELED： + +JSON parse error: Cannot deserialize value of type `org.geekbang.time.commonmistakes.enums.enumusedinapi.StatusEnumClient` from String "CANCELED": not one of the values accepted for Enum class: [CREATED, FINISHED, DELIVERED, PAID]; + + +要解决这个问题，可以开启 Jackson 的 read_unknown_enum_values_using_default_value 反序列化特性，也就是在枚举值未知的时候使用默认值： + +spring.jackson.deserialization.read_unknown_enum_values_using_default_value=true + + +并为枚举添加一个默认值，使用 @JsonEnumDefaultValue 注解注释： + +@JsonEnumDefaultValue +UNKNOWN(-1, "未知"); + + +需要注意的是，这个枚举值一定是添加在客户端 StatusEnumClient 中的，因为反序列化使用的是客户端枚举。 + +这里还有一个小坑是，仅仅这样配置还不能让 RestTemplate 生效这个反序列化特性，还需要配置 RestTemplate，来使用 Spring Boot 的 MappingJackson2HttpMessageConverter 才行： + +@Bean +public RestTemplate restTemplate(MappingJackson2HttpMessageConverter mappingJackson2HttpMessageConverter) { + + return new RestTemplateBuilder() + .additionalMessageConverters(mappingJackson2HttpMessageConverter) + .build(); +} + + +现在，请求接口可以返回默认值了： + +[21:49:03.887] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.e.e.EnumUsedInAPIController:25 ] - result UNKNOWN + + +第二个坑，也是更大的坑，枚举序列化反序列化实现自定义的字段非常麻烦，会涉及 Jackson 的 Bug。比如，下面这个接口，传入枚举 List，为 List 增加一个 CENCELED 枚举值然后返回： + +@PostMapping("queryOrdersByStatusList") +public List queryOrdersByStatus(@RequestBody List enumServers) { + enumServers.add(StatusEnumServer.CANCELED); + return enumServers; +} + + +如果我们希望根据枚举的 Desc 字段来序列化，传入“已送到”作为入参： + + + +会得到异常，提示“已送到”不是正确的枚举值： + +JSON parse error: Cannot deserialize value of type `org.geekbang.time.commonmistakes.enums.enumusedinapi.StatusEnumServer` from String "已送到": not one of the values accepted for Enum class: [CREATED, CANCELED, FINISHED, DELIVERED, PAID] + + +显然，这里反序列化使用的是枚举的 name，序列化也是一样： + + + +你可能也知道，要让枚举的序列化和反序列化走 desc 字段，可以在字段上加 @JsonValue 注解，修改 StatusEnumServer 和 StatusEnumClient： + +@JsonValue +private final String desc; + + +然后再尝试下，果然可以用 desc 作为入参了，而且出参也使用了枚举的 desc： + + + +但是，如果你认为这样就完美解决问题了，那就大错特错了。你可以再尝试把 @JsonValue 注解加在 int 类型的 status 字段上，也就是希望序列化反序列化走 status 字段： + +@JsonValue +private final int status; + + +写一个客户端测试一下，传入 CREATED 和 PAID 两个枚举值： + +@GetMapping("queryOrdersByStatusListClient") +public void queryOrdersByStatusListClient() { + + List request = Arrays.asList(StatusEnumClient.CREATED, StatusEnumClient.PAID); + + HttpEntity> entity = new HttpEntity<>(request, new HttpHeaders()); + + List response = restTemplate.exchange("http://localhost:45678/enumusedinapi/queryOrdersByStatusList", + HttpMethod.POST, entity, new ParameterizedTypeReference>() {}).getBody(); + log.info("result {}", response); +} + + +请求接口可以看到，传入的是 CREATED 和 PAID，返回的居然是 DELIVERED 和 FINISHED。果然如标题所说，一来一回你已不是原来的你： + +[22:03:03.579] [http-nio-45678-exec-4] [INFO ] [o.g.t.c.e.e.EnumUsedInAPIController:34 ] - result [DELIVERED, FINISHED, UNKNOWN] + + +出现这个问题的原因是，序列化走了 status 的值，而反序列化并没有根据 status 来，还是使用了枚举的 ordinal() 索引值。这是 Jackson至今（2.10）没有解决的 Bug，应该会在 2.11 解决。 + +如下图所示，我们调用服务端接口，传入一个不存在的 status 值 0，也能反序列化成功，最后服务端的返回是 1： + + + +有一个解决办法是，设置 @JsonCreator 来强制反序列化时使用自定义的工厂方法，可以实现使用枚举的 status 字段来取值。我们把这段代码加在 StatusEnumServer 枚举类中： + +@JsonCreator +public static StatusEnumServer parse(Object o) { + return Arrays.stream(StatusEnumServer.values()).filter(value->o.equals(value.status)).findFirst().orElse(null); +} + + +要特别注意的是，我们同样要为 StatusEnumClient 也添加相应的方法。因为除了服务端接口接收 StatusEnumServer 参数涉及一次反序列化外，从服务端返回值转换为 List 还会有一次反序列化： + +@JsonCreator +public static StatusEnumClient parse(Object o) { + return Arrays.stream(StatusEnumClient.values()).filter(value->o.equals(value.status)).findFirst().orElse(null); +} + + +重新调用接口发现，虽然结果正确了，但是服务端不存在的枚举值 CANCELED 被设置为了 null，而不是 @JsonEnumDefaultValue 设置的 UNKNOWN。 + +这个问题，我们之前已经通过设置 @JsonEnumDefaultValue 注解解决了，但现在又出现了： + +[22:20:13.727] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.e.e.EnumUsedInAPIController:34 ] - result [CREATED, PAID, null] + + +原因也很简单，我们自定义的 parse 方法实现的是找不到枚举值时返回 null。 + +为彻底解决这个问题，并避免通过 @JsonCreator 在枚举中自定义一个非常复杂的工厂方法，我们可以实现一个自定义的反序列化器。这段代码比较复杂，我特意加了详细的注释： + +class EnumDeserializer extends JsonDeserializer implements ContextualDeserializer { + + private Class targetClass; + + public EnumDeserializer() { + } + + public EnumDeserializer(Class targetClass) { + this.targetClass = targetClass; + } + + @Override + public Enum deserialize(JsonParser p, DeserializationContext ctxt) { + + //找枚举中带有@JsonValue注解的字段，这是我们反序列化的基准字段 + Optional valueFieldOpt = Arrays.asList(targetClass.getDeclaredFields()).stream() + .filter(m -> m.isAnnotationPresent(JsonValue.class)) + .findFirst(); + if (valueFieldOpt.isPresent()) { + Field valueField = valueFieldOpt.get(); + if (!valueField.isAccessible()) { + valueField.setAccessible(true); + } + //遍历枚举项，查找字段的值等于反序列化的字符串的那个枚举项 + return Arrays.stream(targetClass.getEnumConstants()).filter(e -> { + try { + return valueField.get(e).toString().equals(p.getValueAsString()); + } catch (Exception ex) { + ex.printStackTrace(); + } + return false; + }).findFirst().orElseGet(() -> Arrays.stream(targetClass.getEnumConstants()).filter(e -> { + //如果找不到，就需要寻找默认枚举值来替代，同样遍历所有枚举项，查找@JsonEnumDefaultValue注解标识的枚举项 + try { + return targetClass.getField(e.name()).isAnnotationPresent(JsonEnumDefaultValue.class); + } catch (Exception ex) { + ex.printStackTrace(); + } + return false; + }).findFirst().orElse(null)); + } + return null; + } + + @Override + public JsonDeserializer createContextual(DeserializationContext ctxt, + BeanProperty property) throws JsonMappingException { + + targetClass = (Class) ctxt.getContextualType().getRawClass(); + return new EnumDeserializer(targetClass); + } +} + + +然后，把这个自定义反序列化器注册到 Jackson 中： + +@Bean +public Module enumModule() { + + SimpleModule module = new SimpleModule(); + + module.addDeserializer(Enum.class, new EnumDeserializer()); + + return module; + +} + + +第二个大坑终于被完美地解决了： + +[22:32:28.327] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.e.e.EnumUsedInAPIController:34 ] - result [CREATED, PAID, UNKNOWN] + + +这样做，虽然解决了序列化反序列化使用枚举中自定义字段的问题，也解决了找不到枚举值时使用默认值的问题，但解决方案很复杂。因此，我还是建议在 DTO 中直接使用 int 或 String 等简单的数据类型，而不是使用枚举再配合各种复杂的序列化配置，来实现枚举到枚举中字段的映射，会更加清晰明了。 + +重点回顾 + +今天，我基于 Redis 和 Web API 的入参和出参两个场景，和你介绍了序列化和反序列化时需要避开的几个坑。 + +第一，要确保序列化和反序列化算法的一致性。因为，不同序列化算法输出必定不同，要正确处理序列化后的数据就要使用相同的反序列化算法。 + +第二，Jackson 有大量的序列化和反序列化特性，可以用来微调序列化和反序列化的细节。需要注意的是，如果自定义 ObjectMapper 的 Bean，小心不要和 Spring Boot 自动配置的 Bean 冲突。 + +第三，在调试序列化反序列化问题时，我们一定要捋清楚三点：是哪个组件在做序列化反序列化、整个过程有几次序列化反序列化，以及目前到底是序列化还是反序列化。 + +第四，对于反序列化默认情况下，框架调用的是无参构造方法，如果要调用自定义的有参构造方法，那么需要告知框架如何调用。更合理的方式是，对于需要序列化的 POJO 考虑尽量不要自定义构造方法。 + +第五，枚举不建议定义在 DTO 中跨服务传输，因为会有版本问题，并且涉及序列化反序列化时会很复杂，容易出错。因此，我只建议在程序内部使用枚举。 + +最后还有一点需要注意，如果需要跨平台使用序列化的数据，那么除了两端使用的算法要一致外，还可能会遇到不同语言对数据类型的兼容问题。这，也是经常踩坑的一个地方。如果你有相关需求，可以多做实验、多测试。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在讨论 Redis 序列化方式的时候，我们自定义了 RedisTemplate，让 Key 使用 String 序列化、让 Value 使用 JSON 序列化，从而使 Redis 获得的 Value 可以直接转换为需要的对象类型。那么，使用 RedisTemplate 能否存取 Value 是 Long 的数据呢？这其中有什么坑吗？ + +你可以看一下 Jackson2ObjectMapperBuilder 类源码的实现（注意 configure 方法），分析一下其除了关闭 FAIL_ON_UNKNOWN_PROPERTIES 外，还做了什么吗？ + +关于序列化和反序列化，你还遇到过什么坑吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把这篇文章分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/16用好Java8的日期时间类，少踩一些“老三样”的坑.md b/专栏/Java业务开发常见错误100例/16用好Java8的日期时间类，少踩一些“老三样”的坑.md new file mode 100644 index 0000000..5de58d9 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/16用好Java8的日期时间类，少踩一些“老三样”的坑.md @@ -0,0 +1,526 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 16 用好Java 8的日期时间类，少踩一些“老三样”的坑 + 今天，我来和你说说恼人的时间错乱问题。 + +在 Java 8 之前，我们处理日期时间需求时，使用 Date、Calender 和 SimpleDateFormat，来声明时间戳、使用日历处理日期和格式化解析日期时间。但是，这些类的 API 的缺点比较明显，比如可读性差、易用性差、使用起来冗余繁琐，还有线程安全问题。 + +因此，Java 8 推出了新的日期时间类。每一个类功能明确清晰、类之间协作简单、API 定义清晰不踩坑，API 功能强大无需借助外部工具类即可完成操作，并且线程安全。 + +但是，Java 8 刚推出的时候，诸如序列化、数据访问等类库都还不支持 Java 8 的日期时间类型，需要在新老类中来回转换。比如，在业务逻辑层使用 LocalDateTime，存入数据库或者返回前端的时候还要切换回 Date。因此，很多同学还是选择使用老的日期时间类。 + +现在几年时间过去了，几乎所有的类库都支持了新日期时间类型，使用起来也不会有来回切换等问题了。但，很多代码中因为还是用的遗留的日期时间类，因此出现了很多时间错乱的错误实践。比如，试图通过随意修改时区，使读取到的数据匹配当前时钟；再比如，试图直接对读取到的数据做加、减几个小时的操作，来“修正数据”。 + +今天，我就重点与你分析下时间错乱问题背后的原因，看看使用遗留的日期时间类，来处理日期时间初始化、格式化、解析、计算等可能会遇到的问题，以及如何使用新日期时间类来解决。 + +初始化日期时间 + +我们先从日期时间的初始化看起。如果要初始化一个 2019 年 12 月 31 日 11 点 12 分 13 秒这样的时间，可以使用下面的两行代码吗？ + +Date date = new Date(2019, 12, 31, 11, 12, 13); +System.out.println(date); + + +可以看到，输出的时间是 3029 年 1 月 31 日 11 点 12 分 13 秒： + +Sat Jan 31 11:12:13 CST 3920 + + +相信看到这里，你会说这是新手才会犯的低级错误：年应该是和 1900 的差值，月应该是从 0 到 11 而不是从 1 到 12。 + +Date date = new Date(2019 - 1900, 11, 31, 11, 12, 13); + + +你说的没错，但更重要的问题是，当有国际化需求时，需要使用 Calendar 类来初始化时间。 + +使用 Calendar 改造之后，初始化时年参数直接使用当前年即可，不过月需要注意是从 0 到 11。当然，你也可以直接使用 Calendar.DECEMBER 来初始化月份，更不容易犯错。为了说明时区的问题，我分别使用当前时区和纽约时区初始化了两次相同的日期： + +Calendar calendar = Calendar.getInstance(); +calendar.set(2019, 11, 31, 11, 12, 13); +System.out.println(calendar.getTime()); + +Calendar calendar2 = Calendar.getInstance(TimeZone.getTimeZone("America/New_York")); +calendar2.set(2019, Calendar.DECEMBER, 31, 11, 12, 13); +System.out.println(calendar2.getTime()); + + +输出显示了两个时间，说明时区产生了作用。但，我们更习惯年 / 月 / 日 时: 分: 秒这样的日期时间格式，对现在输出的日期格式还不满意： + +Tue Dec 31 11:12:13 CST 2019 +Wed Jan 01 00:12:13 CST 2020 + + +那，时区的问题是怎么回事，又怎么格式化需要输出的日期时间呢？接下来，我就与你逐一分析下这两个问题。 + +“恼人”的时区问题 + +我们知道，全球有 24 个时区，同一个时刻不同时区（比如中国上海和美国纽约）的时间是不一样的。对于需要全球化的项目，如果初始化时间时没有提供时区，那就不是一个真正意义上的时间，只能认为是我看到的当前时间的一个表示。 + +关于 Date 类，我们要有两点认识： + +一是，Date 并无时区问题，世界上任何一台计算机使用 new Date() 初始化得到的时间都一样。因为，Date 中保存的是 UTC 时间，UTC 是以原子钟为基础的统一时间，不以太阳参照计时，并无时区划分。 + +二是，Date 中保存的是一个时间戳，代表的是从 1970 年 1 月 1 日 0 点（Epoch 时间）到现在的毫秒数。尝试输出 Date(0)： + +System.out.println(new Date(0)); +System.out.println(TimeZone.getDefault().getID() + ":" + TimeZone.getDefault().getRawOffset()/3600000); + + +我得到的是 1970 年 1 月 1 日 8 点。因为我机器当前的时区是中国上海，相比 UTC 时差 +8 小时： + +Thu Jan 01 08:00:00 CST 1970 +Asia/Shanghai:8 + + +对于国际化（世界各国的人都在使用）的项目，处理好时间和时区问题首先就是要正确保存日期时间。这里有两种保存方式： + +方式一，以 UTC 保存，保存的时间没有时区属性，是不涉及时区时间差问题的世界统一时间。我们通常说的时间戳，或 Java 中的 Date 类就是用的这种方式，这也是推荐的方式。 + +方式二，以字面量保存，比如年 / 月 / 日 时: 分: 秒，一定要同时保存时区信息。只有有了时区信息，我们才能知道这个字面量时间真正的时间点，否则它只是一个给人看的时间表示，只在当前时区有意义。Calendar 是有时区概念的，所以我们通过不同的时区初始化 Calendar，得到了不同的时间。 + +正确保存日期时间之后，就是正确展示，即我们要使用正确的时区，把时间点展示为符合当前时区的时间表示。到这里，我们就能理解为什么会有所谓的“时间错乱”问题了。接下来，我再通过实际案例分析一下，从字面量解析成时间和从时间格式化为字面量这两类问题。 + +第一类是，对于同一个时间表示，比如 2020-01-02 22:00:00，不同时区的人转换成 Date 会得到不同的时间（时间戳）： + +String stringDate = "2020-01-02 22:00:00"; +SimpleDateFormat inputFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); + +//默认时区解析时间表示 +Date date1 = inputFormat.parse(stringDate); +System.out.println(date1 + ":" + date1.getTime()); + +//纽约时区解析时间表示 +inputFormat.setTimeZone(TimeZone.getTimeZone("America/New_York")); +Date date2 = inputFormat.parse(stringDate); +System.out.println(date2 + ":" + date2.getTime()); + + +可以看到，把 2020-01-02 22:00:00 这样的时间表示，对于当前的上海时区和纽约时区，转化为 UTC 时间戳是不同的时间： + +Thu Jan 02 22:00:00 CST 2020:1577973600000 +Fri Jan 03 11:00:00 CST 2020:1578020400000 + + +这正是 UTC 的意义，并不是时间错乱。对于同一个本地时间的表示，不同时区的人解析得到的 UTC 时间一定是不同的，反过来不同的本地时间可能对应同一个 UTC。 + +第二类问题是，格式化后出现的错乱，即同一个 Date，在不同的时区下格式化得到不同的时间表示。比如，在我的当前时区和纽约时区格式化 2020-01-02 22:00:00： + +String stringDate = "2020-01-02 22:00:00"; +SimpleDateFormat inputFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); +//同一Date +Date date = inputFormat.parse(stringDate); +//默认时区格式化输出： +System.out.println(new SimpleDateFormat("[yyyy-MM-dd HH:mm:ss Z]").format(date)); +//纽约时区格式化输出 +TimeZone.setDefault(TimeZone.getTimeZone("America/New_York")); +System.out.println(new SimpleDateFormat("[yyyy-MM-dd HH:mm:ss Z]").format(date)); + + +输出如下，我当前时区的 Offset（时差）是 +8 小时，对于 -5 小时的纽约，晚上 10 点对应早上 9 点： + +[2020-01-02 22:00:00 +0800] +[2020-01-02 09:00:00 -0500] + + +因此，有些时候数据库中相同的时间，由于服务器的时区设置不同，读取到的时间表示不同。这，不是时间错乱，正是时区发挥了作用，因为 UTC 时间需要根据当前时区解析为正确的本地时间。 + +所以，要正确处理时区，在于存进去和读出来两方面：存的时候，需要使用正确的当前时区来保存，这样 UTC 时间才会正确；读的时候，也只有正确设置本地时区，才能把 UTC 时间转换为正确的当地时间。 + +Java 8 推出了新的时间日期类 ZoneId、ZoneOffset、LocalDateTime、ZonedDateTime 和 DateTimeFormatter，处理时区问题更简单清晰。我们再用这些类配合一个完整的例子，来理解一下时间的解析和展示： + +首先初始化上海、纽约和东京三个时区。我们可以使用 ZoneId.of 来初始化一个标准的时区，也可以使用 ZoneOffset.ofHours 通过一个 offset，来初始化一个具有指定时间差的自定义时区。 + +对于日期时间表示，LocalDateTime 不带有时区属性，所以命名为本地时区的日期时间；而 ZonedDateTime=LocalDateTime+ZoneId，具有时区属性。因此，LocalDateTime 只能认为是一个时间表示，ZonedDateTime 才是一个有效的时间。在这里我们把 2020-01-02 22:00:00 这个时间表示，使用东京时区来解析得到一个 ZonedDateTime。 + +使用 DateTimeFormatter 格式化时间的时候，可以直接通过 withZone 方法直接设置格式化使用的时区。最后，分别以上海、纽约和东京三个时区来格式化这个时间输出： + +//一个时间表示 +String stringDate = "2020-01-02 22:00:00"; + +//初始化三个时区 +ZoneId timeZoneSH = ZoneId.of("Asia/Shanghai"); +ZoneId timeZoneNY = ZoneId.of("America/New_York"); +ZoneId timeZoneJST = ZoneOffset.ofHours(9); + +//格式化器 +DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); +ZonedDateTime date = ZonedDateTime.of(LocalDateTime.parse(stringDate, dateTimeFormatter), timeZoneJST); + +//使用DateTimeFormatter格式化时间，可以通过withZone方法直接设置格式化使用的时区 +DateTimeFormatter outputFormat = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss Z"); +System.out.println(timeZoneSH.getId() + outputFormat.withZone(timeZoneSH).format(date)); +System.out.println(timeZoneNY.getId() + outputFormat.withZone(timeZoneNY).format(date)); +System.out.println(timeZoneJST.getId() + outputFormat.withZone(timeZoneJST).format(date)); + + +可以看到，相同的时区，经过解析存进去和读出来的时间表示是一样的（比如最后一行）；而对于不同的时区，比如上海和纽约，最后输出的本地时间不同。+9 小时时区的晚上 10 点，对于上海是 +8 小时，所以上海本地时间是晚上 9 点；而对于纽约是 -5 小时，差 14 小时，所以是早上 8 点： + +Asia/Shanghai2020-01-02 21:00:00 +0800 +America/New_York2020-01-02 08:00:00 -0500 ++09:002020-01-02 22:00:00 +0900 + + +到这里，我来小结下。要正确处理国际化时间问题，我推荐使用 Java 8 的日期时间类，即使用 ZonedDateTime 保存时间，然后使用设置了 ZoneId 的 DateTimeFormatter 配合 ZonedDateTime 进行时间格式化得到本地时间表示。这样的划分十分清晰、细化，也不容易出错。 + +接下来，我们继续看看对于日期时间的格式化和解析，使用遗留的 SimpleDateFormat，会遇到哪些问题。 + +日期时间格式化和解析 + +每到年底，就有很多开发同学踩时间格式化的坑，比如“这明明是一个 2019 年的日期，怎么使用 SimpleDateFormat 格式化后就提前跨年了”。我们来重现一下这个问题。 + +初始化一个 Calendar，设置日期时间为 2019 年 12 月 29 日，使用大写的 YYYY 来初始化 SimpleDateFormat： + +Locale.setDefault(Locale.SIMPLIFIED_CHINESE); +System.out.println("defaultLocale:" + Locale.getDefault()); +Calendar calendar = Calendar.getInstance(); +calendar.set(2019, Calendar.DECEMBER, 29,0,0,0); +SimpleDateFormat YYYY = new SimpleDateFormat("YYYY-MM-dd"); +System.out.println("格式化: " + YYYY.format(calendar.getTime())); +System.out.println("weekYear:" + calendar.getWeekYear()); +System.out.println("firstDayOfWeek:" + calendar.getFirstDayOfWeek()); +System.out.println("minimalDaysInFirstWeek:" + calendar.getMinimalDaysInFirstWeek()); + + +得到的输出却是 2020 年 12 月 29 日： + +defaultLocale:zh_CN +格式化: 2020-12-29 +weekYear:2020 +firstDayOfWeek:1 +minimalDaysInFirstWeek:1 + + +出现这个问题的原因在于，这位同学混淆了 SimpleDateFormat 的各种格式化模式。JDK 的文档中有说明：小写 y 是年，而大写 Y 是 week year，也就是所在的周属于哪一年。 + +一年第一周的判断方式是，从 getFirstDayOfWeek() 开始，完整的 7 天，并且包含那一年至少 getMinimalDaysInFirstWeek() 天。这个计算方式和区域相关，对于当前 zh_CN 区域来说，2020 年第一周的条件是，从周日开始的完整 7 天，2020 年包含 1 天即可。显然，2019 年 12 月 29 日周日到 2020 年 1 月 4 日周六是 2020 年第一周，得出的 week year 就是 2020 年。 + +如果把区域改为法国： + +Locale.setDefault(Locale.FRANCE); + + +那么 week yeay 就还是 2019 年，因为一周的第一天从周一开始算，2020 年的第一周是 2019 年 12 月 30 日周一开始，29 日还是属于去年： + +defaultLocale:fr_FR +格式化: 2019-12-29 +weekYear:2019 +firstDayOfWeek:2 +minimalDaysInFirstWeek:4 + + +这个案例告诉我们，没有特殊需求，针对年份的日期格式化，应该一律使用 “y” 而非 “Y”。 + +除了格式化表达式容易踩坑外，SimpleDateFormat 还有两个著名的坑。 + +第一个坑是，定义的 static 的 SimpleDateFormat 可能会出现线程安全问题。比如像这样，使用一个 100 线程的线程池，循环 20 次把时间格式化任务提交到线程池处理，每个任务中又循环 10 次解析 2020-01-01 11:12:13 这样一个时间表示： + +ExecutorService threadPool = Executors.newFixedThreadPool(100); +for (int i = 0; i < 20; i++) { + //提交20个并发解析时间的任务到线程池，模拟并发环境 + threadPool.execute(() -> { + for (int j = 0; j < 10; j++) { + try { + System.out.println(simpleDateFormat.parse("2020-01-01 11:12:13")); + } catch (ParseException e) { + e.printStackTrace(); + } + } + }); +} +threadPool.shutdown(); + +threadPool.awaitTermination(1, TimeUnit.HOURS); + + +运行程序后大量报错，且没有报错的输出结果也不正常，比如 2020 年解析成了 1212 年： + + + +SimpleDateFormat 的作用是定义解析和格式化日期时间的模式。这，看起来这是一次性的工作，应该复用，但它的解析和格式化操作是非线程安全的。我们来分析一下相关源码： + +SimpleDateFormat 继承了 DateFormat，DateFormat 有一个字段 Calendar； + +SimpleDateFormat 的 parse 方法调用 CalendarBuilder 的 establish 方法，来构建 Calendar； + +establish 方法内部先清空 Calendar 再构建 Calendar，整个操作没有加锁。 + +显然，如果多线程池调用 parse 方法，也就意味着多线程在并发操作一个 Calendar，可能会产生一个线程还没来得及处理 Calendar 就被另一个线程清空了的情况： + +public abstract class DateFormat extends Format { + protected Calendar calendar; +} + +public class SimpleDateFormat extends DateFormat { + + @Override + public Date parse(String text, ParsePosition pos) { + CalendarBuilder calb = new CalendarBuilder(); + parsedDate = calb.establish(calendar).getTime(); + return parsedDate; + } +} + +class CalendarBuilder { + + Calendar establish(Calendar cal) { + + ... + cal.clear();//清空 + + for (int stamp = MINIMUM_USER_STAMP; stamp < nextStamp; stamp++) { + + for (int index = 0; index <= maxFieldIndex; index++) { + if (field[index] == stamp) { + cal.set(index, field[MAX_FIELD + index]);//构建 + break; + } + } + } + return cal; + } +} + + +format 方法也类似，你可以自己分析。因此只能在同一个线程复用 SimpleDateFormat，比较好的解决方式是，通过 ThreadLocal 来存放 SimpleDateFormat： + +private static ThreadLocal threadSafeSimpleDateFormat = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss")); + + +第二个坑是，当需要解析的字符串和格式不匹配的时候，SimpleDateFormat 表现得很宽容，还是能得到结果。比如，我们期望使用 yyyyMM 来解析 20160901 字符串： + +String dateString = "20160901"; +SimpleDateFormat dateFormat = new SimpleDateFormat("yyyyMM"); + +System.out.println("result:" + dateFormat.parse(dateString)); + + +居然输出了 2091 年 1 月 1 日，原因是把 0901 当成了月份，相当于 75 年： + +result:Mon Jan 01 00:00:00 CST 2091 + + +对于 SimpleDateFormat 的这三个坑，我们使用 Java 8 中的 DateTimeFormatter 就可以避过去。首先，使用 DateTimeFormatterBuilder 来定义格式化字符串，不用去记忆使用大写的 Y 还是小写的 Y，大写的 M 还是小写的 m： + +private static DateTimeFormatter dateTimeFormatter = new DateTimeFormatterBuilder() + .appendValue(ChronoField.YEAR) //年 + .appendLiteral("/") + .appendValue(ChronoField.MONTH_OF_YEAR) //月 + .appendLiteral("/") + .appendValue(ChronoField.DAY_OF_MONTH) //日 + .appendLiteral(" ") + .appendValue(ChronoField.HOUR_OF_DAY) //时 + .appendLiteral(":") + .appendValue(ChronoField.MINUTE_OF_HOUR) //分 + .appendLiteral(":") + .appendValue(ChronoField.SECOND_OF_MINUTE) //秒 + .appendLiteral(".") + .appendValue(ChronoField.MILLI_OF_SECOND) //毫秒 + .toFormatter(); + + +其次，DateTimeFormatter 是线程安全的，可以定义为 static 使用；最后，DateTimeFormatter 的解析比较严格，需要解析的字符串和格式不匹配时，会直接报错，而不会把 0901 解析为月份。我们测试一下： + +//使用刚才定义的DateTimeFormatterBuilder构建的DateTimeFormatter来解析这个时间 +LocalDateTime localDateTime = LocalDateTime.parse("2020/1/2 12:34:56.789", dateTimeFormatter); +//解析成功 +System.out.println(localDateTime.format(dateTimeFormatter)); +//使用yyyyMM格式解析20160901是否可以成功呢？ +String dt = "20160901"; +DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyyMM"); +System.out.println("result:" + dateTimeFormatter.parse(dt)); + + +输出日志如下： + +2020/1/2 12:34:56.789 +Exception in thread "main" java.time.format.DateTimeParseException: Text '20160901' could not be parsed at index 0 + at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) + at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1777) + at org.geekbang.time.commonmistakes.datetime.dateformat.CommonMistakesApplication.better(CommonMistakesApplication.java:80) + at org.geekbang.time.commonmistakes.datetime.dateformat.CommonMistakesApplication.main(CommonMistakesApplication.java:41) + + +到这里我们可以发现，使用 Java 8 中的 DateTimeFormatter 进行日期时间的格式化和解析，显然更让人放心。那么，对于日期时间的运算，使用 Java 8 中的日期时间类会不会更简单呢？ + +日期时间的计算 + +关于日期时间的计算，我先和你说一个常踩的坑。有些同学喜欢直接使用时间戳进行时间计算，比如希望得到当前时间之后 30 天的时间，会这么写代码：直接把 new Date().getTime 方法得到的时间戳加 30 天对应的毫秒数，也就是 30 天 *1000 毫秒 *3600 秒 *24 小时： + +Date today = new Date(); +Date nextMonth = new Date(today.getTime() + 30 * 1000 * 60 * 60 * 24); +System.out.println(today); +System.out.println(nextMonth); + + +得到的日期居然比当前日期还要早，根本不是晚 30 天的时间： + +Sat Feb 01 14:17:41 CST 2020 +Sun Jan 12 21:14:54 CST 2020 + + +出现这个问题，其实是因为 int 发生了溢出。修复方式就是把 30 改为 30L，让其成为一个 long： + +Date today = new Date(); +Date nextMonth = new Date(today.getTime() + 30L * 1000 * 60 * 60 * 24); +System.out.println(today); +System.out.println(nextMonth); + + +这样就可以得到正确结果了： + +Sat Feb 01 14:17:41 CST 2020 +Mon Mar 02 14:17:41 CST 2020 + + +不难发现，手动在时间戳上进行计算操作的方式非常容易出错。对于 Java 8 之前的代码，我更建议使用 Calendar： + +Calendar c = Calendar.getInstance(); +c.setTime(new Date()); +c.add(Calendar.DAY_OF_MONTH, 30); +System.out.println(c.getTime()); + + +使用 Java 8 的日期时间类型，可以直接进行各种计算，更加简洁和方便： + +LocalDateTime localDateTime = LocalDateTime.now(); +System.out.println(localDateTime.plusDays(30)); + + +并且，对日期时间做计算操作，Java 8 日期时间 API 会比 Calendar 功能强大很多。 + +第一，可以使用各种 minus 和 plus 方法直接对日期进行加减操作，比如如下代码实现了减一天和加一天，以及减一个月和加一个月： + +System.out.println("//测试操作日期"); +System.out.println(LocalDate.now() + .minus(Period.ofDays(1)) + .plus(1, ChronoUnit.DAYS) + .minusMonths(1) + .plus(Period.ofMonths(1))); + + +可以得到： + +//测试操作日期 +2020-02-01 + + +第二，还可以通过 with 方法进行快捷时间调节，比如： + +使用 TemporalAdjusters.firstDayOfMonth 得到当前月的第一天； + +使用 TemporalAdjusters.firstDayOfYear() 得到当前年的第一天； + +使用 TemporalAdjusters.previous(DayOfWeek.SATURDAY) 得到上一个周六； + +使用 TemporalAdjusters.lastInMonth(DayOfWeek.FRIDAY) 得到本月最后一个周五。 + +System.out.println("//本月的第一天"); +System.out.println(LocalDate.now().with(TemporalAdjusters.firstDayOfMonth())); +System.out.println("//今年的程序员日"); +System.out.println(LocalDate.now().with(TemporalAdjusters.firstDayOfYear()).plusDays(255)); +System.out.println("//今天之前的一个周六"); +System.out.println(LocalDate.now().with(TemporalAdjusters.previous(DayOfWeek.SATURDAY))); +System.out.println("//本月最后一个工作日"); +System.out.println(LocalDate.now().with(TemporalAdjusters.lastInMonth(DayOfWeek.FRIDAY))); + + +输出如下： + +//本月的第一天 +2020-02-01 +//今年的程序员日 +2020-09-12 +//今天之前的一个周六 +2020-01-25 +//本月最后一个工作日 +2020-02-28 + + +第三，可以直接使用 lambda 表达式进行自定义的时间调整。比如，为当前时间增加 100 天以内的随机天数： + +System.out.println(LocalDate.now().with(temporal -> temporal.plus(ThreadLocalRandom.current().nextInt(100), ChronoUnit.DAYS))); + + +得到： + +2020-03-15 + + +除了计算外，还可以判断日期是否符合某个条件。比如，自定义函数，判断指定日期是否是家庭成员的生日： + +public static Boolean isFamilyBirthday(TemporalAccessor date) { + int month = date.get(MONTH_OF_YEAR); + int day = date.get(DAY_OF_MONTH); + if (month == Month.FEBRUARY.getValue() && day == 17) + return Boolean.TRUE; + if (month == Month.SEPTEMBER.getValue() && day == 21) + return Boolean.TRUE; + if (month == Month.MAY.getValue() && day == 22) + return Boolean.TRUE; + return Boolean.FALSE; +} + + +然后，使用 query 方法查询是否匹配条件： + +System.out.println("//查询是否是今天要举办生日"); +System.out.println(LocalDate.now().query(CommonMistakesApplication::isFamilyBirthday)); + + +使用 Java 8 操作和计算日期时间虽然方便，但计算两个日期差时可能会踩坑：Java 8 中有一个专门的类 Period 定义了日期间隔，通过 Period.between 得到了两个 LocalDate 的差，返回的是两个日期差几年零几月零几天。如果希望得知两个日期之间差几天，直接调用 Period 的 getDays() 方法得到的只是最后的“零几天”，而不是算总的间隔天数。 + +比如，计算 2019 年 12 月 12 日和 2019 年 10 月 1 日的日期间隔，很明显日期差是 2 个月零 11 天，但获取 getDays 方法得到的结果只是 11 天，而不是 72 天： + +System.out.println("//计算日期差"); +LocalDate today = LocalDate.of(2019, 12, 12); +LocalDate specifyDate = LocalDate.of(2019, 10, 1); +System.out.println(Period.between(specifyDate, today).getDays()); +System.out.println(Period.between(specifyDate, today)); +System.out.println(ChronoUnit.DAYS.between(specifyDate, today)); + + +可以使用 ChronoUnit.DAYS.between 解决这个问题： + +//计算日期差 +11 +P2M11D +72 + + +从日期时间的时区到格式化再到计算，你是不是体会到 Java 8 日期时间类的强大了呢？ + +重点回顾 + +今天，我和你一起看了日期时间的初始化、时区、格式化、解析和计算的问题。我们看到，使用 Java 8 中的日期时间包 Java.time 的类进行各种操作，会比使用遗留的 Date、Calender 和 SimpleDateFormat 更简单、清晰，功能也更丰富、坑也比较少。 + +如果有条件的话，我还是建议全面改为使用 Java 8 的日期时间类型。我把 Java 8 前后的日期时间类型，汇总到了一张思维导图上，图中箭头代表的是新老类型在概念上等价的类型： + + + +这里有个误区是，认为 java.util.Date 类似于新 API 中的 LocalDateTime。其实不是，虽然它们都没有时区概念，但 java.util.Date 类是因为使用 UTC 表示，所以没有时区概念，其本质是时间戳；而 LocalDateTime，严格上可以认为是一个日期时间的表示，而不是一个时间点。 + +因此，在把 Date 转换为 LocalDateTime 的时候，需要通过 Date 的 toInstant 方法得到一个 UTC 时间戳进行转换，并需要提供当前的时区，这样才能把 UTC 时间转换为本地日期时间（的表示）。反过来，把 LocalDateTime 的时间表示转换为 Date 时，也需要提供时区，用于指定是哪个时区的时间表示，也就是先通过 atZone 方法把 LocalDateTime 转换为 ZonedDateTime，然后才能获得 UTC 时间戳： + +Date in = new Date(); +LocalDateTime ldt = LocalDateTime.ofInstant(in.toInstant(), ZoneId.systemDefault()); +Date out = Date.from(ldt.atZone(ZoneId.systemDefault()).toInstant()); + + +很多同学说使用新 API 很麻烦，还需要考虑时区的概念，一点都不简洁。但我通过这篇文章要和你说的是，并不是因为 API 需要设计得这么繁琐，而是 UTC 时间要变为当地时间，必须考虑时区。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +我今天多次强调 Date 是一个时间戳，是 UTC 时间、没有时区概念，为什么调用其 toString 方法会输出类似 CST 之类的时区字样呢？ + +日期时间数据始终要保存到数据库中，MySQL 中有两种数据类型 datetime 和 timestamp 可以用来保存日期时间。你能说说它们的区别吗，它们是否包含时区信息呢？ + +对于日期和时间，你还遇到过什么坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/17别以为“自动挡”就不可能出现OOM.md b/专栏/Java业务开发常见错误100例/17别以为“自动挡”就不可能出现OOM.md new file mode 100644 index 0000000..f83caf3 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/17别以为“自动挡”就不可能出现OOM.md @@ -0,0 +1,439 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 17 别以为“自动挡”就不可能出现OOM + 今天，我要和你分享的主题是，别以为“自动挡”就不可能出现 OOM。 + +这里的“自动挡”，是我对 Java 自动垃圾收集器的戏称。的确，经过这么多年的发展，Java 的垃圾收集器已经非常成熟了。有了自动垃圾收集器，绝大多数情况下我们写程序时可以专注于业务逻辑，无需过多考虑对象的分配和释放，一般也不会出现 OOM。 + +但，内存空间始终是有限的，Java 的几大内存区域始终都有 OOM 的可能。相应地，Java 程序的常见 OOM 类型，可以分为堆内存的 OOM、栈 OOM、元空间 OOM、直接内存 OOM 等。几乎每一种 OOM 都可以使用几行代码模拟，市面上也有很多资料在堆、元空间、直接内存中分配超大对象或是无限分配对象，尝试创建无限个线程或是进行方法无限递归调用来模拟。 + +但值得注意的是，我们的业务代码并不会这么干。所以今天，我会从内存分配意识的角度通过一些案例，展示业务代码中可能导致 OOM 的一些坑。这些坑，或是因为我们意识不到对象的分配，或是因为不合理的资源使用，或是没有控制缓存的数据量等。 + +在第 3 讲介绍线程时，我们已经看到了两种 OOM 的情况，一是因为使用无界队列导致的堆 OOM，二是因为使用没有最大线程数量限制的线程池导致无限创建线程的 OOM。接下来，我们再一起看看，在写业务代码的过程中，还有哪些意识上的疏忽可能会导致 OOM。 + +太多份相同的对象导致 OOM + +我要分享的第一个案例是这样的。有一个项目在内存中缓存了全量用户数据，在搜索用户时可以直接从缓存中返回用户信息。现在为了改善用户体验，需要实现输入部分用户名自动在下拉框提示补全用户名的功能（也就是所谓的自动完成功能）。 + +在第 10 讲介绍集合时，我提到对于这种快速检索的需求，最好使用 Map 来实现，会比直接从 List 搜索快得多。 + +为实现这个功能，我们需要一个 HashMap 来存放这些用户数据，Key 是用户姓名索引，Value 是索引下对应的用户列表。举一个例子，如果有两个用户 aa 和 ab，那么 Key 就有三个，分别是 a、aa 和 ab。用户输入字母 a 时，就能从 Value 这个 List 中拿到所有字母 a 开头的用户，即 aa 和 ab。 + +在代码中，在数据库中存入 1 万个测试用户，用户名由 a~j 这 6 个字母随机构成，然后把每一个用户名的前 1 个字母、前 2 个字母以此类推直到完整用户名作为 Key 存入缓存中，缓存的 Value 是一个 UserDTO 的 List，存放的是所有相同的用户名索引，以及对应的用户信息： + +//自动完成的索引，Key是用户输入的部分用户名，Value是对应的用户数据 +private ConcurrentHashMap> autoCompleteIndex = new ConcurrentHashMap<>(); + +@Autowired +private UserRepository userRepository; + +@PostConstruct +public void wrong() { + + //先保存10000个用户名随机的用户到数据库中 + userRepository.saveAll(LongStream.rangeClosed(1, 10000).mapToObj(i -> new UserEntity(i, randomName())).collect(Collectors.toList())); + + //从数据库加载所有用户 + userRepository.findAll().forEach(userEntity -> { + + int len = userEntity.getName().length(); + //对于每一个用户，对其用户名的前N位进行索引，N可能是1~6六种长度类型 + for (int i = 0; i < len; i++) { + String key = userEntity.getName().substring(0, i + 1); + autoCompleteIndex.computeIfAbsent(key, s -> new ArrayList<>()) + .add(new UserDTO(userEntity.getName())); + } + }); + log.info("autoCompleteIndex size:{} count:{}", autoCompleteIndex.size(), + autoCompleteIndex.entrySet().stream().map(item -> item.getValue().size()).reduce(0, Integer::sum)); +} + + +对于每一个用户对象 UserDTO，除了有用户名，我们还加入了 10K 左右的数据模拟其用户信息： + +@Data +public class UserDTO { + + private String name; + + @EqualsAndHashCode.Exclude + private String payload; + + public UserDTO(String name) { + this.name = name; + this.payload = IntStream.rangeClosed(1, 10_000) + .mapToObj(__ -> "a") + .collect(Collectors.joining("")); + } +} + + +运行程序后，日志输出如下： + +[11:11:22.982] [main] [INFO ] [.t.c.o.d.UsernameAutoCompleteService:37 ] - autoCompleteIndex size:26838 count:60000 + + +可以看到，一共有 26838 个索引（也就是所有用户名的 1 位、2 位一直到 6 位有 26838 个组合），HashMap 的 Value，也就是 List一共有 1 万个用户 *6=6 万个 UserDTO 对象。 + +使用内存分析工具 MAT 打开堆 dump 发现，6 万个 UserDTO 占用了约 1.2GB 的内存： + + + +看到这里发现，虽然真正的用户只有 1 万个，但因为使用部分用户名作为索引的 Key，导致缓存的 Key 有 26838 个，缓存的用户信息多达 6 万个。如果我们的用户名不是 6 位而是 10 位、20 位，那么缓存的用户信息可能就是 10 万、20 万个，必然会产生堆 OOM。 + +尝试调大用户名的最大长度，重启程序可以看到类似如下的错误： + +[17:30:29.858] [main] [ERROR] [ringframework.boot.SpringApplication:826 ] - Application run failed +org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'usernameAutoCompleteService': Invocation of init method failed; nested exception is java.lang.OutOfMemoryError: Java heap space + + +我们可能会想当然地认为，数据库中有 1 万个用户，内存中也应该只有 1 万个 UserDTO 对象，但实现的时候每次都会 new 出来 UserDTO 加入缓存，当然在内存中都是新对象。在实际的项目中，用户信息的缓存可能是随着用户输入增量缓存的，而不是像这个案例一样在程序初始化的时候全量缓存，所以问题暴露得不会这么早。 + +知道原因后，解决起来就比较简单了。把所有 UserDTO 先加入 HashSet 中，因为 UserDTO 以 name 来标识唯一性，所以重复用户名会被过滤掉，最终加入 HashSet 的 UserDTO 就不足 1 万个。 + +有了 HashSet 来缓存所有可能的 UserDTO 信息，我们再构建自动完成索引 autoCompleteIndex 这个 HashMap 时，就可以直接从 HashSet 获取所有用户信息来构建了。这样一来，同一个用户名前缀的不同组合（比如用户名为 abc 的用户，a、ab 和 abc 三个 Key）关联到 UserDTO 是同一份： + +@PostConstruct +public void right() { + ... + HashSet cache = userRepository.findAll().stream() + .map(item -> new UserDTO(item.getName())) + .collect(Collectors.toCollection(HashSet::new)); + cache.stream().forEach(userDTO -> { + int len = userDTO.getName().length(); + for (int i = 0; i < len; i++) { + String key = userDTO.getName().substring(0, i + 1); + autoCompleteIndex.computeIfAbsent(key, s -> new ArrayList<>()) + .add(userDTO); + } + }); + ... +} + + +再次分析堆内存，可以看到 UserDTO 只有 9945 份，总共占用的内存不到 200M。这才是我们真正想要的结果。 + + + +修复后的程序，不仅相同的 UserDTO 只有一份，总副本数变为了原来的六分之一；而且因为 HashSet 的去重特性，双重节约了内存。 + +值得注意的是，我们虽然清楚数据总量，但却忽略了每一份数据在内存中可能有多份。我之前还遇到一个案例，一个后台程序需要从数据库加载大量信息用于数据导出，这些数据在数据库中占用 100M 内存，但是 1GB 的 JVM 堆却无法完成导出操作。 + +我来和你分析下原因吧。100M 的数据加载到程序内存中，变为 Java 的数据结构就已经占用了 200M 堆内存；这些数据经过 JDBC、MyBatis 等框架其实是加载了 2 份，然后领域模型、DTO 再进行转换可能又加载了 2 次；最终，占用的内存达到了 200M*4=800M。 + +所以，在进行容量评估时，我们不能认为一份数据在程序内存中也是一份。 + +使用 WeakHashMap 不等于不会 OOM + +对于上一节实现快速检索的案例，为了防止缓存中堆积大量数据导致 OOM，一些同学可能会想到使用 WeakHashMap 作为缓存容器。 + +WeakHashMap 的特点是 Key 在哈希表内部是弱引用的，当没有强引用指向这个 Key 之后，Entry 会被 GC，即使我们无限往 WeakHashMap 加入数据，只要 Key 不再使用，也就不会 OOM。 + +说到了强引用和弱引用，我先和你回顾下 Java 中引用类型和垃圾回收的关系： + +垃圾回收器不会回收有强引用的对象； + +在内存充足时，垃圾回收器不会回收具有软引用的对象； + +垃圾回收器只要扫描到了具有弱引用的对象就会回收，WeakHashMap 就是利用了这个特点。 + +不过，我要和你分享的第二个案例，恰巧就是不久前我遇到的一个使用 WeakHashMap 却最终 OOM 的案例。我们暂且不论使用 WeakHashMap 作为缓存是否合适，先分析一下这个 OOM 问题。 + +声明一个 Key 是 User 类型、Value 是 UserProfile 类型的 WeakHashMap，作为用户数据缓存，往其中添加 200 万个 Entry，然后使用 ScheduledThreadPoolExecutor 发起一个定时任务，每隔 1 秒输出缓存中的 Entry 个数： + +private Map cache = new WeakHashMap<>(); + +@GetMapping("wrong") +public void wrong() { + + String userName = "zhuye"; + + //间隔1秒定时输出缓存中的条目数 + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate( + () -> log.info("cache size:{}", cache.size()), 1, 1, TimeUnit.SECONDS); + + LongStream.rangeClosed(1, 2000000).forEach(i -> { + User user = new User(userName + i); + cache.put(user, new UserProfile(user, "location" + i)); + }); +} + + +执行程序后日志如下： + +[10:30:28.509] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:29 ] - cache size:2000000 +[10:30:29.507] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:29 ] - cache size:2000000 +[10:30:30.509] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:29 ] - cache size:2000000 + + +可以看到，输出的 cache size 始终是 200 万，即使我们通过 jvisualvm 进行手动 GC 还是这样。这就说明，这些 Entry 无法通过 GC 回收。如果你把 200 万改为 1000 万，就可以在日志中看到如下的 OOM 错误： + +Exception in thread "http-nio-45678-exec-1" java.lang.OutOfMemoryError: GC overhead limit exceeded +Exception in thread "Catalina-utility-2" java.lang.OutOfMemoryError: GC overhead limit exceeded + + +我们来分析一下这个问题。进行堆转储后可以看到，堆内存中有 200 万个 UserProfie 和 User： + + + +如下是 User 和 UserProfile 类的定义，需要注意的是，WeakHashMap 的 Key 是 User 对象，而其 Value 是 UserProfile 对象，持有了 User 的引用： + +@Data +@AllArgsConstructor +@NoArgsConstructor +class User { + + private String name; +} + +@Data +@AllArgsConstructor +@NoArgsConstructor +public class UserProfile { + + private User user; + + private String location; + +} + + +没错，这就是问题的所在。分析一下 WeakHashMap 的源码，你会发现 WeakHashMap 和 HashMap 的最大区别，是 Entry 对象的实现。接下来，我们暂且忽略 HashMap 的实现，来看下 Entry 对象： + +private static class Entry extends WeakReference ... + +/** + * Creates new entry. + */ +Entry(Object key, V value, + + ReferenceQueue queue, + + int hash, Entry next) { + super(key, queue); + this.value = value; + this.hash = hash; + this.next = next; +} + + +Entry 对象继承了 WeakReference，Entry 的构造函数调用了 super (key,queue)，这是父类的构造函数。其中，key 是我们执行 put 方法时的 key；queue 是一个 ReferenceQueue。如果你了解 Java 的引用就会知道，被 GC 的对象会被丢进这个 queue 里面。 + +再来看看对象被丢进 queue 后是如何被销毁的： + +public V get(Object key) { + + Object k = maskNull(key); + + int h = hash(k); + + Entry[] tab = getTable(); + + int index = indexFor(h, tab.length); + + Entry e = tab[index]; + + while (e != null) { + if (e.hash == h && eq(k, e.get())) + return e.value; + e = e.next; + } + return null; +} + +private Entry[] getTable() { + expungeStaleEntries(); + return table; +} + +/** + * Expunges stale entries from the table. + */ +private void expungeStaleEntries() { + + for (Object x; (x = queue.poll()) != null; ) { + + synchronized (queue) { + @SuppressWarnings("unchecked") + Entry e = (Entry) x; + int i = indexFor(e.hash, table.length); + + Entry prev = table[i]; + + Entry p = prev; + + while (p != null) { + Entry next = p.next; + if (p == e) { + if (prev == e) + table[i] = next; + else + prev.next = next; + // Must not null out e.next; + // stale entries may be in use by a HashIterator + e.value = null; // Help GC + size--; + break; + } + prev = p; + p = next; + } + } + } +} + + +从源码中可以看到，每次调用 get、put、size 等方法时，都会从 queue 里拿出所有已经被 GC 掉的 key 并删除对应的 Entry 对象。我们再来回顾下这个逻辑： + +put 一个对象进 Map 时，它的 key 会被封装成弱引用对象； + +发生 GC 时，弱引用的 key 被发现并放入 queue； + +调用 get 等方法时，扫描 queue 删除 key，以及包含 key 和 value 的 Entry 对象。 + +WeakHashMap 的 Key 虽然是弱引用，但是其 Value 却持有 Key 中对象的强引用，Value 被 Entry 引用，Entry 被 WeakHashMap 引用，最终导致 Key 无法回收。解决方案就是让 Value 变为弱引用，使用 WeakReference 来包装 UserProfile 即可： + +private Map> cache2 = new WeakHashMap<>(); + +@GetMapping("right") +public void right() { + + String userName = "zhuye"; + + //间隔1秒定时输出缓存中的条目数 + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate( + () -> log.info("cache size:{}", cache2.size()), 1, 1, TimeUnit.SECONDS); + LongStream.rangeClosed(1, 2000000).forEach(i -> { + User user = new User(userName + i); + //这次，我们使用弱引用来包装UserProfile + cache2.put(user, new WeakReference(new UserProfile(user, "location" + i))); + }); +} + + +重新运行程序，从日志中观察到 cache size 不再是固定的 200 万，而是在不断减少，甚至在手动 GC 后所有的 Entry 都被回收了： + +[10:40:05.792] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:40 ] - cache size:1367402 +[10:40:05.795] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:40 ] - cache size:1367846 +[10:40:06.773] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:40 ] - cache size:549551 +... +[10:40:20.742] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:40 ] - cache size:549551 +[10:40:22.862] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:40 ] - cache size:547937 +[10:40:22.865] [pool-3-thread-1] [INFO ] [t.c.o.demo3.WeakHashMapOOMController:40 ] - cache size:542134 +[10:40:23.779] [pool-3-thread-1] [INFO ] +//手动进行GC +[t.c.o.demo3.WeakHashMapOOMController:40 ] - cache size:0 + + +当然，还有一种办法就是，让 Value 也就是 UserProfile 不再引用 Key，而是重新 new 出一个新的 User 对象赋值给 UserProfile： + +@GetMapping("right2") +public void right2() { + + String userName = "zhuye"; + ... + User user = new User(userName + i); + cache.put(user, new UserProfile(new User(user.getName()), "location" + i)); +} + + +此外，Spring 提供的ConcurrentReferenceHashMap类可以使用弱引用、软引用做缓存，Key 和 Value 同时被软引用或弱引用包装，也能解决相互引用导致的数据不能释放问题。与 WeakHashMap 相比，ConcurrentReferenceHashMap 不但性能更好，还可以确保线程安全。你可以自己做实验测试下。 + +Tomcat 参数配置不合理导致 OOM + +我们再来看看第三个案例。有一次运维同学反馈，有个应用在业务量大的情况下会出现假死，日志中也有大量 OOM 异常： + +[13:18:17.597] [http-nio-45678-exec-70] [ERROR] [ache.coyote.http11.Http11NioProtocol:175 ] - Failed to complete processing of a request +java.lang.OutOfMemoryError: Java heap space + + +于是，我让运维同学进行生产堆 Dump。通过 MAT 打开 dump 文件后，我们一眼就看到 OOM 的原因是，有接近 1.7GB 的 byte 数组分配，而 JVM 进程的最大堆内存我们只配置了 2GB： + + + +通过查看引用可以发现，大量引用都是 Tomcat 的工作线程。大部分工作线程都分配了两个 10M 左右的数组，100 个左右工作线程吃满了内存。第一个红框是 Http11InputBuffer，其 buffer 大小是 10008192 字节；而第二个红框的 Http11OutputBuffer 的 buffer，正好占用 10000000 字节： + + + +我们先来看看第一个 Http11InputBuffer 为什么会占用这么多内存。查看 Http11InputBuffer 类的 init 方法注意到，其中一个初始化方法会分配 headerBufferSize+readBuffer 大小的内存： + +void init(SocketWrapperBase socketWrapper) { + + wrapper = socketWrapper; + wrapper.setAppReadBufHandler(this); + int bufLength = headerBufferSize + + wrapper.getSocketBufferHandler().getReadBuffer().capacity(); + if (byteBuffer == null || byteBuffer.capacity() < bufLength) { + byteBuffer = ByteBuffer.allocate(bufLength); + byteBuffer.position(0).limit(0); + } +} + + +在Tomcat 文档中有提到，这个 Socket 的读缓冲，也就是 readBuffer 默认是 8192 字节。显然，问题出在了 headerBufferSize 上： + + + +向上追溯初始化 Http11InputBuffer 的 Http11Processor 类，可以看到，传入的 headerBufferSize 配置的是 MaxHttpHeaderSize： + + inputBuffer = new Http11InputBuffer(request, protocol.getMaxHttpHeaderSize(), + protocol.getRejectIllegalHeaderName(), httpParser); + + +Http11OutputBuffer 中的 buffer 正好占用了 10000000 字节，这又是为什么？通过 Http11OutputBuffer 的构造方法，可以看到它是直接根据 headerBufferSize 分配了固定大小的 headerBuffer： + +protected Http11OutputBuffer(Response response, int headerBufferSize){ +... + headerBuffer = ByteBuffer.allocate(headerBufferSize); +} + + +那么我们就可以想到，一定是应用把 Tomcat 头相关的参数配置为 10000000 了，使得每一个请求对于 Request 和 Response 都占用了 20M 内存，最终在并发较多的情况下引起了 OOM。 + +果不其然，查看项目代码发现配置文件中有这样的配置项： + +server.max-http-header-size=10000000 + + +翻看源码提交记录可以看到，当时开发同学遇到了这样的异常： + +java.lang.IllegalArgumentException: Request header is too large + + +于是他就到网上搜索了一下解决方案，随意将 server.max-http-header-size 修改为了一个超大值，期望永远不会再出现类似问题。但，没想到这个修改却引起了这么大的问题。把这个参数改为比较合适的 20000 再进行压测，我们就可以发现应用的各项指标都比较稳定。 + +这个案例告诉我们，一定要根据实际需求来修改参数配置，可以考虑预留 2 到 5 倍的量。容量类的参数背后往往代表了资源，设置超大的参数就有可能占用不必要的资源，在并发量大的时候因为资源大量分配导致 OOM。 + +重点回顾 + +今天，我从内存分配意识的角度和你分享了 OOM 的问题。通常而言，Java 程序的 OOM 有如下几种可能。 + +一是，我们的程序确实需要超出 JVM 配置的内存上限的内存。不管是程序实现的不合理，还是因为各种框架对数据的重复处理、加工和转换，相同的数据在内存中不一定只占用一份空间。针对内存量使用超大的业务逻辑，比如缓存逻辑、文件上传下载和导出逻辑，我们在做容量评估时，可能还需要实际做一下 Dump，而不是进行简单的假设。 + +二是，出现内存泄露，其实就是我们认为没有用的对象最终会被 GC，但却没有。GC 并不会回收强引用对象，我们可能经常在程序中定义一些容器作为缓存，但如果容器中的数据无限增长，要特别小心最终会导致 OOM。使用 WeakHashMap 是解决这个问题的好办法，但值得注意的是，如果强引用的 Value 有引用 Key，也无法回收 Entry。 + +三是，不合理的资源需求配置，在业务量小的时候可能不会出现问题，但业务量一大可能很快就会撑爆内存。比如，随意配置 Tomcat 的 max-http-header-size 参数，会导致一个请求使用过多的内存，请求量大的时候出现 OOM。在进行参数配置的时候，我们要认识到，很多限制类参数限制的是背后资源的使用，资源始终是有限的，需要根据实际需求来合理设置参数。 + +最后我想说的是，在出现 OOM 之后，也不用过于紧张。我们可以根据错误日志中的异常信息，再结合 jstat 等命令行工具观察内存使用情况，以及程序的 GC 日志，来大致定位出现 OOM 的内存区块和类型。其实，我们遇到的 90% 的 OOM 都是堆 OOM，对 JVM 进程进行堆内存 Dump，或使用 jmap 命令分析对象内存占用排行，一般都可以很容易定位到问题。 + +这里，我建议你为生产系统的程序配置 JVM 参数启用详细的 GC 日志，方便观察垃圾收集器的行为，并开启 HeapDumpOnOutOfMemoryError，以便在出现 OOM 时能自动 Dump 留下第一问题现场。对于 JDK8，你可以这么设置： + +XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=. -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M + + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +Spring 的 ConcurrentReferenceHashMap，针对 Key 和 Value 支持软引用和弱引用两种方式。你觉得哪种方式更适合做缓存呢？ + +当我们需要动态执行一些表达式时，可以使用 Groovy 动态语言实现：new 出一个 GroovyShell 类，然后调用 evaluate 方法动态执行脚本。这种方式的问题是，会重复产生大量的类，增加 Metaspace 区的 GC 负担，有可能会引起 OOM。你知道如何避免这个问题吗？ + +针对 OOM 或内存泄露，你还遇到过什么案例吗？我是朱晔，欢迎在评论区与我留言分享，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/18当反射、注解和泛型遇到OOP时，会有哪些坑？.md b/专栏/Java业务开发常见错误100例/18当反射、注解和泛型遇到OOP时，会有哪些坑？.md new file mode 100644 index 0000000..bf97db9 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/18当反射、注解和泛型遇到OOP时，会有哪些坑？.md @@ -0,0 +1,420 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 18 当反射、注解和泛型遇到OOP时，会有哪些坑？ + 今天，我们聊聊 Java 高级特性的话题，看看反射、注解和泛型遇到重载和继承时可能会产生的坑。 + +你可能说，业务项目中几乎都是增删改查，用到反射、注解和泛型这些高级特性的机会少之又少，没啥好学的。但我要说的是，只有学好、用好这些高级特性，才能开发出更简洁易读的代码，而且几乎所有的框架都使用了这三大高级特性。比如，要减少重复代码，就得用到反射和注解（详见第 21 讲）。 + +如果你从来没用过反射、注解和泛型，可以先通过官网有一个大概了解： + +Java Reflection API & Reflection Tutorials； + +Annotations & Lesson: Annotations； + +Generics & Lesson: Generics。 + +接下来，我们就通过几个案例，看看这三大特性结合 OOP 使用时会有哪些坑吧。 + +反射调用方法不是以传参决定重载 + +反射的功能包括，在运行时动态获取类和类成员定义，以及动态读取属性调用方法。也就是说，针对类动态调用方法，不管类中字段和方法怎么变动，我们都可以用相同的规则来读取信息和执行方法。因此，几乎所有的 ORM（对象关系映射）、对象映射、MVC 框架都使用了反射。 + +反射的起点是 Class 类，Class 类提供了各种方法帮我们查询它的信息。你可以通过这个文档，了解每一个方法的作用。 + +接下来，我们先看一个反射调用方法遇到重载的坑：有两个叫 age 的方法，入参分别是基本类型 int 和包装类型 Integer。 + +@Slf4j +public class ReflectionIssueApplication { + private void age(int age) { + log.info("int age = {}", age); + } + + private void age(Integer age) { + log.info("Integer age = {}", age); + } +} + + +如果不通过反射调用，走哪个重载方法很清晰，比如传入 36 走 int 参数的重载方法，传入 Integer.valueOf(“36”) 走 Integer 重载： + +ReflectionIssueApplication application = new ReflectionIssueApplication(); +application.age(36); +application.age(Integer.valueOf("36")); + + +但使用反射时的误区是，认为反射调用方法还是根据入参确定方法重载。比如，使用 getDeclaredMethod 来获取 age 方法，然后传入 Integer.valueOf(“36”)： + +getClass().getDeclaredMethod("age", Integer.TYPE).invoke(this, Integer.valueOf("36")); + + +输出的日志证明，走的是 int 重载方法： + +14:23:09.801 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo1.ReflectionIssueApplication - int age = 36 + + +其实，要通过反射进行方法调用，第一步就是通过方法签名来确定方法。具体到这个案例，getDeclaredMethod 传入的参数类型 Integer.TYPE 代表的是 int，所以实际执行方法时无论传的是包装类型还是基本类型，都会调用 int 入参的 age 方法。 + +把 Integer.TYPE 改为 Integer.class，执行的参数类型就是包装类型的 Integer。这时，无论传入的是 Integer.valueOf(“36”) 还是基本类型的 36： + +getClass().getDeclaredMethod("age", Integer.class).invoke(this, Integer.valueOf("36")); +getClass().getDeclaredMethod("age", Integer.class).invoke(this, 36); + + +都会调用 Integer 为入参的 age 方法： + +14:25:18.028 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo1.ReflectionIssueApplication - Integer age = 36 +14:25:18.029 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo1.ReflectionIssueApplication - Integer age = 36 + + +现在我们非常清楚了，反射调用方法，是以反射获取方法时传入的方法名称和参数类型来确定调用方法的。接下来，我们再来看一下反射、泛型擦除和继承结合在一起会碰撞出什么坑。 + +泛型经过类型擦除多出桥接方法的坑 + +泛型是一种风格或范式，一般用于强类型程序设计语言，允许开发者使用类型参数替代明确的类型，实例化时再指明具体的类型。它是代码重用的有效手段，允许把一套代码应用到多种数据类型上，避免针对每一种数据类型实现重复的代码。 + +Java 编译器对泛型应用了强大的类型检测，如果代码违反了类型安全就会报错，可以在编译时暴露大多数泛型的编码错误。但总有一部分编码错误，比如泛型类型擦除的坑，在运行时才会暴露。接下来，我就和你分享一个案例吧。 + +有一个项目希望在类字段内容变动时记录日志，于是开发同学就想到定义一个泛型父类，并在父类中定义一个统一的日志记录方法，子类可以通过继承重用这个方法。代码上线后业务没啥问题，但总是出现日志重复记录的问题。开始时，我们怀疑是日志框架的问题，排查到最后才发现是泛型的问题，反复修改多次才解决了这个问题。 + +父类是这样的：有一个泛型占位符 T；有一个 AtomicInteger 计数器，用来记录 value 字段更新的次数，其中 value 字段是泛型 T 类型的，setValue 方法每次为 value 赋值时对计数器进行 +1 操作。我重写了 toString 方法，输出 value 字段的值和计数器的值： + +class Parent { + + //用于记录value更新的次数，模拟日志记录的逻辑 + AtomicInteger updateCount = new AtomicInteger(); + + private T value; + + //重写toString，输出值和值更新次数 + @Override + public String toString() { + return String.format("value: %s updateCount: %d", value, updateCount.get()); + } + + //设置值 + public void setValue(T value) { + this.value = value; + updateCount.incrementAndGet(); + } +} + + +子类 Child1 的实现是这样的：继承父类，但没有提供父类泛型参数；定义了一个参数为 String 的 setValue 方法，通过 super.setValue 调用父类方法实现日志记录。我们也能明白，开发同学这么设计是希望覆盖父类的 setValue 实现： + +class Child1 extends Parent { + public void setValue(String value) { + System.out.println("Child1.setValue called"); + super.setValue(value); + } +} + + +在实现的时候，子类方法的调用是通过反射进行的。实例化 Child1 类型后，通过 getClass().getMethods 方法获得所有的方法；然后按照方法名过滤出 setValue 方法进行调用，传入字符串 test 作为参数： + +Child1 child1 = new Child1(); + +Arrays.stream(child1.getClass().getMethods()) + .filter(method -> method.getName().equals("setValue")) + .forEach(method -> { + try { + method.invoke(child1, "test"); + } catch (Exception e) { + e.printStackTrace(); + } + }); +System.out.println(child1.toString()); + + +运行代码后可以看到，虽然 Parent 的 value 字段正确设置了 test，但父类的 setValue 方法调用了两次，计数器也显示 2 而不是 1： + +Child1.setValue called +Parent.setValue called +Parent.setValue called +value: test updateCount: 2 + + +显然，两次 Parent 的 setValue 方法调用，是因为 getMethods 方法找到了两个名为 setValue 的方法，分别是父类和子类的 setValue 方法。 + +这个案例中，子类方法重写父类方法失败的原因，包括两方面： + +一是，子类没有指定 String 泛型参数，父类的泛型方法 setValue(T value) 在泛型擦除后是 setValue(Object value)，子类中入参是 String 的 setValue 方法被当作了新方法； + +二是，子类的 setValue 方法没有增加 @Override 注解，因此编译器没能检测到重写失败的问题。这就说明，重写子类方法时，标记 @Override 是一个好习惯。 + +但是，开发同学认为问题出在反射 API 使用不当，却没意识到重写失败。他查文档后发现，getMethods 方法能获得当前类和父类的所有 public 方法，而 getDeclaredMethods 只能获得当前类所有的 public、protected、package 和 private 方法。 + +于是，他就用 getDeclaredMethods 替代了 getMethods： + +Arrays.stream(child1.getClass().getDeclaredMethods()) + .filter(method -> method.getName().equals("setValue")) + .forEach(method -> { + try { + method.invoke(child1, "test"); + } catch (Exception e) { + e.printStackTrace(); + } + }); + + +这样虽然能解决重复记录日志的问题，但没有解决子类方法重写父类方法失败的问题，得到如下输出： + +Child1.setValue called +Parent.setValue called +value: test updateCount: 1 + + +其实这治标不治本，其他人使用 Child1 时还是会发现有两个 setValue 方法，非常容易让人困惑。 + +幸好，架构师在修复上线前发现了这个问题，让开发同学重新实现了 Child2，继承 Parent 的时候提供了 String 作为泛型 T 类型，并使用 @Override 关键字注释了 setValue 方法，实现了真正有效的方法重写： + +class Child2 extends Parent { + + @Override + public void setValue(String value) { + System.out.println("Child2.setValue called"); + super.setValue(value); + } +} + + +但很可惜，修复代码上线后，还是出现了日志重复记录： + +Child2.setValue called +Parent.setValue called +Child2.setValue called +Parent.setValue called +value: test updateCount: 2 + + +可以看到，这次是 Child2 类的 setValue 方法被调用了两次。开发同学惊讶地说，肯定是反射出 Bug 了，通过 getDeclaredMethods 查找到的方法一定是来自 Child2 类本身；而且，怎么看 Child2 类中也只有一个 setValue 方法，为什么还会重复呢？ + +调试一下可以发现，Child2 类其实有 2 个 setValue 方法，入参分别是 String 和 Object。 + + + +如果不通过反射来调用方法，我们确实很难发现这个问题。其实，这就是泛型类型擦除导致的问题。我们来分析一下。 + +我们知道，Java 的泛型类型在编译后擦除为 Object。虽然子类指定了父类泛型 T 类型是 String，但编译后 T 会被擦除成为 Object，所以父类 setValue 方法的入参是 Object，value 也是 Object。如果子类 Child2 的 setValue 方法要覆盖父类的 setValue 方法，那入参也必须是 Object。所以，编译器会为我们生成一个所谓的 bridge 桥接方法，你可以使用 javap 命令来反编译编译后的 Child2 类的 class 字节码： + +javap -c /Users/zhuye/Documents/common-mistakes/target/classes/org/geekbang/time/commonmistakes/advancedfeatures/demo3/Child2.class +Compiled from "GenericAndInheritanceApplication.java" +class org.geekbang.time.commonmistakes.advancedfeatures.demo3.Child2 extends org.geekbang.time.commonmistakes.advancedfeatures.demo3.Parent { + org.geekbang.time.commonmistakes.advancedfeatures.demo3.Child2(); + Code: + 0: aload_0 + 1: invokespecial #1 // Method org/geekbang/time/commonmistakes/advancedfeatures/demo3/Parent."":()V + 4: return + public void setValue(java.lang.String); + Code: + 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; + 3: ldc #3 // String Child2.setValue called + 5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V + 8: aload_0 + 9: aload_1 + 10: invokespecial #5 // Method org/geekbang/time/commonmistakes/advancedfeatures/demo3/Parent.setValue:(Ljava/lang/Object;)V + 13: return + + public void setValue(java.lang.Object); + Code: + 0: aload_0 + 1: aload_1 + 2: checkcast #6 // class java/lang/String + 5: invokevirtual #7 // Method setValue:(Ljava/lang/String;)V + 8: return +} + + +可以看到，入参为 Object 的 setValue 方法在内部调用了入参为 String 的 setValue 方法（第 27 行），也就是代码里实现的那个方法。如果编译器没有帮我们实现这个桥接方法，那么 Child2 子类重写的是父类经过泛型类型擦除后、入参是 Object 的 setValue 方法。这两个方法的参数，一个是 String 一个是 Object，明显不符合 Java 的语义： + +class Parent { + + AtomicInteger updateCount = new AtomicInteger(); + private Object value; + + public void setValue(Object value) { + System.out.println("Parent.setValue called"); + this.value = value; + updateCount.incrementAndGet(); + } +} + +class Child2 extends Parent { + + @Override + public void setValue(String value) { + System.out.println("Child2.setValue called"); + super.setValue(value); + } +} + + +使用 jclasslib 工具打开 Child2 类，同样可以看到入参为 Object 的桥接方法上标记了 public + synthetic + bridge 三个属性。synthetic 代表由编译器生成的不可见代码，bridge 代表这是泛型类型擦除后生成的桥接代码： + + + +知道这个问题之后，修改方式就明朗了，可以使用 method 的 isBridge 方法，来判断方法是不是桥接方法： + +通过 getDeclaredMethods 方法获取到所有方法后，必须同时根据方法名 setValue 和非 isBridge 两个条件过滤，才能实现唯一过滤； + +使用 Stream 时，如果希望只匹配 0 或 1 项的话，可以考虑配合 ifPresent 来使用 findFirst 方法。 + +修复代码如下： + +Arrays.stream(child2.getClass().getDeclaredMethods()) + .filter(method -> method.getName().equals("setValue") && !method.isBridge()) + .findFirst().ifPresent(method -> { + try { + method.invoke(chi2, "test"); + } catch (Exception e) { + e.printStackTrace(); + } +}); + + +这样就可以得到正确输出了： + +Child2.setValue called +Parent.setValue called +value: test updateCount: 1 + + +最后小结下，使用反射查询类方法清单时，我们要注意两点： + +getMethods 和 getDeclaredMethods 是有区别的，前者可以查询到父类方法，后者只能查询到当前类。 + +反射进行方法调用要注意过滤桥接方法。 + +注解可以继承吗？ + +注解可以为 Java 代码提供元数据，各种框架也都会利用注解来暴露功能，比如 Spring 框架中的 @Service、@Controller、@Bean 注解，Spring Boot 的 @SpringBootApplication 注解。 + +框架可以通过类或方法等元素上标记的注解，来了解它们的功能或特性，并以此来启用或执行相应的功能。通过注解而不是 API 调用来配置框架，属于声明式交互，可以简化框架的配置工作，也可以和框架解耦。 + +开发同学可能会认为，类继承后，类的注解也可以继承，子类重写父类方法后，父类方法上的注解也能作用于子类，但这些观点其实是错误或者说是不全面的。我们来验证下吧。 + +首先，定义一个包含 value 属性的 MyAnnotation 注解，可以标记在方法或类上： + +@Target({ElementType.METHOD, ElementType.TYPE}) +@Retention(RetentionPolicy.RUNTIME) +public @interface MyAnnotation { + String value(); +} + + +然后，定义一个标记了 @MyAnnotation 注解的父类 Parent，设置 value 为 Class 字符串；同时这个类的 foo 方法也标记了 @MyAnnotation 注解，设置 value 为 Method 字符串。接下来，定义一个子类 Child 继承 Parent 父类，并重写父类的 foo 方法，子类的 foo 方法和类上都没有 @MyAnnotation 注解。 + +@MyAnnotation(value = "Class") +@Slf4j +static class Parent { + + @MyAnnotation(value = "Method") + public void foo() { + } +} + +@Slf4j +static class Child extends Parent { + + @Override + public void foo() { + } +} + + +再接下来，通过反射分别获取 Parent 和 Child 的类和方法的注解信息，并输出注解的 value 属性的值（如果注解不存在则输出空字符串）： + +private static String getAnnotationValue(MyAnnotation annotation) { + if (annotation == null) return ""; + return annotation.value(); +} + +public static void wrong() throws NoSuchMethodException { + + //获取父类的类和方法上的注解 + Parent parent = new Parent(); + log.info("ParentClass:{}", getAnnotationValue(parent.getClass().getAnnotation(MyAnnotation.class))); + log.info("ParentMethod:{}", getAnnotationValue(parent.getClass().getMethod("foo").getAnnotation(MyAnnotation.class))); + //获取子类的类和方法上的注解 + Child child = new Child(); + log.info("ChildClass:{}", getAnnotationValue(child.getClass().getAnnotation(MyAnnotation.class))); + log.info("ChildMethod:{}", getAnnotationValue(child.getClass().getMethod("foo").getAnnotation(MyAnnotation.class))); +} + + +输出如下： + +17:34:25.495 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ParentClass:Class +17:34:25.501 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ParentMethod:Method +17:34:25.504 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ChildClass: +17:34:25.504 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ChildMethod: + + +可以看到，父类的类和方法上的注解都可以正确获得，但是子类的类和方法却不能。这说明，子类以及子类的方法，无法自动继承父类和父类方法上的注解。 + +如果你详细了解过注解应该知道，在注解上标记 @Inherited 元注解可以实现注解的继承。那么，把 @MyAnnotation 注解标记了 @Inherited，就可以一键解决问题了吗？ + +@Target({ElementType.METHOD, ElementType.TYPE}) +@Retention(RetentionPolicy.RUNTIME) +@Inherited +public @interface MyAnnotation { + String value(); +} + + +重新运行代码输出如下： + +17:44:54.831 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ParentClass:Class +17:44:54.837 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ParentMethod:Method +17:44:54.838 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ChildClass:Class +17:44:54.838 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ChildMethod: + + +可以看到，子类可以获得父类上的注解；子类 foo 方法虽然是重写父类方法，并且注解本身也支持继承，但还是无法获得方法上的注解。 + +如果你再仔细阅读一下@Inherited 的文档就会发现，@Inherited 只能实现类上的注解继承。要想实现方法上注解的继承，你可以通过反射在继承链上找到方法上的注解。但，这样实现起来很繁琐，而且需要考虑桥接方法。 + +好在 Spring 提供了 AnnotatedElementUtils 类，来方便我们处理注解的继承问题。这个类的 findMergedAnnotation 工具方法，可以帮助我们找出父类和接口、父类方法和接口方法上的注解，并可以处理桥接方法，实现一键找到继承链的注解： + +Child child = new Child(); +log.info("ChildClass:{}", getAnnotationValue(AnnotatedElementUtils.findMergedAnnotation(child.getClass(), MyAnnotation.class))); +log.info("ChildMethod:{}", getAnnotationValue(AnnotatedElementUtils.findMergedAnnotation(child.getClass().getMethod("foo"), MyAnnotation.class))); + + +修改后，可以得到如下输出： + +17:47:30.058 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ChildClass:Class +17:47:30.059 [main] INFO org.geekbang.time.commonmistakes.advancedfeatures.demo2.AnnotationInheritanceApplication - ChildMethod:Method + + +可以看到，子类 foo 方法也获得了父类方法上的注解。 + +重点回顾 + +今天，我和你分享了使用 Java 反射、注解和泛型高级特性配合 OOP 时，可能会遇到的一些坑。 + +第一，反射调用方法并不是通过调用时的传参确定方法重载，而是在获取方法的时候通过方法名和参数类型来确定的。遇到方法有包装类型和基本类型重载的时候，你需要特别注意这一点。 + +第二，反射获取类成员，需要注意 getXXX 和 getDeclaredXXX 方法的区别，其中 XXX 包括 Methods、Fields、Constructors、Annotations。这两类方法，针对不同的成员类型 XXX 和对象，在实现上都有一些细节差异，详情请查看官方文档。今天提到的 getDeclaredMethods 方法无法获得父类定义的方法，而 getMethods 方法可以，只是差异之一，不能适用于所有的 XXX。 + +第三，泛型因为类型擦除会导致泛型方法 T 占位符被替换为 Object，子类如果使用具体类型覆盖父类实现，编译器会生成桥接方法。这样既满足子类方法重写父类方法的定义，又满足子类实现的方法有具体的类型。使用反射来获取方法清单时，你需要特别注意这一点。 + +第四，自定义注解可以通过标记元注解 @Inherited 实现注解的继承，不过这只适用于类。如果要继承定义在接口或方法上的注解，可以使用 Spring 的工具类 AnnotatedElementUtils，并注意各种 getXXX 方法和 findXXX 方法的区别，详情查看Spring 的文档。 + +最后，我要说的是。编译后的代码和原始代码并不完全一致，编译器可能会做一些优化，加上还有诸如 AspectJ 等编译时增强框架，使用反射动态获取类型的元数据可能会和我们编写的源码有差异，这点需要特别注意。你可以在反射中多写断言，遇到非预期的情况直接抛异常，避免通过反射实现的业务逻辑不符合预期。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +泛型类型擦除后会生成一个 bridge 方法，这个方法同时又是 synthetic 方法。除了泛型类型擦除，你知道还有什么情况编译器会生成 synthetic 方法吗？ + +关于注解继承问题，你觉得 Spring 的常用注解 @Service、@Controller 是否支持继承呢？ + +你还遇到过与 Java 高级特性相关的其他坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/19Spring框架：IoC和AOP是扩展的核心.md b/专栏/Java业务开发常见错误100例/19Spring框架：IoC和AOP是扩展的核心.md new file mode 100644 index 0000000..a9cc8dd --- /dev/null +++ b/专栏/Java业务开发常见错误100例/19Spring框架：IoC和AOP是扩展的核心.md @@ -0,0 +1,547 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 19 Spring框架：IoC和AOP是扩展的核心 + 今天，我们来聊聊 Spring 框架中的 IoC 和 AOP，及其容易出错的地方。 + +熟悉 Java 的同学都知道，Spring 的家族庞大，常用的模块就有 Spring Data、Spring Security、Spring Boot、Spring Cloud 等。其实呢，Spring 体系虽然庞大，但都是围绕 Spring Core 展开的，而 Spring Core 中最核心的就是 IoC（控制反转）和 AOP（面向切面编程）。 + +概括地说，IoC 和 AOP 的初衷是解耦和扩展。理解这两个核心技术，就可以让你的代码变得更灵活、可随时替换，以及业务组件间更解耦。在接下来的两讲中，我会与你深入剖析几个案例，带你绕过业务中通过 Spring 实现 IoC 和 AOP 相关的坑。 + +为了便于理解这两讲中的案例，我们先回顾下 IoC 和 AOP 的基础知识。 + +IoC，其实就是一种设计思想。使用 Spring 来实现 IoC，意味着将你设计好的对象交给 Spring 容器控制，而不是直接在对象内部控制。那，为什么要让容器来管理对象呢？或许你能想到的是，使用 IoC 方便、可以实现解耦。但在我看来，相比于这两个原因，更重要的是 IoC 带来了更多的可能性。 + +如果以容器为依托来管理所有的框架、业务对象，我们不仅可以无侵入地调整对象的关系，还可以无侵入地随时调整对象的属性，甚至是实现对象的替换。这就使得框架开发者在程序背后实现一些扩展不再是问题，带来的可能性是无限的。比如我们要监控的对象如果是 Bean，实现就会非常简单。所以，这套容器体系，不仅被 Spring Core 和 Spring Boot 大量依赖，还实现了一些外部框架和 Spring 的无缝整合。 + +AOP，体现了松耦合、高内聚的精髓，在切面集中实现横切关注点（缓存、权限、日志等），然后通过切点配置把代码注入合适的地方。切面、切点、增强、连接点，是 AOP 中非常重要的概念，也是我们这两讲会大量提及的。 + +为方便理解，我们把 Spring AOP 技术看作为蛋糕做奶油夹层的工序。如果我们希望找到一个合适的地方把奶油注入蛋糕胚子中，那应该如何指导工人完成操作呢？ + + + +首先，我们要提醒他，只能往蛋糕胚子里面加奶油，而不能上面或下面加奶油。这就是连接点（Join point），对于 Spring AOP 来说，连接点就是方法执行。 + +然后，我们要告诉他，在什么点切开蛋糕加奶油。比如，可以在蛋糕坯子中间加入一层奶油，在中间切一次；也可以在中间加两层奶油，在 1⁄3 和 2⁄3 的地方切两次。这就是切点（Pointcut），Spring AOP 中默认使用 AspectJ 查询表达式，通过在连接点运行查询表达式来匹配切入点。 + +接下来也是最重要的，我们要告诉他，切开蛋糕后要做什么，也就是加入奶油。这就是增强（Advice），也叫作通知，定义了切入切点后增强的方式，包括前、后、环绕等。Spring AOP 中，把增强定义为拦截器。 + +最后，我们要告诉他，找到蛋糕胚子中要加奶油的地方并加入奶油。为蛋糕做奶油夹层的操作，对 Spring AOP 来说就是切面（Aspect），也叫作方面。切面 = 切点 + 增强。 + +好了，理解了这几个核心概念，我们就可以继续分析案例了。 + +我要首先说明的是，Spring 相关问题的问题比较复杂，一方面是 Spring 提供的 IoC 和 AOP 本就灵活，另一方面 Spring Boot 的自动装配、Spring Cloud 复杂的模块会让问题排查变得更复杂。因此，今天这一讲，我会带你先打好基础，通过两个案例来重点聊聊 IoC 和 AOP；然后，我会在下一讲中与你分享 Spring 相关的坑。 + +单例的 Bean 如何注入 Prototype 的 Bean？ + +我们虽然知道 Spring 创建的 Bean 默认是单例的，但当 Bean 遇到继承的时候，可能会忽略这一点。为什么呢？忽略这一点又会造成什么影响呢？接下来，我就和你分享一个由单例引起内存泄露的案例。 + +架构师一开始定义了这么一个 SayService 抽象类，其中维护了一个类型是 ArrayList 的字段 data，用于保存方法处理的中间数据。每次调用 say 方法都会往 data 加入新数据，可以认为 SayService 是有状态，如果 SayService 是单例的话必然会 OOM： + +@Slf4j +public abstract class SayService { + + List data = new ArrayList<>(); + + public void say() { + data.add(IntStream.rangeClosed(1, 1000000) + .mapToObj(__ -> "a") + .collect(Collectors.joining("")) + UUID.randomUUID().toString()); + log.info("I'm {} size:{}", this, data.size()); + } +} + + +但实际开发的时候，开发同学没有过多思考就把 SayHello 和 SayBye 类加上了 @Service 注解，让它们成为了 Bean，也没有考虑到父类是有状态的： + +@Service +@Slf4j +public class SayHello extends SayService { + + @Override + public void say() { + super.say(); + log.info("hello"); + } +} + +@Service +@Slf4j +public class SayBye extends SayService { + + @Override + public void say() { + super.say(); + log.info("bye"); + } +} + + +许多开发同学认为，@Service 注解的意义在于，能通过 @Autowired 注解让 Spring 自动注入对象，就比如可以直接使用注入的 List获取到 SayHello 和 SayBye，而没想过类的生命周期： + +@Autowired +List sayServiceList; + +@GetMapping("test") +public void test() { + + log.info("===================="); + sayServiceList.forEach(SayService::say); +} + + +这一个点非常容易忽略。开发基类的架构师将基类设计为有状态的，但并不知道子类是怎么使用基类的；而开发子类的同学，没多想就直接标记了 @Service，让类成为了 Bean，通过 @Autowired 注解来注入这个服务。但这样设置后，有状态的基类就可能产生内存泄露或线程安全问题。 + +正确的方式是，在为类标记上 @Service 注解把类型交由容器管理前，首先评估一下类是否有状态，然后为 Bean 设置合适的 Scope。好在上线前，架构师发现了这个内存泄露问题，开发同学也做了修改，为 SayHello 和 SayBye 两个类都标记了 @Scope 注解，设置了 PROTOTYPE 的生命周期，也就是多例： + +@Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE) + + +但，上线后还是出现了内存泄漏，证明修改是无效的。 + +从日志可以看到，第一次调用和第二次调用的时候，SayBye 对象都是 4c0bfe9e，SayHello 也是一样的问题。从日志第 7 到 10 行还可以看到，第二次调用后 List 的元素个数变为了 2，说明父类 SayService 维护的 List 在不断增长，不断调用必然出现 OOM： + +[15:01:09.349] [http-nio-45678-exec-1] [INFO ] [.s.d.BeanSingletonAndOrderController:22 ] - ==================== +[15:01:09.401] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayBye@4c0bfe9e size:1 +[15:01:09.402] [http-nio-45678-exec-1] [INFO ] [t.commonmistakes.spring.demo1.SayBye:16 ] - bye +[15:01:09.469] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayHello@490fbeaa size:1 +[15:01:09.469] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo1.SayHello :17 ] - hello +[15:01:15.167] [http-nio-45678-exec-2] [INFO ] [.s.d.BeanSingletonAndOrderController:22 ] - ==================== +[15:01:15.197] [http-nio-45678-exec-2] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayBye@4c0bfe9e size:2 +[15:01:15.198] [http-nio-45678-exec-2] [INFO ] [t.commonmistakes.spring.demo1.SayBye:16 ] - bye +[15:01:15.224] [http-nio-45678-exec-2] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayHello@490fbeaa size:2 +[15:01:15.224] [http-nio-45678-exec-2] [INFO ] [o.g.t.c.spring.demo1.SayHello :17 ] - hello + + +这就引出了单例的 Bean 如何注入 Prototype 的 Bean 这个问题。Controller 标记了 @RestController 注解，而 @RestController 注解 =@Controller 注解 +@ResponseBody 注解，又因为 @Controller 标记了 @Component 元注解，所以 @RestController 注解其实也是一个 Spring Bean： + +//@RestController注解=@Controller注解+@ResponseBody注解@Target(ElementType.TYPE) +@Retention(RetentionPolicy.RUNTIME) +@Documented +@Controller +@ResponseBody +public @interface RestController {} + +//@Controller又标记了@Component元注解 +@Target({ElementType.TYPE}) +@Retention(RetentionPolicy.RUNTIME) +@Documented +@Component +public @interface Controller {} + + +Bean 默认是单例的，所以单例的 Controller 注入的 Service 也是一次性创建的，即使 Service 本身标识了 prototype 的范围也没用。 + +修复方式是，让 Service 以代理方式注入。这样虽然 Controller 本身是单例的，但每次都能从代理获取 Service。这样一来，prototype 范围的配置才能真正生效： + +@Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE, proxyMode = ScopedProxyMode.TARGET_CLASS) + + +通过日志可以确认这种修复方式有效： + +[15:08:42.649] [http-nio-45678-exec-1] [INFO ] [.s.d.BeanSingletonAndOrderController:22 ] - ==================== +[15:08:42.747] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayBye@3fa64743 size:1 +[15:08:42.747] [http-nio-45678-exec-1] [INFO ] [t.commonmistakes.spring.demo1.SayBye:17 ] - bye +[15:08:42.871] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayHello@2f0b779 size:1 +[15:08:42.872] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo1.SayHello :17 ] - hello +[15:08:42.932] [http-nio-45678-exec-2] [INFO ] [.s.d.BeanSingletonAndOrderController:22 ] - ==================== +[15:08:42.991] [http-nio-45678-exec-2] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayBye@7319b18e size:1 +[15:08:42.992] [http-nio-45678-exec-2] [INFO ] [t.commonmistakes.spring.demo1.SayBye:17 ] - bye +[15:08:43.046] [http-nio-45678-exec-2] [INFO ] [o.g.t.c.spring.demo1.SayService :19 ] - I'm org.geekbang.time.commonmistakes.spring.demo1.SayHello@77262b35 size:1 +[15:08:43.046] [http-nio-45678-exec-2] [INFO ] [o.g.t.c.spring.demo1.SayHello :17 ] - hello + + +调试一下也可以发现，注入的 Service 都是 Spring 生成的代理类： + + + +当然，如果不希望走代理的话还有一种方式是，每次直接从 ApplicationContext 中获取 Bean： + +@Autowired +private ApplicationContext applicationContext; + +@GetMapping("test2") +public void test2() { + applicationContext.getBeansOfType(SayService.class).values().forEach(SayService::say); +} + + +如果细心的话，你可以发现另一个潜在的问题。这里 Spring 注入的 SayService 的 List，第一个元素是 SayBye，第二个元素是 SayHello。但，我们更希望的是先执行 Hello 再执行 Bye，所以注入一个 List Bean 时，需要进一步考虑 Bean 的顺序或者说优先级。 + +大多数情况下顺序并不是那么重要，但对于 AOP，顺序可能会引发致命问题。我们继续往下看这个问题吧。 + +监控切面因为顺序问题导致 Spring 事务失效 + +实现横切关注点，是 AOP 非常常见的一个应用。我曾看到过一个不错的 AOP 实践，通过 AOP 实现了一个整合日志记录、异常处理和方法耗时打点为一体的统一切面。但后来发现，使用了 AOP 切面后，这个应用的声明式事务处理居然都是无效的。你可以先回顾下第 6 讲中提到的，Spring 事务失效的几种可能性。 + +现在我们来看下这个案例，分析下 AOP 实现的监控组件和事务失效有什么关系，以及通过 AOP 实现监控组件是否还有其他坑。 + +首先，定义一个自定义注解 Metrics，打上了该注解的方法可以实现各种监控功能： + +@Retention(RetentionPolicy.RUNTIME) +@Target({ElementType.METHOD, ElementType.TYPE}) +public @interface Metrics { + + /** + * 在方法成功执行后打点，记录方法的执行时间发送到指标系统，默认开启 + * + * @return + */ + boolean recordSuccessMetrics() default true; + + /** + * 在方法成功失败后打点，记录方法的执行时间发送到指标系统，默认开启 + * + * @return + */ + boolean recordFailMetrics() default true; + + /** + * 通过日志记录请求参数，默认开启 + * + * @return + */ + boolean logParameters() default true; + + /** + * 通过日志记录方法返回值，默认开启 + * + * @return + */ + boolean logReturn() default true; + + /** + * 出现异常后通过日志记录异常信息，默认开启 + * + * @return + */ + boolean logException() default true; + + /** + * 出现异常后忽略异常返回默认值，默认关闭 + * + * @return + */ + boolean ignoreException() default false; + +} + + +然后，实现一个切面完成 Metrics 注解提供的功能。这个切面可以实现标记了 @RestController 注解的 Web 控制器的自动切入，如果还需要对更多 Bean 进行切入的话，再自行标记 @Metrics 注解。 + +备注：这段代码有些长，里面还用到了一些小技巧，你需要仔细阅读代码中的注释。 + +@Aspect +@Component +@Slf4j +public class MetricsAspect { + + //让Spring帮我们注入ObjectMapper，以方便通过JSON序列化来记录方法入参和出参 + @Autowired + private ObjectMapper objectMapper; + + //实现一个返回Java基本类型默认值的工具。其实，你也可以逐一写很多if-else判断类型，然后手动设置其默认值。这里为了减少代码量用了一个小技巧，即通过初始化一个具有1个元素的数组，然后通过获取这个数组的值来获取基本类型默认值 + private static final Map, Object> DEFAULT_VALUES = Stream + .of(boolean.class, byte.class, char.class, double.class, float.class, int.class, long.class, short.class) + .collect(toMap(clazz -> (Class) clazz, clazz -> Array.get(Array.newInstance(clazz, 1), 0))); + + public static T getDefaultValue(Class clazz) { + return (T) DEFAULT_VALUES.get(clazz); + } + + //@annotation指示器实现对标记了Metrics注解的方法进行匹配 + @Pointcut("within(@org.geekbang.time.commonmistakes.springpart1.aopmetrics.Metrics *)") + public void withMetricsAnnotation() { + + } + + //within指示器实现了匹配那些类型上标记了@RestController注解的方法 + @Pointcut("within(@org.springframework.web.bind.annotation.RestController *)") + public void controllerBean() { + + } + + @Around("controllerBean() || withMetricsAnnotation())") + public Object metrics(ProceedingJoinPoint pjp) throws Throwable { + //通过连接点获取方法签名和方法上Metrics注解，并根据方法签名生成日志中要输出的方法定义描述 + MethodSignature signature = (MethodSignature) pjp.getSignature(); + Metrics metrics = signature.getMethod().getAnnotation(Metrics.class); + + String name = String.format("【%s】【%s】", signature.getDeclaringType().toString(), signature.toLongString()); + + //因为需要默认对所有@RestController标记的Web控制器实现@Metrics注解的功能，在这种情况下方法上必然是没有@Metrics注解的，我们需要获取一个默认注解。虽然可以手动实例化一个@Metrics注解的实例出来，但为了节省代码行数，我们通过在一个内部类上定义@Metrics注解方式，然后通过反射获取注解的小技巧，来获得一个默认的@Metrics注解的实例 + if (metrics == null) { + @Metrics + final class c {} + metrics = c.class.getAnnotation(Metrics.class); + } + //尝试从请求上下文（如果有的话）获得请求URL，以方便定位问题 + RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes(); + if (requestAttributes != null) { + HttpServletRequest request = ((ServletRequestAttributes) requestAttributes).getRequest(); + if (request != null) + name += String.format("【%s】", request.getRequestURL().toString()); + } + + //实现的是入参的日志输出 + if (metrics.logParameters()) + log.info(String.format("【入参日志】调用 %s 的参数是：【%s】", name, objectMapper.writeValueAsString(pjp.getArgs()))); + //实现连接点方法的执行，以及成功失败的打点，出现异常的时候还会记录日志 + Object returnValue; + Instant start = Instant.now(); + try { + returnValue = pjp.proceed(); + if (metrics.recordSuccessMetrics()) + //在生产级代码中，我们应考虑使用类似Micrometer的指标框架，把打点信息记录到时间序列数据库中，实现通过图表来查看方法的调用次数和执行时间，在设计篇我们会重点介绍 + log.info(String.format("【成功打点】调用 %s 成功，耗时：%d ms", name, Duration.between(start, Instant.now()).toMillis())); + } catch (Exception ex) { + if (metrics.recordFailMetrics()) + log.info(String.format("【失败打点】调用 %s 失败，耗时：%d ms", name, Duration.between(start, Instant.now()).toMillis())); + if (metrics.logException()) + log.error(String.format("【异常日志】调用 %s 出现异常！", name), ex); + //忽略异常的时候，使用一开始定义的getDefaultValue方法，来获取基本类型的默认值 + if (metrics.ignoreException()) + returnValue = getDefaultValue(signature.getReturnType()); + else + throw ex; + } + //实现了返回值的日志输出 + if (metrics.logReturn()) + log.info(String.format("【出参日志】调用 %s 的返回是：【%s】", name, returnValue)); + return returnValue; + } +} + + +接下来，分别定义最简单的 Controller、Service 和 Repository，来测试 MetricsAspect 的功能。 + +其中，Service 中实现创建用户的时候做了事务处理，当用户名包含 test 字样时会抛出异常，导致事务回滚。同时，我们为 Service 中的 createUser 标记了 @Metrics 注解。这样一来，我们还可以手动为类或方法标记 @Metrics 注解，实现 Controller 之外的其他组件的自动监控。 + +@Slf4j +@RestController //自动进行监控 +@RequestMapping("metricstest") +public class MetricsController { + + @Autowired + private UserService userService; + + @GetMapping("transaction") + public int transaction(@RequestParam("name") String name) { + try { + userService.createUser(new UserEntity(name)); + } catch (Exception ex) { + log.error("create user failed because {}", ex.getMessage()); + } + + return userService.getUserCount(name); + } +} + +@Service +@Slf4j +public class UserService { + + @Autowired + private UserRepository userRepository; + + @Transactional + @Metrics //启用方法监控 + public void createUser(UserEntity entity) { + userRepository.save(entity); + if (entity.getName().contains("test")) + throw new RuntimeException("invalid username!"); + } + + public int getUserCount(String name) { + return userRepository.findByName(name).size(); + } +} + +@Repository +public interface UserRepository extends JpaRepository { + + List findByName(String name); + +} + + +使用用户名“test”测试一下注册功能： + +[16:27:52.586] [http-nio-45678-exec-3] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :85 ] - 【入参日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.MetricsController】【public int org.geekbang.time.commonmistakes.spring.demo2.MetricsController.transaction(java.lang.String)】【http://localhost:45678/metricstest/transaction】 的参数是：【["test"]】 +[16:27:52.590] [http-nio-45678-exec-3] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :85 ] - 【入参日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.UserService】【public void org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(org.geekbang.time.commonmistakes.spring.demo2.UserEntity)】【http://localhost:45678/metricstest/transaction】 的参数是：【[{"id":null,"name":"test"}]】 +[16:27:52.609] [http-nio-45678-exec-3] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :96 ] - 【失败打点】调用 【class org.geekbang.time.commonmistakes.spring.demo2.UserService】【public void org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(org.geekbang.time.commonmistakes.spring.demo2.UserEntity)】【http://localhost:45678/metricstest/transaction】 失败，耗时：19 ms +[16:27:52.610] [http-nio-45678-exec-3] [ERROR] [o.g.t.c.spring.demo2.MetricsAspect :98 ] - 【异常日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.UserService】【public void org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(org.geekbang.time.commonmistakes.spring.demo2.UserEntity)】【http://localhost:45678/metricstest/transaction】 出现异常！ +java.lang.RuntimeException: invalid username! + at org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(UserService.java:18) + at org.geekbang.time.commonmistakes.spring.demo2.UserService$$FastClassBySpringCGLIB$$9eec91f.invoke() +[16:27:52.614] [http-nio-45678-exec-3] [ERROR] [g.t.c.spring.demo2.MetricsController:21 ] - create user failed because invalid username! +[16:27:52.617] [http-nio-45678-exec-3] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :93 ] - 【成功打点】调用 【class org.geekbang.time.commonmistakes.spring.demo2.MetricsController】【public int org.geekbang.time.commonmistakes.spring.demo2.MetricsController.transaction(java.lang.String)】【http://localhost:45678/metricstest/transaction】 成功，耗时：31 ms +[16:27:52.618] [http-nio-45678-exec-3] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :108 ] - 【出参日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.MetricsController】【public int org.geekbang.time.commonmistakes.spring.demo2.MetricsController.transaction(java.lang.String)】【http://localhost:45678/metricstest/transaction】 的返回是：【0】 + + +看起来这个切面很不错，日志中打出了整个调用的出入参、方法耗时： + +第 1、8、9 和 10 行分别是 Controller 方法的入参日志、调用 Service 方法出错后记录的错误信息、成功执行的打点和出参日志。因为 Controller 方法内部进行了 try-catch 处理，所以其方法最终是成功执行的。出参日志中显示最后查询到的用户数量是 0，表示用户创建实际是失败的。 + +第 2、3 和 4~7 行分别是 Service 方法的入参日志、失败打点和异常日志。正是因为 Service 方法的异常抛到了 Controller，所以整个方法才能被 @Transactional 声明式事务回滚。在这里，MetricsAspect 捕获了异常又重新抛出，记录了异常的同时又不影响事务回滚。 + +一段时间后，开发同学觉得默认的 @Metrics 配置有点不合适，希望进行两个调整： + +对于 Controller 的自动打点，不要自动记录入参和出参日志，否则日志量太大； + +对于 Service 中的方法，最好可以自动捕获异常。 + +于是，他就为 MetricsController 手动加上了 @Metrics 注解，设置 logParameters 和 logReturn 为 false；然后为 Service 中的 createUser 方法的 @Metrics 注解，设置了 ignoreException 属性为 true： + +@Metrics(logParameters = false, logReturn = false) //改动点1 +public class MetricsController { + +@Service +@Slf4j +public class UserService { + + @Transactional + @Metrics(ignoreException = true) //改动点2 + public void createUser(UserEntity entity) { + + ... + + +代码上线后发现日志量并没有减少，更要命的是事务回滚失效了，从输出看到最后查询到了名为 test 的用户： + +[17:01:16.549] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :75 ] - 【入参日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.MetricsController】【public int org.geekbang.time.commonmistakes.spring.demo2.MetricsController.transaction(java.lang.String)】【http://localhost:45678/metricstest/transaction】 的参数是：【["test"]】 +[17:01:16.670] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :75 ] - 【入参日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.UserService】【public void org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(org.geekbang.time.commonmistakes.spring.demo2.UserEntity)】【http://localhost:45678/metricstest/transaction】 的参数是：【[{"id":null,"name":"test"}]】 +[17:01:16.885] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :86 ] - 【失败打点】调用 【class org.geekbang.time.commonmistakes.spring.demo2.UserService】【public void org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(org.geekbang.time.commonmistakes.spring.demo2.UserEntity)】【http://localhost:45678/metricstest/transaction】 失败，耗时：211 ms +[17:01:16.899] [http-nio-45678-exec-1] [ERROR] [o.g.t.c.spring.demo2.MetricsAspect :88 ] - 【异常日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.UserService】【public void org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(org.geekbang.time.commonmistakes.spring.demo2.UserEntity)】【http://localhost:45678/metricstest/transaction】 出现异常！ +java.lang.RuntimeException: invalid username! + at org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(UserService.java:18) + at org.geekbang.time.commonmistakes.spring.demo2.UserService$$FastClassBySpringCGLIB$$9eec91f.invoke() +[17:01:16.902] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :98 ] - 【出参日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.UserService】【public void org.geekbang.time.commonmistakes.spring.demo2.UserService.createUser(org.geekbang.time.commonmistakes.spring.demo2.UserEntity)】【http://localhost:45678/metricstest/transaction】 的返回是：【null】 +[17:01:17.466] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :83 ] - 【成功打点】调用 【class org.geekbang.time.commonmistakes.spring.demo2.MetricsController】【public int org.geekbang.time.commonmistakes.spring.demo2.MetricsController.transaction(java.lang.String)】【http://localhost:45678/metricstest/transaction】 成功，耗时：915 ms +[17:01:17.467] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo2.MetricsAspect :98 ] - 【出参日志】调用 【class org.geekbang.time.commonmistakes.spring.demo2.MetricsController】【public int org.geekbang.time.commonmistakes.spring.demo2.MetricsController.transaction(java.lang.String)】【http://localhost:45678/metricstest/transaction】 的返回是：【1】 + + +在介绍数据库事务时，我们分析了 Spring 通过 TransactionAspectSupport 类实现事务。在 invokeWithinTransaction 方法中设置断点可以发现，在执行 Service 的 createUser 方法时，TransactionAspectSupport 并没有捕获到异常，所以自然无法回滚事务。原因就是，异常被 MetricsAspect 吃掉了。 + +我们知道，切面本身是一个 Bean，Spring 对不同切面增强的执行顺序是由 Bean 优先级决定的，具体规则是： + +入操作（Around（连接点执行前）、Before），切面优先级越高，越先执行。一个切面的入操作执行完，才轮到下一切面，所有切面入操作执行完，才开始执行连接点（方法）。 + +出操作（Around（连接点执行后）、After、AfterReturning、AfterThrowing），切面优先级越低，越先执行。一个切面的出操作执行完，才轮到下一切面，直到返回到调用点。 + +同一切面的 Around 比 After、Before 先执行。 + +对于 Bean 可以通过 @Order 注解来设置优先级，查看 @Order 注解和 Ordered 接口源码可以发现，默认情况下 Bean 的优先级为最低优先级，其值是 Integer 的最大值。其实，值越大优先级反而越低，这点比较反直觉： + +@Retention(RetentionPolicy.RUNTIME) +@Target({ElementType.TYPE, ElementType.METHOD, ElementType.FIELD}) +@Documented +public @interface Order { + + int value() default Ordered.LOWEST_PRECEDENCE; + +} + +public interface Ordered { + int HIGHEST_PRECEDENCE = Integer.MIN_VALUE; + int LOWEST_PRECEDENCE = Integer.MAX_VALUE; + + int getOrder(); +} + + +我们再通过一个例子，来理解下增强的执行顺序。新建一个 TestAspectWithOrder10 切面，通过 @Order 注解设置优先级为 10，在内部定义 @Before、@After、@Around 三类增强，三个增强的逻辑只是简单的日志输出，切点是 TestController 所有方法；然后再定义一个类似的 TestAspectWithOrder20 切面，设置优先级为 20： + +@Aspect +@Component +@Order(10) +@Slf4j +public class TestAspectWithOrder10 { + + @Before("execution(* org.geekbang.time.commonmistakes.springpart1.aopmetrics.TestController.*(..))") + public void before(JoinPoint joinPoint) throws Throwable { + log.info("TestAspectWithOrder10 @Before"); + } + + @After("execution(* org.geekbang.time.commonmistakes.springpart1.aopmetrics.TestController.*(..))") + public void after(JoinPoint joinPoint) throws Throwable { + log.info("TestAspectWithOrder10 @After"); + } + + @Around("execution(* org.geekbang.time.commonmistakes.springpart1.aopmetrics.TestController.*(..))") + public Object around(ProceedingJoinPoint pjp) throws Throwable { + log.info("TestAspectWithOrder10 @Around before"); + Object o = pjp.proceed(); + log.info("TestAspectWithOrder10 @Around after"); + return o; + } + +} + +@Aspect +@Component +@Order(20) +@Slf4j +public class TestAspectWithOrder20 { + + ... + +} + + +调用 TestController 的方法后，通过日志输出可以看到，增强执行顺序符合切面执行顺序的三个规则： + + + +因为 Spring 的事务管理也是基于 AOP 的，默认情况下优先级最低也就是会先执行出操作，但是自定义切面 MetricsAspect 也同样是最低优先级，这个时候就可能出现问题：如果出操作先执行捕获了异常，那么 Spring 的事务处理就会因为无法捕获到异常导致无法回滚事务。 + +解决方式是，明确 MetricsAspect 的优先级，可以设置为最高优先级，也就是最先执行入操作最后执行出操作： + +//将MetricsAspect这个Bean的优先级设置为最高 +@Order(Ordered.HIGHEST_PRECEDENCE) +public class MetricsAspect { + + ... + +} + + +此外，我们要知道切入的连接点是方法，注解定义在类上是无法直接从方法上获取到注解的。修复方式是，改为优先从方法获取，如果获取不到再从类获取，如果还是获取不到再使用默认的注解： + +Metrics metrics = signature.getMethod().getAnnotation(Metrics.class); +if (metrics == null) { + metrics = signature.getMethod().getDeclaringClass().getAnnotation(Metrics.class); +} + + +经过这 2 处修改，事务终于又可以回滚了，并且 Controller 的监控日志也不再出现入参、出参信息。 + +我再总结下这个案例。利用反射 + 注解 +Spring AOP 实现统一的横切日志关注点时，我们遇到的 Spring 事务失效问题，是由自定义的切面执行顺序引起的。这也让我们认识到，因为 Spring 内部大量利用 IoC 和 AOP 实现了各种组件，当使用 IoC 和 AOP 时，一定要考虑是否会影响其他内部组件。 + +重点回顾 + +今天，我通过 2 个案例和你分享了 Spring IoC 和 AOP 的基本概念，以及三个比较容易出错的点。 + +第一，让 Spring 容器管理对象，要考虑对象默认的 Scope 单例是否适合，对于有状态的类型，单例可能产生内存泄露问题。 + +第二，如果要为单例的 Bean 注入 Prototype 的 Bean，绝不是仅仅修改 Scope 属性这么简单。由于单例的 Bean 在容器启动时就会完成一次性初始化。最简单的解决方案是，把 Prototype 的 Bean 设置为通过代理注入，也就是设置 proxyMode 属性为 TARGET_CLASS。 + +第三，如果一组相同类型的 Bean 是有顺序的，需要明确使用 @Order 注解来设置顺序。你可以再回顾下，两个不同优先级切面中 @Before、@After 和 @Around 三种增强的执行顺序，是什么样的。 + +最后我要说的是，文内第二个案例是一个完整的统一日志监控案例，继续修改就可以实现一个完善的、生产级的方法调用监控平台。这些修改主要是两方面：把日志打点，改为对接 Metrics 监控系统；把各种功能的监控开关，从注解属性获取改为通过配置系统实时获取。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +除了通过 @Autowired 注入 Bean 外，还可以使用 @Inject 或 @Resource 来注入 Bean。你知道这三种方式的区别是什么吗？ + +当 Bean 产生循环依赖时，比如 BeanA 的构造方法依赖 BeanB 作为成员需要注入，BeanB 也依赖 BeanA，你觉得会出现什么问题呢？又有哪些解决方式呢？ + +在下一讲中，我会继续与你探讨 Spring 核心的其他问题。我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/20Spring框架：框架帮我们做了很多工作也带来了复杂度.md b/专栏/Java业务开发常见错误100例/20Spring框架：框架帮我们做了很多工作也带来了复杂度.md new file mode 100644 index 0000000..e4de5c8 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/20Spring框架：框架帮我们做了很多工作也带来了复杂度.md @@ -0,0 +1,639 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 20 Spring框架：框架帮我们做了很多工作也带来了复杂度 + 今天，我们聊聊 Spring 框架给业务代码带来的复杂度，以及与之相关的坑。 + +在上一讲，通过 AOP 实现统一的监控组件的案例，我们看到了 IoC 和 AOP 配合使用的威力：当对象由 Spring 容器管理成为 Bean 之后，我们不但可以通过容器管理配置 Bean 的属性，还可以方便地对感兴趣的方法做 AOP。 + +不过，前提是对象必须是 Bean。你可能会觉得这个结论很明显，也很容易理解啊。但就和上一讲提到的 Bean 默认是单例一样，理解起来简单，实践的时候却非常容易踩坑。其中原因，一方面是，理解 Spring 的体系结构和使用方式有一定曲线；另一方面是，Spring 多年发展堆积起来的内部结构非常复杂，这也是更重要的原因。 + +在我看来，Spring 框架内部的复杂度主要表现为三点： + +第一，Spring 框架借助 IoC 和 AOP 的功能，实现了修改、拦截 Bean 的定义和实例的灵活性，因此真正执行的代码流程并不是串行的。 + +第二，Spring Boot 根据当前依赖情况实现了自动配置，虽然省去了手动配置的麻烦，但也因此多了一些黑盒、提升了复杂度。 + +第三，Spring Cloud 模块多版本也多，Spring Boot 1.x 和 2.x 的区别也很大。如果要对 Spring Cloud 或 Spring Boot 进行二次开发的话，考虑兼容性的成本会很高。 + +今天，我们就通过配置 AOP 切入 Spring Cloud Feign 组件失败、Spring Boot 程序的文件配置被覆盖这两个案例，感受一下 Spring 的复杂度。我希望这一讲的内容，能帮助你面对 Spring 这个复杂框架出现的问题时，可以非常自信地找到解决方案。 + +Feign AOP 切不到的诡异案例 + +我曾遇到过这么一个案例：使用 Spring Cloud 做微服务调用，为方便统一处理 Feign，想到了用 AOP 实现，即使用 within 指示器匹配 feign.Client 接口的实现进行 AOP 切入。 + +代码如下，通过 @Before 注解在执行方法前打印日志，并在代码中定义了一个标记了 @FeignClient 注解的 Client 类，让其成为一个 Feign 接口： + +//测试Feign +@FeignClient(name = "client") +public interface Client { + @GetMapping("/feignaop/server") + String api(); +} + +//AOP切入feign.Client的实现 +@Aspect +@Slf4j +@Component +public class WrongAspect { + + @Before("within(feign.Client+)") + public void before(JoinPoint pjp) { + log.info("within(feign.Client+) pjp {}, args:{}", pjp, pjp.getArgs()); + } +} + +//配置扫描Feign +@Configuration +@EnableFeignClients(basePackages = "org.geekbang.time.commonmistakes.spring.demo4.feign") +public class Config { + +} + + +通过 Feign 调用服务后可以看到日志中有输出，的确实现了 feign.Client 的切入，切入的是 execute 方法： + +[15:48:32.850] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo4.WrongAspect :20 ] - within(feign.Client+) pjp execution(Response feign.Client.execute(Request,Options)), args:[GET http://client/feignaop/server HTTP/1.1 + +Binary data, feign.Request$Options@5c16561a] + + +一开始这个项目使用的是客户端的负载均衡，也就是让 Ribbon 来做负载均衡，代码没啥问题。后来因为后端服务通过 Nginx 实现服务端负载均衡，所以开发同学把 @FeignClient 的配置设置了 URL 属性，直接通过一个固定 URL 调用后端服务： + +@FeignClient(name = "anotherClient",url = "http://localhost:45678") +public interface ClientWithUrl { + + @GetMapping("/feignaop/server") + String api(); +} + + +但这样配置后，之前的 AOP 切面竟然失效了，也就是 within(feign.Client+) 无法切入 ClientWithUrl 的调用了。 + +为了还原这个场景，我写了一段代码，定义两个方法分别通过 Client 和 ClientWithUrl 这两个 Feign 进行接口调用： + +@Autowired +private Client client; + +@Autowired +private ClientWithUrl clientWithUrl; + +@GetMapping("client") +public String client() { + return client.api(); +} + +@GetMapping("clientWithUrl") +public String clientWithUrl() { + return clientWithUrl.api(); +} + + +可以看到，调用 Client 后 AOP 有日志输出，调用 ClientWithUrl 后却没有： + +[15:50:32.850] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo4.WrongAspect :20 ] - within(feign.Client+) pjp execution(Response feign.Client.execute(Request,Options)), args:[GET http://client/feignaop/server HTTP/1.1 +Binary data, feign.Request$Options@5c16561 + + +这就很费解了。难道为 Feign 指定了 URL，其实现就不是 feign.Clinet 了吗？ + +要明白原因，我们需要分析一下 FeignClient 的创建过程，也就是分析 FeignClientFactoryBean 类的 getTarget 方法。源码第 4 行有一个 if 判断，当 URL 没有内容也就是为空或者不配置时调用 loadBalance 方法，在其内部通过 FeignContext 从容器获取 feign.Client 的实例： + + T getTarget() { + + FeignContext context = this.applicationContext.getBean(FeignContext.class); + + Feign.Builder builder = feign(context); + + if (!StringUtils.hasText(this.url)) { + ... + return (T) loadBalance(builder, context, + new HardCodedTarget<>(this.type, this.name, this.url)); + } + ... + String url = this.url + cleanPath(); + Client client = getOptional(context, Client.class); + if (client != null) { + if (client instanceof LoadBalancerFeignClient) { + // not load balancing because we have a url, + // but ribbon is on the classpath, so unwrap + client = ((LoadBalancerFeignClient) client).getDelegate(); + } + builder.client(client); + } + ... +} + +protected T loadBalance(Feign.Builder builder, FeignContext context, HardCodedTarget target) { + + Client client = getOptional(context, Client.class); + if (client != null) { + builder.client(client); + Targeter targeter = get(context, Targeter.class); + return targeter.target(this, builder, context, target); + } +... +} + +protected T getOptional(FeignContext context, Class type) { + return context.getInstance(this.contextId, type); +} + + +调试一下可以看到，client 是 LoadBalanceFeignClient，已经是经过代理增强的，明显是一个 Bean： + + + +所以，没有指定 URL 的 @FeignClient 对应的 LoadBalanceFeignClient，是可以通过 feign.Client 切入的。 + +在我们上面贴出来的源码的 16 行可以看到，当 URL 不为空的时候，client 设置为了 LoadBalanceFeignClient 的 delegate 属性。其原因注释中有提到，因为有了 URL 就不需要客户端负载均衡了，但因为 Ribbon 在 classpath 中，所以需要从 LoadBalanceFeignClient 提取出真正的 Client。断点调试下可以看到，这时 client 是一个 ApacheHttpClient： + + + +那么，这个 ApacheHttpClient 是从哪里来的呢？这里，我教你一个小技巧：如果你希望知道一个类是怎样调用栈初始化的，可以在构造方法中设置一个断点进行调试。这样，你就可以在 IDE 的栈窗口看到整个方法调用栈，然后点击每一个栈帧看到整个过程。 + +用这种方式，我们可以看到，是 HttpClientFeignLoadBalancedConfiguration 类实例化的 ApacheHttpClient： + + + +进一步查看 HttpClientFeignLoadBalancedConfiguration 的源码可以发现，LoadBalancerFeignClient 这个 Bean 在实例化的时候，new 出来一个 ApacheHttpClient 作为 delegate 放到了 LoadBalancerFeignClient 中： + +@Bean +@ConditionalOnMissingBean(Client.class) +public Client feignClient(CachingSpringLoadBalancerFactory cachingFactory, + SpringClientFactory clientFactory, HttpClient httpClient) { + + ApacheHttpClient delegate = new ApacheHttpClient(httpClient); + return new LoadBalancerFeignClient(delegate, cachingFactory, clientFactory); +} + +public LoadBalancerFeignClient(Client delegate, + CachingSpringLoadBalancerFactory lbClientFactory, + SpringClientFactory clientFactory) { + + this.delegate = delegate; + this.lbClientFactory = lbClientFactory; + this.clientFactory = clientFactory; +} + + +显然，ApacheHttpClient 是 new 出来的，并不是 Bean，而 LoadBalancerFeignClient 是一个 Bean。 + +有了这个信息，我们再来捋一下，为什么 within(feign.Client+) 无法切入设置过 URL 的 @FeignClient ClientWithUrl： + +表达式声明的是切入 feign.Client 的实现类。 + +Spring 只能切入由自己管理的 Bean。 + +虽然 LoadBalancerFeignClient 和 ApacheHttpClient 都是 feign.Client 接口的实现，但是 HttpClientFeignLoadBalancedConfiguration 的自动配置只是把前者定义为 Bean，后者是 new 出来的、作为了 LoadBalancerFeignClient 的 delegate，不是 Bean。 + +在定义了 FeignClient 的 URL 属性后，我们获取的是 LoadBalancerFeignClient 的 delegate，它不是 Bean。 + +因此，定义了 URL 的 FeignClient 采用 within(feign.Client+) 无法切入。 + +那，如何解决这个问题呢？有一位同学提出，修改一下切点表达式，通过 @FeignClient 注解来切： + +@Before("@within(org.springframework.cloud.openfeign.FeignClient)") +public void before(JoinPoint pjp){ + log.info("@within(org.springframework.cloud.openfeign.FeignClient) pjp {}, args:{}", pjp, pjp.getArgs()); +} + + +修改后通过日志看到，AOP 的确切成功了： + +[15:53:39.093] [http-nio-45678-exec-3] [INFO ] [o.g.t.c.spring.demo4.Wrong2Aspect :17 ] - @within(org.springframework.cloud.openfeign.FeignClient) pjp execution(String org.geekbang.time.commonmistakes.spring.demo4.feign.ClientWithUrl.api()), args:[] + + +但仔细一看就会发现，这次切入的是 ClientWithUrl 接口的 API 方法，并不是 client.Feign 接口的 execute 方法，显然不符合预期。 + +这位同学犯的错误是，没有弄清楚真正希望切的是什么对象。@FeignClient 注解标记在 Feign Client 接口上，所以切的是 Feign 定义的接口，也就是每一个实际的 API 接口。而通过 feign.Client 接口切的是客户端实现类，切到的是通用的、执行所有 Feign 调用的 execute 方法。 + +那么问题来了，ApacheHttpClient 不是 Bean 无法切入，切 Feign 接口本身又不符合要求。怎么办呢？ + +经过一番研究发现，ApacheHttpClient 其实有机会独立成为 Bean。查看 HttpClientFeignConfiguration 的源码可以发现，当没有 ILoadBalancer 类型的时候，自动装配会把 ApacheHttpClient 设置为 Bean。 + +这么做的原因很明确，如果我们不希望做客户端负载均衡的话，应该不会引用 Ribbon 组件的依赖，自然没有 LoadBalancerFeignClient，只有 ApacheHttpClient： + +@Configuration +@ConditionalOnClass(ApacheHttpClient.class) +@ConditionalOnMissingClass("com.netflix.loadbalancer.ILoadBalancer") +@ConditionalOnMissingBean(CloseableHttpClient.class) +@ConditionalOnProperty(value = "feign.httpclient.enabled", matchIfMissing = true) +protected static class HttpClientFeignConfiguration { + + @Bean + @ConditionalOnMissingBean(Client.class) + public Client feignClient(HttpClient httpClient) { + return new ApacheHttpClient(httpClient); + } +} + + +那，把 pom.xml 中的 ribbon 模块注释之后，是不是可以解决问题呢？ + + + org.springframework.cloud + spring-cloud-starter-netflix-ribbon + + + +但，问题并没解决，启动出错误了： + +Caused by: java.lang.IllegalArgumentException: Cannot subclass final class feign.httpclient.ApacheHttpClient + at org.springframework.cglib.proxy.Enhancer.generateClass(Enhancer.java:657) + at org.springframework.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25) + + +这里，又涉及了 Spring 实现动态代理的两种方式： + +JDK 动态代理，通过反射实现，只支持对实现接口的类进行代理； + +CGLIB 动态字节码注入方式，通过继承实现代理，没有这个限制。 + +Spring Boot 2.x 默认使用 CGLIB 的方式，但通过继承实现代理有个问题是，无法继承 final 的类。因为，ApacheHttpClient 类就是定义为了 final： + +public final class ApacheHttpClient implements Client { + + +为解决这个问题，我们把配置参数 proxy-target-class 的值修改为 false，以切换到使用 JDK 动态代理的方式： + +spring.aop.proxy-target-class=false + + +修改后执行 clientWithUrl 接口可以看到，通过 within(feign.Client+) 方式可以切入 feign.Client 子类了。以下日志显示了 @within 和 within 的两次切入： + +[16:29:55.303] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo4.Wrong2Aspect :16 ] - @within(org.springframework.cloud.openfeign.FeignClient) pjp execution(String org.geekbang.time.commonmistakes.spring.demo4.feign.ClientWithUrl.api()), args:[] +[16:29:55.310] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.spring.demo4.WrongAspect :15 ] - within(feign.Client+) pjp execution(Response feign.Client.execute(Request,Options)), args:[GET http://localhost:45678/feignaop/server HTTP/1.1 +Binary data, feign.Request$Options@387550b0] + + +这下我们就明白了，Spring Cloud 使用了自动装配来根据依赖装配组件，组件是否成为 Bean 决定了 AOP 是否可以切入，在尝试通过 AOP 切入 Spring Bean 的时候要注意。 + +加上上一讲的两个案例，我就把 IoC 和 AOP 相关的坑点和你说清楚了。除此之外，我们在业务开发时，还有一个绕不开的点是，Spring 程序的配置问题。接下来，我们就具体看看吧。 + +Spring 程序配置的优先级问题 + +我们知道，通过配置文件 application.properties，可以实现 Spring Boot 应用程序的参数配置。但我们可能不知道的是，Spring 程序配置是有优先级的，即当两个不同的配置源包含相同的配置项时，其中一个配置项很可能会被覆盖掉。这，也是为什么我们会遇到些看似诡异的配置失效问题。 + +我们来通过一个实际案例，研究下配置源以及配置源的优先级问题。 + +对于 Spring Boot 应用程序，一般我们会通过设置 management.server.port 参数，来暴露独立的 actuator 管理端口。这样做更安全，也更方便监控系统统一监控程序是否健康。 + +management.server.port=45679 + + +有一天程序重新发布后，监控系统显示程序离线。但排查下来发现，程序是正常工作的，只是 actuator 管理端口的端口号被改了，不是配置文件中定义的 45679 了。 + +后来发现，运维同学在服务器上定义了两个环境变量 MANAGEMENT_SERVER_IP 和 MANAGEMENT_SERVER_PORT，目的是方便监控 Agent 把监控数据上报到统一的管理服务上： + +MANAGEMENT_SERVER_IP=192.168.0.2 +MANAGEMENT_SERVER_PORT=12345 + + +问题就是出在这里。MANAGEMENT_SERVER_PORT 覆盖了配置文件中的 management.server.port，修改了应用程序本身的端口。当然，监控系统也就无法通过老的管理端口访问到应用的 health 端口了。如下图所示，actuator 的端口号变成了 12345： + + + +到这里坑还没完，为了方便用户登录，需要在页面上显示默认的管理员用户名，于是开发同学在配置文件中定义了一个 user.name 属性，并设置为 defaultadminname： + +user.name=defaultadminname + + +后来发现，程序读取出来的用户名根本就不是配置文件中定义的。这，又是咋回事？ + +带着这个问题，以及之前环境变量覆盖配置文件配置的问题，我们写段代码看看，从 Spring 中到底能读取到几个 management.server.port 和 user.name 配置项。 + +要想查询 Spring 中所有的配置，我们需要以环境 Environment 接口为入口。接下来，我就与你说说 Spring 通过环境 Environment 抽象出的 Property 和 Profile： + +针对 Property，又抽象出各种 PropertySource 类代表配置源。一个环境下可能有多个配置源，每个配置源中有诸多配置项。在查询配置信息时，需要按照配置源优先级进行查询。 + +Profile 定义了场景的概念。通常，我们会定义类似 dev、test、stage 和 prod 等环境作为不同的 Profile，用于按照场景对 Bean 进行逻辑归属。同时，Profile 和配置文件也有关系，每个环境都有独立的配置文件，但我们只会激活某一个环境来生效特定环境的配置文件。 + + + +接下来，我们重点看看 Property 的查询过程。 + +对于非 Web 应用，Spring 对于 Environment 接口的实现是 StandardEnvironment 类。我们通过 Spring 注入 StandardEnvironment 后循环 getPropertySources 获得的 PropertySource，来查询所有的 PropertySource 中 key 是 user.name 或 management.server.port 的属性值；然后遍历 getPropertySources 方法，获得所有配置源并打印出来： + +@Autowired +private StandardEnvironment env; +@PostConstruct +public void init(){ + Arrays.asList("user.name", "management.server.port").forEach(key -> { + env.getPropertySources().forEach(propertySource -> { + if (propertySource.containsProperty(key)) { + log.info("{} -> {} 实际取值：{}", propertySource, propertySource.getProperty(key), env.getProperty(key)); + } + }); + }); + System.out.println("配置优先级："); + env.getPropertySources().stream().forEach(System.out::println); +} + + +我们研究下输出的日志： + +2020-01-15 16:08:34.054 INFO 40123 --- [ main] o.g.t.c.s.d.CommonMistakesApplication : ConfigurationPropertySourcesPropertySource {name='configurationProperties'} -> zhuye 实际取值：zhuye +2020-01-15 16:08:34.054 INFO 40123 --- [ main] o.g.t.c.s.d.CommonMistakesApplication : PropertiesPropertySource {name='systemProperties'} -> zhuye 实际取值：zhuye +2020-01-15 16:08:34.054 INFO 40123 --- [ main] o.g.t.c.s.d.CommonMistakesApplication : OriginTrackedMapPropertySource {name='applicationConfig: [classpath:/application.properties]'} -> defaultadminname 实际取值：zhuye +2020-01-15 16:08:34.054 INFO 40123 --- [ main] o.g.t.c.s.d.CommonMistakesApplication : ConfigurationPropertySourcesPropertySource {name='configurationProperties'} -> 12345 实际取值：12345 +2020-01-15 16:08:34.054 INFO 40123 --- [ main] o.g.t.c.s.d.CommonMistakesApplication : OriginAwareSystemEnvironmentPropertySource {name=''} -> 12345 实际取值：12345 +2020-01-15 16:08:34.054 INFO 40123 --- [ main] o.g.t.c.s.d.CommonMistakesApplication : OriginTrackedMapPropertySource {name='applicationConfig: [classpath:/application.properties]'} -> 45679 实际取值：12345 + +配置优先级： +ConfigurationPropertySourcesPropertySource {name='configurationProperties'} +StubPropertySource {name='servletConfigInitParams'} +ServletContextPropertySource {name='servletContextInitParams'} +PropertiesPropertySource {name='systemProperties'} +OriginAwareSystemEnvironmentPropertySource {name='systemEnvironment'} +RandomValuePropertySource {name='random'} +OriginTrackedMapPropertySource {name='applicationConfig: [classpath:/application.properties]'} +MapPropertySource {name='springCloudClientHostInfo'} +MapPropertySource {name='defaultProperties'} + + +有三处定义了 user.name：第一个是 configurationProperties，值是 zhuye；第二个是 systemProperties，代表系统配置，值是 zhuye；第三个是 applicationConfig，也就是我们的配置文件，值是配置文件中定义的 defaultadminname。 + +同样地，也有三处定义了 management.server.port：第一个是 configurationProperties，值是 12345；第二个是 systemEnvironment 代表系统环境，值是 12345；第三个是 applicationConfig，也就是我们的配置文件，值是配置文件中定义的 45679。 + +第 7 到 16 行的输出显示，Spring 中有 9 个配置源，值得关注是 ConfigurationPropertySourcesPropertySource、PropertiesPropertySource、OriginAwareSystemEnvironmentPropertySource 和我们的配置文件。 + +那么，Spring 真的是按这个顺序查询配置吗？最前面的 configurationProperties，又是什么？为了回答这 2 个问题，我们需要分析下源码。我先说明下，下面源码分析的逻辑有些复杂，你可以结合着下面的整体流程图来理解： + + + +Demo 中注入的 StandardEnvironment，继承的是 AbstractEnvironment（图中紫色类）。AbstractEnvironment 的源码如下： + +public abstract class AbstractEnvironment implements ConfigurableEnvironment { + private final MutablePropertySources propertySources = new MutablePropertySources(); + + private final ConfigurablePropertyResolver propertyResolver = + new PropertySourcesPropertyResolver(this.propertySources); + + public String getProperty(String key) { + return this.propertyResolver.getProperty(key); + } +} + + +可以看到： + +MutablePropertySources 类型的字段 propertySources，看起来代表了所有配置源； + +getProperty 方法，通过 PropertySourcesPropertyResolver 类进行查询配置； + +实例化 PropertySourcesPropertyResolver 的时候，传入了当前的 MutablePropertySources。 + +接下来，我们继续分析 MutablePropertySources 和 PropertySourcesPropertyResolver。先看看 MutablePropertySources 的源码（图中蓝色类）： + +public class MutablePropertySources implements PropertySources { + + private final List> propertySourceList = new CopyOnWriteArrayList<>(); + + public void addFirst(PropertySource propertySource) { + removeIfPresent(propertySource); + this.propertySourceList.add(0, propertySource); + } + + public void addLast(PropertySource propertySource) { + removeIfPresent(propertySource); + this.propertySourceList.add(propertySource); + } + + public void addBefore(String relativePropertySourceName, PropertySource propertySource) { + ... + int index = assertPresentAndGetIndex(relativePropertySourceName); + addAtIndex(index, propertySource); + } + + public void addAfter(String relativePropertySourceName, PropertySource propertySource) { + ... + int index = assertPresentAndGetIndex(relativePropertySourceName); + addAtIndex(index + 1, propertySource); + } + + private void addAtIndex(int index, PropertySource propertySource) { + removeIfPresent(propertySource); + this.propertySourceList.add(index, propertySource); + } +} + + +可以发现： + +propertySourceList 字段用来真正保存 PropertySource 的 List，且这个 List 是一个 CopyOnWriteArrayList。 + +类中定义了 addFirst、addLast、addBefore、addAfter 等方法，来精确控制 PropertySource 加入 propertySourceList 的顺序。这也说明了顺序的重要性。 + +继续看下 PropertySourcesPropertyResolver（图中绿色类）的源码，找到真正查询配置的方法 getProperty。 + +这里，我们重点看一下第 9 行代码：遍历的 propertySources 是 PropertySourcesPropertyResolver 构造方法传入的，再结合 AbstractEnvironment 的源码可以发现，这个 propertySources 正是 AbstractEnvironment 中的 MutablePropertySources 对象。遍历时，如果发现配置源中有对应的 Key 值，则使用这个值。因此，MutablePropertySources 中配置源的次序尤为重要。 + +public class PropertySourcesPropertyResolver extends AbstractPropertyResolver { + + private final PropertySources propertySources; + + public PropertySourcesPropertyResolver(@Nullable PropertySources propertySources) { + this.propertySources = propertySources; + } + + protected T getProperty(String key, Class targetValueType, boolean resolveNestedPlaceholders) { + if (this.propertySources != null) { + for (PropertySource propertySource : this.propertySources) { + if (logger.isTraceEnabled()) { + logger.trace("Searching for key '" + key + "' in PropertySource '" + + propertySource.getName() + "'"); + } + Object value = propertySource.getProperty(key); + if (value != null) { + if (resolveNestedPlaceholders && value instanceof String) { + value = resolveNestedPlaceholders((String) value); + } + logKeyFound(key, propertySource, value); + return convertValueIfNecessary(value, targetValueType); + } + } + } + ... + } +} + + +回到之前的问题，在查询所有配置源的时候，我们注意到处在第一位的是 ConfigurationPropertySourcesPropertySource，这是什么呢？ + +其实，它不是一个实际存在的配置源，扮演的是一个代理的角色。但通过调试你会发现，我们获取的值竟然是由它提供并且返回的，且没有循环遍历后面的 PropertySource： + + + +继续查看 ConfigurationPropertySourcesPropertySource（图中红色类）的源码可以发现，getProperty 方法其实是通过 findConfigurationProperty 方法查询配置的。如第 25 行代码所示，这其实还是在遍历所有的配置源： + +class ConfigurationPropertySourcesPropertySource extends PropertySource> + implements OriginLookup { + + ConfigurationPropertySourcesPropertySource(String name, Iterable source) { + super(name, source); + } + + @Override + public Object getProperty(String name) { + ConfigurationProperty configurationProperty = findConfigurationProperty(name); + return (configurationProperty != null) ? configurationProperty.getValue() : null; + } + + private ConfigurationProperty findConfigurationProperty(String name) { + try { + return findConfigurationProperty(ConfigurationPropertyName.of(name, true)); + } catch (Exception ex) { + return null; + } + } + + private ConfigurationProperty findConfigurationProperty(ConfigurationPropertyName name) { + + if (name == null) { + return null; + } + + for (ConfigurationPropertySource configurationPropertySource : getSource()) { + ConfigurationProperty configurationProperty = configurationPropertySource.getConfigurationProperty(name); + if (configurationProperty != null) { + return configurationProperty; + } + } + return null; + } +} + + +调试可以发现，这个循环遍历（getSource() 的结果）的配置源，其实是 SpringConfigurationPropertySources（图中黄色类），其中包含的配置源列表就是之前看到的 9 个配置源，而第一个就是 ConfigurationPropertySourcesPropertySource。看到这里，我们的第一感觉是会不会产生死循环，它在遍历的时候怎么排除自己呢？ + +同时观察 configurationProperty 可以看到，这个 ConfigurationProperty 其实类似代理的角色，实际配置是从系统属性中获得的： + + + +继续查看 SpringConfigurationPropertySources 可以发现，它返回的迭代器是内部类 SourcesIterator，在 fetchNext 方法获取下一个项时，通过 isIgnored 方法排除了 ConfigurationPropertySourcesPropertySource（源码第 38 行）： + +class SpringConfigurationPropertySources implements Iterable { + + private final Iterable> sources; + + private final Map, ConfigurationPropertySource> cache = new ConcurrentReferenceHashMap<>(16, + ReferenceType.SOFT); + + SpringConfigurationPropertySources(Iterable> sources) { + Assert.notNull(sources, "Sources must not be null"); + this.sources = sources; + } + + @Override + public Iterator iterator() { + return new SourcesIterator(this.sources.iterator(), this::adapt); + } + + private static class SourcesIterator implements Iterator { + @Override + public boolean hasNext() { + return fetchNext() != null; + } + + private ConfigurationPropertySource fetchNext() { + if (this.next == null) { + if (this.iterators.isEmpty()) { + return null; + } + if (!this.iterators.peek().hasNext()) { + this.iterators.pop(); + return fetchNext(); + } + PropertySource candidate = this.iterators.peek().next(); + if (candidate.getSource() instanceof ConfigurableEnvironment) { + push((ConfigurableEnvironment) candidate.getSource()); + return fetchNext(); + } + if (isIgnored(candidate)) { + return fetchNext(); + } + this.next = this.adapter.apply(candidate); + } + return this.next; + } + + private void push(ConfigurableEnvironment environment) { + this.iterators.push(environment.getPropertySources().iterator()); + } + + private boolean isIgnored(PropertySource candidate) { + return (candidate instanceof StubPropertySource + || candidate instanceof ConfigurationPropertySourcesPropertySource); + } + } +} + + +我们已经了解了 ConfigurationPropertySourcesPropertySource 是所有配置源中的第一个，实现了对 PropertySourcesPropertyResolver 中遍历逻辑的“劫持”，并且知道了其遍历逻辑。最后一个问题是，它如何让自己成为第一个配置源呢？ + +再次运用之前我们学到的那个小技巧，来查看实例化 ConfigurationPropertySourcesPropertySource 的地方： + + + +可以看到，ConfigurationPropertySourcesPropertySource 类是由 ConfigurationPropertySources 的 attach 方法实例化的。查阅源码可以发现，这个方法的确从环境中获得了原始的 MutablePropertySources，把自己加入成为一个元素： + +public final class ConfigurationPropertySources { + + public static void attach(Environment environment) { + MutablePropertySources sources = ((ConfigurableEnvironment) environment).getPropertySources(); + PropertySource attached = sources.get(ATTACHED_PROPERTY_SOURCE_NAME); + if (attached == null) { + sources.addFirst(new ConfigurationPropertySourcesPropertySource(ATTACHED_PROPERTY_SOURCE_NAME, + new SpringConfigurationPropertySources(sources))); + } + } +} + + +而这个 attach 方法，是 Spring 应用程序启动时准备环境的时候调用的。在 SpringApplication 的 run 方法中调用了 prepareEnvironment 方法，然后又调用了 ConfigurationPropertySources.attach 方法： + +public class SpringApplication { + +public ConfigurableApplicationContext run(String... args) { + ... + try { + ApplicationArguments applicationArguments = new DefaultApplicationArguments(args); + ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments); + ... + } + + private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners, + ApplicationArguments applicationArguments) { + ... + ConfigurationPropertySources.attach(environment); + ... + } +} + + +看到这里你是否彻底理清楚 Spring 劫持 PropertySourcesPropertyResolver 的实现方式，以及配置源有优先级的原因了呢？如果你想知道 Spring 各种预定义的配置源的优先级，可以参考官方文档。 + +重点回顾 + +今天，我用两个业务开发中的实际案例，带你进一步学习了 Spring 的 AOP 和配置优先级这两大知识点。现在，你应该也感受到 Spring 实现的复杂度了。 + +对于 AOP 切 Feign 的案例，我们在实现功能时走了一些弯路。Spring Cloud 会使用 Spring Boot 的特性，根据当前引入包的情况做各种自动装配。如果我们要扩展 Spring 的组件，那么只有清晰了解 Spring 自动装配的运作方式，才能鉴别运行时对象在 Spring 容器中的情况，不能想当然认为代码中能看到的所有 Spring 的类都是 Bean。 + +对于配置优先级的案例，分析配置源优先级时，如果我们以为看到 PropertySourcesPropertyResolver 就看到了真相，后续进行扩展开发时就可能会踩坑。我们一定要注意，分析 Spring 源码时，你看到的表象不一定是实际运行时的情况，还需要借助日志或调试工具来理清整个过程。如果没有调试工具，你可以借助第 11 讲用到的 Arthas，来分析代码调用路径。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +除了我们这两讲用到 execution、within、@within、@annotation 四个指示器外，Spring AOP 还支持 this、target、args、@target、@args。你能说说后面五种指示器的作用吗？ + +Spring 的 Environment 中的 PropertySources 属性可以包含多个 PropertySource，越往前优先级越高。那，我们能否利用这个特点实现配置文件中属性值的自动赋值呢？比如，我们可以定义 %%MYSQL.URL%%、%%MYSQL.USERNAME%% 和 %%MYSQL.PASSWORD%%，分别代表数据库连接字符串、用户名和密码。在配置数据源时，我们只要设置其值为占位符，框架就可以自动根据当前应用程序名 application.name，统一把占位符替换为真实的数据库信息。这样，生产的数据库信息就不需要放在配置文件中了，会更安全。 + +关于 Spring Core、Spring Boot 和 Spring Cloud，你还遇到过其他坑吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/21代码重复：搞定代码重复的三个绝招.md b/专栏/Java业务开发常见错误100例/21代码重复：搞定代码重复的三个绝招.md new file mode 100644 index 0000000..8e8e965 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/21代码重复：搞定代码重复的三个绝招.md @@ -0,0 +1,729 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 21 代码重复：搞定代码重复的三个绝招 + 今天，我来和你聊聊搞定代码重复的三个绝招。 + +业务同学抱怨业务开发没有技术含量，用不到设计模式、Java 高级特性、OOP，平时写代码都在堆 CRUD，个人成长无从谈起。每次面试官问到“请说说平时常用的设计模式”，都只能答单例模式，因为其他设计模式的确是听过但没用过；对于反射、注解之类的高级特性，也只是知道它们在写框架的时候非常常用，但自己又不写框架代码，没有用武之地。 + +其实，我认为不是这样的。设计模式、OOP 是前辈们在大型项目中积累下来的经验，通过这些方法论来改善大型项目的可维护性。反射、注解、泛型等高级特性在框架中大量使用的原因是，框架往往需要以同一套算法来应对不同的数据结构，而这些特性可以帮助减少重复代码，提升项目可维护性。 + +在我看来，可维护性是大型项目成熟度的一个重要指标，而提升可维护性非常重要的一个手段就是减少代码重复。那为什么这样说呢？ + +如果多处重复代码实现完全相同的功能，很容易修改一处忘记修改另一处，造成 Bug； + +有一些代码并不是完全重复，而是相似度很高，修改这些类似的代码容易改（复制粘贴）错，把原本有区别的地方改为了一样。 + +今天，我就从业务代码中最常见的三个需求展开，和你聊聊如何使用 Java 中的一些高级特性、设计模式，以及一些工具消除重复代码，才能既优雅又高端。通过今天的学习，也希望改变你对业务代码没有技术含量的看法。 + +利用工厂模式 + 模板方法模式，消除 if…else 和重复代码 + +假设要开发一个购物车下单的功能，针对不同用户进行不同处理： + +普通用户需要收取运费，运费是商品价格的 10%，无商品折扣； + +VIP 用户同样需要收取商品价格 10% 的快递费，但购买两件以上相同商品时，第三件开始享受一定折扣； + +内部用户可以免运费，无商品折扣。 + +我们的目标是实现三种类型的购物车业务逻辑，把入参 Map 对象（Key 是商品 ID，Value 是商品数量），转换为出参购物车类型 Cart。 + +先实现针对普通用户的购物车处理逻辑： + +//购物车 +@Data +public class Cart { + + //商品清单 + private List items = new ArrayList<>(); + + //总优惠 + private BigDecimal totalDiscount; + + //商品总价 + private BigDecimal totalItemPrice; + + //总运费 + private BigDecimal totalDeliveryPrice; + + //应付总价 + private BigDecimal payPrice; + +} + +//购物车中的商品 +@Data +public class Item { + + //商品ID + private long id; + + //商品数量 + private int quantity; + + //商品单价 + private BigDecimal price; + + //商品优惠 + private BigDecimal couponPrice; + + //商品运费 + private BigDecimal deliveryPrice; + +} + +//普通用户购物车处理 +public class NormalUserCart { + + public Cart process(long userId, Map items) { + Cart cart = new Cart(); + //把Map的购物车转换为Item列表 + List itemList = new ArrayList<>(); + items.entrySet().stream().forEach(entry -> { + Item item = new Item(); + item.setId(entry.getKey()); + item.setPrice(Db.getItemPrice(entry.getKey())); + item.setQuantity(entry.getValue()); + itemList.add(item); + }); + cart.setItems(itemList); + //处理运费和商品优惠 + itemList.stream().forEach(item -> { + //运费为商品总价的10% + item.setDeliveryPrice(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())).multiply(new BigDecimal("0.1"))); + //无优惠 + item.setCouponPrice(BigDecimal.ZERO); + }); + + //计算商品总价 + cart.setTotalItemPrice(cart.getItems().stream().map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))).reduce(BigDecimal.ZERO, BigDecimal::add)); + + //计算运费总价 + cart.setTotalDeliveryPrice(cart.getItems().stream().map(Item::getDeliveryPrice).reduce(BigDecimal.ZERO, BigDecimal::add)); + + //计算总优惠 + cart.setTotalDiscount(cart.getItems().stream().map(Item::getCouponPrice).reduce(BigDecimal.ZERO, BigDecimal::add)); + + //应付总价=商品总价+运费总价-总优惠 + cart.setPayPrice(cart.getTotalItemPrice().add(cart.getTotalDeliveryPrice()).subtract(cart.getTotalDiscount())); + return cart; + } +} + + +然后实现针对 VIP 用户的购物车逻辑。与普通用户购物车逻辑的不同在于，VIP 用户能享受同类商品多买的折扣。所以，这部分代码只需要额外处理多买折扣部分： + +public class VipUserCart { + public Cart process(long userId, Map items) { + ... + + itemList.stream().forEach(item -> { + + //运费为商品总价的10% + item.setDeliveryPrice(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())).multiply(new BigDecimal("0.1"))); + //购买两件以上相同商品，第三件开始享受一定折扣 + if (item.getQuantity() > 2) { + item.setCouponPrice(item.getPrice() + .multiply(BigDecimal.valueOf(100 - Db.getUserCouponPercent(userId)).divide(new BigDecimal("100"))) + .multiply(BigDecimal.valueOf(item.getQuantity() - 2))); + } else { + item.setCouponPrice(BigDecimal.ZERO); + } + }); + ... + return cart; + } +} + + +最后是免运费、无折扣的内部用户，同样只是处理商品折扣和运费时的逻辑差异： + +public class InternalUserCart { + + public Cart process(long userId, Map items) { + ... + itemList.stream().forEach(item -> { + //免运费 + item.setDeliveryPrice(BigDecimal.ZERO); + //无优惠 + item.setCouponPrice(BigDecimal.ZERO); + }); + ... + return cart; + } +} + + +对比一下代码量可以发现，三种购物车 70% 的代码是重复的。原因很简单，虽然不同类型用户计算运费和优惠的方式不同，但整个购物车的初始化、统计总价、总运费、总优惠和支付价格的逻辑都是一样的。 + +正如我们开始时提到的，代码重复本身不可怕，可怕的是漏改或改错。比如，写 VIP 用户购物车的同学发现商品总价计算有 Bug，不应该是把所有 Item 的 price 加在一起，而是应该把所有 Item 的 price*quantity 加在一起。这时，他可能会只修改 VIP 用户购物车的代码，而忽略了普通用户、内部用户的购物车中，重复的逻辑实现也有相同的 Bug。 + +有了三个购物车后，我们就需要根据不同的用户类型使用不同的购物车了。如下代码所示，使用三个 if 实现不同类型用户调用不同购物车的 process 方法： + +@GetMapping("wrong") +public Cart wrong(@RequestParam("userId") int userId) { + + //根据用户ID获得用户类型 + String userCategory = Db.getUserCategory(userId); + + //普通用户处理逻辑 + if (userCategory.equals("Normal")) { + NormalUserCart normalUserCart = new NormalUserCart(); + return normalUserCart.process(userId, items); + } + + //VIP用户处理逻辑 + if (userCategory.equals("Vip")) { + VipUserCart vipUserCart = new VipUserCart(); + return vipUserCart.process(userId, items); + } + + //内部用户处理逻辑 + if (userCategory.equals("Internal")) { + InternalUserCart internalUserCart = new InternalUserCart(); + return internalUserCart.process(userId, items); + } + return null; +} + + +电商的营销玩法是多样的，以后势必还会有更多用户类型，需要更多的购物车。我们就只能不断增加更多的购物车类，一遍一遍地写重复的购物车逻辑、写更多的 if 逻辑吗？ + +当然不是，相同的代码应该只在一处出现！ + +如果我们熟记抽象类和抽象方法的定义的话，这时或许就会想到，是否可以把重复的逻辑定义在抽象类中，三个购物车只要分别实现不同的那份逻辑呢？ + +其实，这个模式就是模板方法模式。我们在父类中实现了购物车处理的流程模板，然后把需要特殊处理的地方留空白也就是留抽象方法定义，让子类去实现其中的逻辑。由于父类的逻辑不完整无法单独工作，因此需要定义为抽象类。 + +如下代码所示，AbstractCart 抽象类实现了购物车通用的逻辑，额外定义了两个抽象方法让子类去实现。其中，processCouponPrice 方法用于计算商品折扣，processDeliveryPrice 方法用于计算运费。 + +public abstract class AbstractCart { + + //处理购物车的大量重复逻辑在父类实现 + public Cart process(long userId, Map items) { + + Cart cart = new Cart(); + List itemList = new ArrayList<>(); + items.entrySet().stream().forEach(entry -> { + Item item = new Item(); + item.setId(entry.getKey()); + item.setPrice(Db.getItemPrice(entry.getKey())); + item.setQuantity(entry.getValue()); + itemList.add(item); + }); + cart.setItems(itemList); + //让子类处理每一个商品的优惠 + itemList.stream().forEach(item -> { + processCouponPrice(userId, item); + processDeliveryPrice(userId, item); + }); + //计算商品总价 + cart.setTotalItemPrice(cart.getItems().stream().map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))).reduce(BigDecimal.ZERO, BigDecimal::add)); + + //计算总运费 + cart.setTotalDeliveryPrice(cart.getItems().stream().map(Item::getDeliveryPrice).reduce(BigDecimal.ZERO, BigDecimal::add)); + + //计算总折扣 + cart.setTotalDiscount(cart.getItems().stream().map(Item::getCouponPrice).reduce(BigDecimal.ZERO, BigDecimal::add)); + + //计算应付价格 + cart.setPayPrice(cart.getTotalItemPrice().add(cart.getTotalDeliveryPrice()).subtract(cart.getTotalDiscount())); + + return cart; + } + + //处理商品优惠的逻辑留给子类实现 + protected abstract void processCouponPrice(long userId, Item item); + + //处理配送费的逻辑留给子类实现 + protected abstract void processDeliveryPrice(long userId, Item item); +} + + +有了这个抽象类，三个子类的实现就非常简单了。普通用户的购物车 NormalUserCart，实现的是 0 优惠和 10% 运费的逻辑： + +@Service(value = "NormalUserCart") +public class NormalUserCart extends AbstractCart { + + @Override + protected void processCouponPrice(long userId, Item item) { + item.setCouponPrice(BigDecimal.ZERO); + } + + @Override + protected void processDeliveryPrice(long userId, Item item) { + item.setDeliveryPrice(item.getPrice() + .multiply(BigDecimal.valueOf(item.getQuantity())) + .multiply(new BigDecimal("0.1"))); + } +} + + +VIP 用户的购物车 VipUserCart，直接继承了 NormalUserCart，只需要修改多买优惠策略： + +@Service(value = "VipUserCart") +public class VipUserCart extends NormalUserCart { + + @Override + protected void processCouponPrice(long userId, Item item) { + if (item.getQuantity() > 2) { + item.setCouponPrice(item.getPrice() + .multiply(BigDecimal.valueOf(100 - Db.getUserCouponPercent(userId)).divide(new BigDecimal("100"))) + .multiply(BigDecimal.valueOf(item.getQuantity() - 2))); + } else { + item.setCouponPrice(BigDecimal.ZERO); + } + } +} + + +内部用户购物车 InternalUserCart 是最简单的，直接设置 0 运费和 0 折扣即可： + +@Service(value = "InternalUserCart") +public class InternalUserCart extends AbstractCart { + + @Override + protected void processCouponPrice(long userId, Item item) { + item.setCouponPrice(BigDecimal.ZERO); + } + + @Override + protected void processDeliveryPrice(long userId, Item item) { + item.setDeliveryPrice(BigDecimal.ZERO); + } +} + + +抽象类和三个子类的实现关系图，如下所示： + + + +是不是比三个独立的购物车程序简单了很多呢？接下来，我们再看看如何能避免三个 if 逻辑。 + +或许你已经注意到了，定义三个购物车子类时，我们在 @Service 注解中对 Bean 进行了命名。既然三个购物车都叫 XXXUserCart，那我们就可以把用户类型字符串拼接 UserCart 构成购物车 Bean 的名称，然后利用 Spring 的 IoC 容器，通过 Bean 的名称直接获取到 AbstractCart，调用其 process 方法即可实现通用。 + +其实，这就是工厂模式，只不过是借助 Spring 容器实现罢了： + +@GetMapping("right") +public Cart right(@RequestParam("userId") int userId) { + String userCategory = Db.getUserCategory(userId); + AbstractCart cart = (AbstractCart) applicationContext.getBean(userCategory + "UserCart"); + return cart.process(userId, items); +} + + +试想， 之后如果有了新的用户类型、新的用户逻辑，是不是完全不用对代码做任何修改，只要新增一个 XXXUserCart 类继承 AbstractCart，实现特殊的优惠和运费处理逻辑就可以了？ + +这样一来，我们就利用工厂模式 + 模板方法模式，不仅消除了重复代码，还避免了修改既有代码的风险。这就是设计模式中的开闭原则：对修改关闭，对扩展开放。 + +利用注解 + 反射消除重复代码 + +是不是有点兴奋了，业务代码居然也能 OOP 了。我们再看一个三方接口的调用案例，同样也是一个普通的业务逻辑。 + +假设银行提供了一些 API 接口，对参数的序列化有点特殊，不使用 JSON，而是需要我们把参数依次拼在一起构成一个大字符串。 + +按照银行提供的 API 文档的顺序，把所有参数构成定长的数据，然后拼接在一起作为整个字符串。 + +因为每一种参数都有固定长度，未达到长度时需要做填充处理： + +字符串类型的参数不满长度部分需要以下划线右填充，也就是字符串内容靠左； + +数字类型的参数不满长度部分以 0 左填充，也就是实际数字靠右； + +货币类型的表示需要把金额向下舍入 2 位到分，以分为单位，作为数字类型同样进行左填充。 + +对所有参数做 MD5 操作作为签名（为了方便理解，Demo 中不涉及加盐处理）。 + +比如，创建用户方法和支付方法的定义是这样的： + + + + + +代码很容易实现，直接根据接口定义实现填充操作、加签名、请求调用操作即可： + +public class BankService { + + //创建用户方法 + public static String createUser(String name, String identity, String mobile, int age) throws IOException { + StringBuilder stringBuilder = new StringBuilder(); + //字符串靠左，多余的地方填充_ + stringBuilder.append(String.format("%-10s", name).replace(' ', '_')); + //字符串靠左，多余的地方填充_ + stringBuilder.append(String.format("%-18s", identity).replace(' ', '_')); + //数字靠右，多余的地方用0填充 + stringBuilder.append(String.format("%05d", age)); + //字符串靠左，多余的地方用_填充 + stringBuilder.append(String.format("%-11s", mobile).replace(' ', '_')); + //最后加上MD5作为签名 + stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString())); + return Request.Post("http://localhost:45678/reflection/bank/createUser") + .bodyString(stringBuilder.toString(), ContentType.APPLICATION_JSON) + .execute().returnContent().asString(); + } + //支付方法 + public static String pay(long userId, BigDecimal amount) throws IOException { + + StringBuilder stringBuilder = new StringBuilder(); + + //数字靠右，多余的地方用0填充 + stringBuilder.append(String.format("%020d", userId)); + + //金额向下舍入2位到分，以分为单位，作为数字靠右，多余的地方用0填充 + stringBuilder.append(String.format("%010d", amount.setScale(2, RoundingMode.DOWN).multiply(new BigDecimal("100")).longValue())); + + //最后加上MD5作为签名 + stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString())); + + return Request.Post("http://localhost:45678/reflection/bank/pay") + .bodyString(stringBuilder.toString(), ContentType.APPLICATION_JSON) + .execute().returnContent().asString(); + } +} + + +可以看到，这段代码的重复粒度更细： + +三种标准数据类型的处理逻辑有重复，稍有不慎就会出现 Bug； + +处理流程中字符串拼接、加签和发请求的逻辑，在所有方法重复； + +实际方法的入参的参数类型和顺序，不一定和接口要求一致，容易出错； + +代码层面针对每一个参数硬编码，无法清晰地进行核对，如果参数达到几十个、上百个，出错的概率极大。 + +那应该如何改造这段代码呢？没错，就是要用注解和反射！ + +使用注解和反射这两个武器，就可以针对银行请求的所有逻辑均使用一套代码实现，不会出现任何重复。 + +要实现接口逻辑和逻辑实现的剥离，首先需要以 POJO 类（只有属性没有任何业务逻辑的数据类）的方式定义所有的接口参数。比如，下面这个创建用户 API 的参数： + +@Data +public class CreateUserAPI { + + private String name; + private String identity; + private String mobile; + private int age; +} + + +有了接口参数定义，我们就能通过自定义注解为接口和所有参数增加一些元数据。如下所示，我们定义一个接口 API 的注解 BankAPI，包含接口 URL 地址和接口说明： + +@Retention(RetentionPolicy.RUNTIME) +@Target(ElementType.TYPE) +@Documented +@Inherited +public @interface BankAPI { + + String desc() default ""; + String url() default ""; +} + + +然后，我们再定义一个自定义注解 @BankAPIField，用于描述接口的每一个字段规范，包含参数的次序、类型和长度三个属性： + +@Retention(RetentionPolicy.RUNTIME) +@Target(ElementType.FIELD) +@Documented +@Inherited +public @interface BankAPIField { + + int order() default -1; + int length() default -1; + String type() default ""; +} + + +接下来，注解就可以发挥威力了。 + +如下所示，我们定义了 CreateUserAPI 类描述创建用户接口的信息，通过为接口增加 @BankAPI 注解，来补充接口的 URL 和描述等元数据；通过为每一个字段增加 @BankAPIField 注解，来补充参数的顺序、类型和长度等元数据： + +@BankAPI(url = "/bank/createUser", desc = "创建用户接口") +@Data +public class CreateUserAPI extends AbstractAPI { + + @BankAPIField(order = 1, type = "S", length = 10) + private String name; + + @BankAPIField(order = 2, type = "S", length = 18) + private String identity; + + @BankAPIField(order = 4, type = "S", length = 11) //注意这里的order需要按照API表格中的顺序 + private String mobile; + + @BankAPIField(order = 3, type = "N", length = 5) + private int age; +} + + +另一个 PayAPI 类也是类似的实现： + +@BankAPI(url = "/bank/pay", desc = "支付接口") +@Data +public class PayAPI extends AbstractAPI { + + @BankAPIField(order = 1, type = "N", length = 20) + private long userId; + + @BankAPIField(order = 2, type = "M", length = 10) + private BigDecimal amount; +} + + +这 2 个类继承的 AbstractAPI 类是一个空实现，因为这个案例中的接口并没有公共数据可以抽象放到基类。 + +通过这 2 个类，我们可以在几秒钟内完成和 API 清单表格的核对。理论上，如果我们的核心翻译过程（也就是把注解和接口 API 序列化为请求需要的字符串的过程）没问题，只要注解和表格一致，API 请求的翻译就不会有任何问题。 + +以上，我们通过注解实现了对 API 参数的描述。接下来，我们再看看反射如何配合注解实现动态的接口参数组装： + +第 3 行代码中，我们从类上获得了 BankAPI 注解，然后拿到其 URL 属性，后续进行远程调用。 + +第 6~9 行代码，使用 stream 快速实现了获取类中所有带 BankAPIField 注解的字段，并把字段按 order 属性排序，然后设置私有字段反射可访问。 + +第 12~38 行代码，实现了反射获取注解的值，然后根据 BankAPIField 拿到的参数类型，按照三种标准进行格式化，将所有参数的格式化逻辑集中在了这一处。 + +第 41~48 行代码，实现了参数加签和请求调用。 + +private static String remoteCall(AbstractAPI api) throws IOException { + + //从BankAPI注解获取请求地址 + BankAPI bankAPI = api.getClass().getAnnotation(BankAPI.class); + bankAPI.url(); + + StringBuilder stringBuilder = new StringBuilder(); + Arrays.stream(api.getClass().getDeclaredFields()) //获得所有字段 + .filter(field -> field.isAnnotationPresent(BankAPIField.class)) //查找标记了注解的字段 + .sorted(Comparator.comparingInt(a -> a.getAnnotation(BankAPIField.class).order())) //根据注解中的order对字段排序 + .peek(field -> field.setAccessible(true)) //设置可以访问私有字段 + .forEach(field -> { + //获得注解 + BankAPIField bankAPIField = field.getAnnotation(BankAPIField.class); + Object value = ""; + try { + //反射获取字段值 + value = field.get(api); + } catch (IllegalAccessException e) { + e.printStackTrace(); + } + //根据字段类型以正确的填充方式格式化字符串 + switch (bankAPIField.type()) { + case "S": { + stringBuilder.append(String.format("%-" + bankAPIField.length() + "s", value.toString()).replace(' ', '_')); + break; + } + case "N": { + stringBuilder.append(String.format("%" + bankAPIField.length() + "s", value.toString()).replace(' ', '0')); + break; + } + case "M": { + if (!(value instanceof BigDecimal)) + throw new RuntimeException(String.format("{} 的 {} 必须是BigDecimal", api, field)); + stringBuilder.append(String.format("%0" + bankAPIField.length() + "d", ((BigDecimal) value).setScale(2, RoundingMode.DOWN).multiply(new BigDecimal("100")).longValue())); + break; + } + default: + break; + } + }); + //签名逻辑 + stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString())); + String param = stringBuilder.toString(); + long begin = System.currentTimeMillis(); + //发请求 + String result = Request.Post("http://localhost:45678/reflection" + bankAPI.url()) + .bodyString(param, ContentType.APPLICATION_JSON) + .execute().returnContent().asString(); + log.info("调用银行API {} url:{} 参数:{} 耗时:{}ms", bankAPI.desc(), bankAPI.url(), param, System.currentTimeMillis() - begin); + return result; + +} + + +可以看到，所有处理参数排序、填充、加签、请求调用的核心逻辑，都汇聚在了 remoteCall 方法中。有了这个核心方法，BankService 中每一个接口的实现就非常简单了，只是参数的组装，然后调用 remoteCall 即可。 + +//创建用户方法 +public static String createUser(String name, String identity, String mobile, int age) throws IOException { + + CreateUserAPI createUserAPI = new CreateUserAPI(); + + createUserAPI.setName(name); + + createUserAPI.setIdentity(identity); + + createUserAPI.setAge(age); + + createUserAPI.setMobile(mobile); + + return remoteCall(createUserAPI); +} + +//支付方法 +public static String pay(long userId, BigDecimal amount) throws IOException { + + PayAPI payAPI = new PayAPI(); + + payAPI.setUserId(userId); + + payAPI.setAmount(amount); + + return remoteCall(payAPI); +} + + +其实，许多涉及类结构性的通用处理，都可以按照这个模式来减少重复代码。反射给予了我们在不知晓类结构的时候，按照固定的逻辑处理类的成员；而注解给了我们为这些成员补充元数据的能力，使得我们利用反射实现通用逻辑的时候，可以从外部获得更多我们关心的数据。 + +利用属性拷贝工具消除重复代码 + +最后，我们再来看一种业务代码中经常出现的代码逻辑，实体之间的转换复制。 + +对于三层架构的系统，考虑到层之间的解耦隔离以及每一层对数据的不同需求，通常每一层都会有自己的 POJO 作为数据实体。比如，数据访问层的实体一般叫作 DataObject 或 DO，业务逻辑层的实体一般叫作 Domain，表现层的实体一般叫作 Data Transfer Object 或 DTO。 + +这里我们需要注意的是，如果手动写这些实体之间的赋值代码，同样容易出错。 + +对于复杂的业务系统，实体有几十甚至几百个属性也很正常。就比如 ComplicatedOrderDTO 这个数据传输对象，描述的是一个订单中的几十个属性。如果我们要把这个 DTO 转换为一个类似的 DO，复制其中大部分的字段，然后把数据入库，势必需要进行很多属性映射赋值操作。就像这样，密密麻麻的代码是不是已经让你头晕了？ + +ComplicatedOrderDTO orderDTO = new ComplicatedOrderDTO(); + +ComplicatedOrderDO orderDO = new ComplicatedOrderDO(); + +orderDO.setAcceptDate(orderDTO.getAcceptDate()); + +orderDO.setAddress(orderDTO.getAddress()); + +orderDO.setAddressId(orderDTO.getAddressId()); + +orderDO.setCancelable(orderDTO.isCancelable()); + +orderDO.setCommentable(orderDTO.isComplainable()); //属性错误 + +orderDO.setComplainable(orderDTO.isCommentable()); //属性错误 + +orderDO.setCancelable(orderDTO.isCancelable()); + +orderDO.setCouponAmount(orderDTO.getCouponAmount()); + +orderDO.setCouponId(orderDTO.getCouponId()); + +orderDO.setCreateDate(orderDTO.getCreateDate()); + +orderDO.setDirectCancelable(orderDTO.isDirectCancelable()); + +orderDO.setDeliverDate(orderDTO.getDeliverDate()); + +orderDO.setDeliverGroup(orderDTO.getDeliverGroup()); + +orderDO.setDeliverGroupOrderStatus(orderDTO.getDeliverGroupOrderStatus()); + +orderDO.setDeliverMethod(orderDTO.getDeliverMethod()); + +orderDO.setDeliverPrice(orderDTO.getDeliverPrice()); + +orderDO.setDeliveryManId(orderDTO.getDeliveryManId()); + +orderDO.setDeliveryManMobile(orderDO.getDeliveryManMobile()); //对象错误 + +orderDO.setDeliveryManName(orderDTO.getDeliveryManName()); + +orderDO.setDistance(orderDTO.getDistance()); + +orderDO.setExpectDate(orderDTO.getExpectDate()); + +orderDO.setFirstDeal(orderDTO.isFirstDeal()); + +orderDO.setHasPaid(orderDTO.isHasPaid()); + +orderDO.setHeadPic(orderDTO.getHeadPic()); + +orderDO.setLongitude(orderDTO.getLongitude()); + +orderDO.setLatitude(orderDTO.getLongitude()); //属性赋值错误 + +orderDO.setMerchantAddress(orderDTO.getMerchantAddress()); + +orderDO.setMerchantHeadPic(orderDTO.getMerchantHeadPic()); + +orderDO.setMerchantId(orderDTO.getMerchantId()); + +orderDO.setMerchantAddress(orderDTO.getMerchantAddress()); + +orderDO.setMerchantName(orderDTO.getMerchantName()); + +orderDO.setMerchantPhone(orderDTO.getMerchantPhone()); + +orderDO.setOrderNo(orderDTO.getOrderNo()); + +orderDO.setOutDate(orderDTO.getOutDate()); + +orderDO.setPayable(orderDTO.isPayable()); + +orderDO.setPaymentAmount(orderDTO.getPaymentAmount()); + +orderDO.setPaymentDate(orderDTO.getPaymentDate()); + +orderDO.setPaymentMethod(orderDTO.getPaymentMethod()); + +orderDO.setPaymentTimeLimit(orderDTO.getPaymentTimeLimit()); + +orderDO.setPhone(orderDTO.getPhone()); + +orderDO.setRefundable(orderDTO.isRefundable()); + +orderDO.setRemark(orderDTO.getRemark()); + +orderDO.setStatus(orderDTO.getStatus()); + +orderDO.setTotalQuantity(orderDTO.getTotalQuantity()); + +orderDO.setUpdateTime(orderDTO.getUpdateTime()); + +orderDO.setName(orderDTO.getName()); + +orderDO.setUid(orderDTO.getUid()); + + +如果不是代码中有注释，你能看出其中的诸多问题吗？ + +如果原始的 DTO 有 100 个字段，我们需要复制 90 个字段到 DO 中，保留 10 个不赋值，最后应该如何校验正确性呢？数数吗？即使数出有 90 行代码，也不一定正确，因为属性可能重复赋值。 + +有的时候字段命名相近，比如 complainable 和 commentable，容易搞反（第 7 和第 8 行），或者对两个目标字段重复赋值相同的来源字段（比如第 28 行） + +明明要把 DTO 的值赋值到 DO 中，却在 set 的时候从 DO 自己取值（比如第 20 行），导致赋值无效。 + +这段代码并不是我随手写出来的，而是一个真实案例。有位同学就像代码中那样把经纬度赋值反了，因为落库的字段实在太多了。这个 Bug 很久都没发现，直到真正用到数据库中的经纬度做计算时，才发现一直以来都存错了。 + +修改方法很简单，可以使用类似 BeanUtils 这种 Mapping 工具来做 Bean 的转换，copyProperties 方法还允许我们提供需要忽略的属性： + +ComplicatedOrderDTO orderDTO = new ComplicatedOrderDTO(); +ComplicatedOrderDO orderDO = new ComplicatedOrderDO(); +BeanUtils.copyProperties(orderDTO, orderDO, "id"); +return orderDO; + + +重点回顾 + +正所谓“常在河边走哪有不湿鞋”，重复代码多了总有一天会出错。今天，我从几个最常见的维度，和你分享了几个实际业务场景中可能出现的重复问题，以及消除重复的方式。 + +第一种代码重复是，有多个并行的类实现相似的代码逻辑。我们可以考虑提取相同逻辑在父类中实现，差异逻辑通过抽象方法留给子类实现。使用类似的模板方法把相同的流程和逻辑固定成模板，保留差异的同时尽可能避免代码重复。同时，可以使用 Spring 的 IoC 特性注入相应的子类，来避免实例化子类时的大量 if…else 代码。 + +第二种代码重复是，使用硬编码的方式重复实现相同的数据处理算法。我们可以考虑把规则转换为自定义注解，作为元数据对类或对字段、方法进行描述，然后通过反射动态读取这些元数据、字段或调用方法，实现规则参数和规则定义的分离。也就是说，把变化的部分也就是规则的参数放入注解，规则的定义统一处理。 + +第三种代码重复是，业务代码中常见的 DO、DTO、VO 转换时大量字段的手动赋值，遇到有上百个属性的复杂类型，非常非常容易出错。我的建议是，不要手动进行赋值，考虑使用 Bean 映射工具进行。此外，还可以考虑采用单元测试对所有字段进行赋值正确性校验。 + +最后，我想说的是，我会把代码重复度作为评估一个项目质量的重要指标，如果一个项目几乎没有任何重复代码，那么它内部的抽象一定是非常好的。在做项目重构的时候，你也可以以消除重复为第一目标去考虑实现。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +除了模板方法设计模式是减少重复代码的一把好手，观察者模式也常用于减少代码重复（并且是松耦合方式）。Spring 也提供了类似工具（点击这里查看），你能想到有哪些应用场景吗？ + +关于 Bean 属性复制工具，除了最简单的 Spring 的 BeanUtils 工具类的使用，你还知道哪些对象映射类库吗？它们又有什么功能呢？ + +你还有哪些消除重复代码的心得和方法吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/22接口设计：系统间对话的语言，一定要统一.md b/专栏/Java业务开发常见错误100例/22接口设计：系统间对话的语言，一定要统一.md new file mode 100644 index 0000000..b30d450 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/22接口设计：系统间对话的语言，一定要统一.md @@ -0,0 +1,896 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 22 接口设计：系统间对话的语言，一定要统一 + 今天，我要和你分享的主题是，在做接口设计时一定要确保系统之间对话的语言是统一的。 + +我们知道，开发一个服务的第一步就是设计接口。接口的设计需要考虑的点非常多，比如接口的命名、参数列表、包装结构体、接口粒度、版本策略、幂等性实现、同步异步处理方式等。 + +这其中，和接口设计相关比较重要的点有三个，分别是包装结构体、版本策略、同步异步处理方式。今天，我就通过我遇到的实际案例，和你一起看看因为接口设计思路和调用方理解不一致所导致的问题，以及相关的实践经验。 + +接口的响应要明确表示接口的处理结果 + +我曾遇到过一个处理收单的收单中心项目，下单接口返回的响应体中，包含了 success、code、info、message 等属性，以及二级嵌套对象 data 结构体。在对项目进行重构的时候，我们发现真的是无从入手，接口缺少文档，代码一有改动就出错。 + +有时候，下单操作的响应结果是这样的：success 是 true、message 是 OK，貌似代表下单成功了；但 info 里却提示订单存在风险，code 是一个 5001 的错误码，data 中能看到订单状态是 Cancelled，订单 ID 是 -1，好像又说明没有下单成功。 + +{ + + "success": true, + + "code": 5001, + + "info": "Risk order detected", + + "message": "OK", + + "data": { + + "orderStatus": "Cancelled", + + "orderId": -1 + + } + +} + + + +有些时候，这个下单接口又会返回这样的结果：success 是 false，message 提示非法用户 ID，看上去下单失败；但 data 里的 orderStatus 是 Created、info 是空、code 是 0。那么，这次下单到底是成功还是失败呢？ + +{ + + "success": false, + + "code": 0, + + "info": "", + + "message": "Illegal userId", + + "data": { + + "orderStatus": "Created", + + "orderId": 0 + + } + +} + + +这样的结果，让我们非常疑惑： + +结构体的 code 和 HTTP 响应状态码，是什么关系？ + +success 到底代表下单成功还是失败？ + +info 和 message 的区别是什么？ + +data 中永远都有数据吗？什么时候应该去查询 data？ + +造成如此混乱的原因是：这个收单服务本身并不真正处理下单操作，只是做一些预校验和预处理；真正的下单操作，需要在收单服务内部调用另一个订单服务来处理；订单服务处理完成后，会返回订单状态和 ID。 + +在一切正常的情况下，下单后的订单状态就是已创建 Created，订单 ID 是一个大于 0 的数字。而结构体中的 message 和 success，其实是收单服务的处理异常信息和处理成功与否的结果，code、info 是调用订单服务的结果。 + +对于第一次调用，收单服务自己没问题，success 是 true，message 是 OK，但调用订单服务时却因为订单风险问题被拒绝，所以 code 是 5001，info 是 Risk order detected，data 中的信息是订单服务返回的，所以最终订单状态是 Cancelled。 + +对于第二次调用，因为用户 ID 非法，所以收单服务在校验了参数后直接就返回了 success 是 false，message 是 Illegal userId。因为请求没有到订单服务，所以 info、code、data 都是默认值，订单状态的默认值是 Created。因此，第二次下单肯定失败了，但订单状态却是已创建。 + +可以看到，如此混乱的接口定义和实现方式，是无法让调用者分清到底应该怎么处理的。为了将接口设计得更合理，我们需要考虑如下两个原则： + +对外隐藏内部实现。虽然说收单服务调用订单服务进行真正的下单操作，但是直接接口其实是收单服务提供的，收单服务不应该“直接”暴露其背后订单服务的状态码、错误描述。 + +设计接口结构时，明确每个字段的含义，以及客户端的处理方式。 + +基于这两个原则，我们调整一下返回结构体，去掉外层的 info，即不再把订单服务的调用结果告知客户端： + +@Data + +public class APIResponse { + + private boolean success; + + private T data; + + private int code; + + private String message; + +} + + + +并明确接口的设计逻辑： + +如果出现非 200 的 HTTP 响应状态码，就代表请求没有到收单服务，可能是网络出问题、网络超时，或者网络配置的问题。这时，肯定无法拿到服务端的响应体，客户端可以给予友好提示，比如让用户重试，不需要继续解析响应结构体。 + +如果 HTTP 响应码是 200，解析响应体查看 success，为 false 代表下单请求处理失败，可能是因为收单服务参数验证错误，也可能是因为订单服务下单操作失败。这时，根据收单服务定义的错误码表和 code，做不同处理。比如友好提示，或是让用户重新填写相关信息，其中友好提示的文字内容可以从 message 中获取。 + +success 为 true 的情况下，才需要继续解析响应体中的 data 结构体。data 结构体代表了业务数据，通常会有下面两种情况。 + +通常情况下，success 为 true 时订单状态是 Created，获取 orderId 属性可以拿到订单号。 + +特殊情况下，比如收单服务内部处理不当，或是订单服务出现了额外的状态，虽然 success 为 true，但订单实际状态不是 Created，这时可以给予友好的错误提示。 + + + +明确了接口的设计逻辑，我们就是可以实现收单服务的服务端和客户端来模拟这些情况了。 + +首先，实现服务端的逻辑： + +@GetMapping("server") + +public APIResponse server(@RequestParam("userId") Long userId) { + + APIResponse response = new APIResponse<>(); + + if (userId == null) { + + //对于userId为空的情况，收单服务直接处理失败，给予相应的错误码和错误提示 + + response.setSuccess(false); + + response.setCode(3001); + + response.setMessage("Illegal userId"); + + } else if (userId == 1) { + + //对于userId=1的用户，模拟订单服务对于风险用户的情况 + + response.setSuccess(false); + + //把订单服务返回的错误码转换为收单服务错误码 + + response.setCode(3002); + + response.setMessage("Internal Error, order is cancelled"); + + //同时日志记录内部错误 + + log.warn("用户 {} 调用订单服务失败，原因是 Risk order detected", userId); + + } else { + + //其他用户，下单成功 + + response.setSuccess(true); + + response.setCode(2000); + + response.setMessage("OK"); + + response.setData(new OrderInfo("Created", 2L)); + + } + + return response; + +} + + + +客户端代码，则可以按照流程图上的逻辑来实现，同样模拟三种出错情况和正常下单的情况： + +error==1 的用例模拟一个不存在的 URL，请求无法到收单服务，会得到 404 的 HTTP 状态码，直接进行友好提示，这是第一层处理。 + + + +error==2 的用例模拟 userId 参数为空的情况，收单服务会因为缺少 userId 参数提示非法用户。这时，可以把响应体中的 message 展示给用户，这是第二层处理。 + + + +error==3 的用例模拟 userId 为 1 的情况，因为用户有风险，收单服务调用订单服务出错。处理方式和之前没有任何区别，因为收单服务会屏蔽订单服务的内部错误。 + + + +但在服务端可以看到如下错误信息： + +[14:13:13.951] [http-nio-45678-exec-8] [WARN ] [.c.a.d.APIThreeLevelStatusController:36 ] - 用户 1 调用订单服务失败，原因是 Risk order detected + + + +error==0 的用例模拟正常用户，下单成功。这时可以解析 data 结构体提取业务结果，作为兜底，需要判断订单状态，如果不是 Created 则给予友好提示，否则查询 orderId 获得下单的订单号，这是第三层处理。 + + + +客户端的实现代码如下： + +@GetMapping("client") + +public String client(@RequestParam(value = "error", defaultValue = "0") int error) { + + String url = Arrays.asList("http://localhost:45678/apiresposne/server?userId=2", + + "http://localhost:45678/apiresposne/server2", + + "http://localhost:45678/apiresposne/server?userId=", + + "http://localhost:45678/apiresposne/server?userId=1").get(error); + + //第一层，先看状态码，如果状态码不是200，不处理响应体 + + String response = ""; + + try { + + response = Request.Get(url).execute().returnContent().asString(); + + } catch (HttpResponseException e) { + + log.warn("请求服务端出现返回非200", e); + + return "服务器忙，请稍后再试！"; + + } catch (IOException e) { + + e.printStackTrace(); + + } + + //状态码为200的情况下处理响应体 + + if (!response.equals("")) { + + try { + + APIResponse apiResponse = objectMapper.readValue(response, new TypeReference>() { + + }); + + //第二层，success是false直接提示用户 + + if (!apiResponse.isSuccess()) { + + return String.format("创建订单失败，请稍后再试，错误代码： %s 错误原因：%s", apiResponse.getCode(), apiResponse.getMessage()); + + } else { + + //第三层，往下解析OrderInfo + + OrderInfo orderInfo = apiResponse.getData(); + + if ("Created".equals(orderInfo.getStatus())) + + return String.format("创建订单成功，订单号是：%s，状态是：%s", orderInfo.getOrderId(), orderInfo.getStatus()); + + else + + return String.format("创建订单失败，请联系客服处理"); + + } + + } catch (JsonProcessingException e) { + + e.printStackTrace(); + + } + + } + + return ""; + +} + + + +相比原来混乱的接口定义和处理逻辑，改造后的代码，明确了接口每一个字段的含义，以及对于各种情况服务端的输出和客户端的处理步骤，对齐了客户端和服务端的处理逻辑。那么现在，你能回答前面那 4 个让人疑惑的问题了吗？ + +最后分享一个小技巧。为了简化服务端代码，我们可以把包装 API 响应体 APIResponse 的工作交由框架自动完成，这样直接返回 DTO OrderInfo 即可。对于业务逻辑错误，可以抛出一个自定义异常： + +@GetMapping("server") + +public OrderInfo server(@RequestParam("userId") Long userId) { + + if (userId == null) { + + throw new APIException(3001, "Illegal userId"); + + } + + if (userId == 1) { + + ... + + //直接抛出异常 + + throw new APIException(3002, "Internal Error, order is cancelled"); + + } + + //直接返回DTO + + return new OrderInfo("Created", 2L); + +} + + + +在 APIException 中包含错误码和错误消息： + +public class APIException extends RuntimeException { + + @Getter + + private int errorCode; + + @Getter + + private String errorMessage; + + public APIException(int errorCode, String errorMessage) { + + super(errorMessage); + + this.errorCode = errorCode; + + this.errorMessage = errorMessage; + + } + + public APIException(Throwable cause, int errorCode, String errorMessage) { + + super(errorMessage, cause); + + this.errorCode = errorCode; + + this.errorMessage = errorMessage; + + } + +} + + +然后，定义一个 @RestControllerAdvice 来完成自动包装响应体的工作： + +通过实现 ResponseBodyAdvice 接口的 beforeBodyWrite 方法，来处理成功请求的响应体转换。 + +实现一个 @ExceptionHandler 来处理业务异常时，APIException 到 APIResponse 的转换。 + +//此段代码只是Demo，生产级应用还需要扩展很多细节 + +@RestControllerAdvice + +@Slf4j + +public class APIResponseAdvice implements ResponseBodyAdvice { + + //自动处理APIException，包装为APIResponse + + @ExceptionHandler(APIException.class) + + public APIResponse handleApiException(HttpServletRequest request, APIException ex) { + + log.error("process url {} failed", request.getRequestURL().toString(), ex); + + APIResponse apiResponse = new APIResponse(); + + apiResponse.setSuccess(false); + + apiResponse.setCode(ex.getErrorCode()); + + apiResponse.setMessage(ex.getErrorMessage()); + + return apiResponse; + + } + + //仅当方法或类没有标记@NoAPIResponse才自动包装 + + @Override + + public boolean supports(MethodParameter returnType, Class converterType) { + + return returnType.getParameterType() != APIResponse.class + + && AnnotationUtils.findAnnotation(returnType.getMethod(), NoAPIResponse.class) == null + + && AnnotationUtils.findAnnotation(returnType.getDeclaringClass(), NoAPIResponse.class) == null; + + } + + //自动包装外层APIResposne响应 + + @Override + + public Object beforeBodyWrite(Object body, MethodParameter returnType, MediaType selectedContentType, Class> selectedConverterType, ServerHttpRequest request, ServerHttpResponse response) { + + APIResponse apiResponse = new APIResponse(); + + apiResponse.setSuccess(true); + + apiResponse.setMessage("OK"); + + apiResponse.setCode(2000); + + apiResponse.setData(body); + + return apiResponse; + + } + +} + + + +在这里，我们实现了一个 @NoAPIResponse 自定义注解。如果某些 @RestController 的接口不希望实现自动包装的话，可以标记这个注解： + +@Target({ElementType.METHOD, ElementType.TYPE}) + +@Retention(RetentionPolicy.RUNTIME) + +public @interface NoAPIResponse { + +} + + + +在 ResponseBodyAdvice 的 support 方法中，我们排除了标记有这个注解的方法或类的自动响应体包装。比如，对于刚才我们实现的测试客户端 client 方法不需要包装为 APIResponse，就可以标记上这个注解： + +@GetMapping("client") + +@NoAPIResponse + +public String client(@RequestParam(value = "error", defaultValue = "0") int error) + + + +这样我们的业务逻辑中就不需要考虑响应体的包装，代码会更简洁。 + +要考虑接口变迁的版本控制策略 + +接口不可能一成不变，需要根据业务需求不断增加内部逻辑。如果做大的功能调整或重构，涉及参数定义的变化或是参数废弃，导致接口无法向前兼容，这时接口就需要有版本的概念。在考虑接口版本策略设计时，我们需要注意的是，最好一开始就明确版本策略，并考虑在整个服务端统一版本策略。 + +第一，版本策略最好一开始就考虑。 + +既然接口总是要变迁的，那么最好一开始就确定版本策略。比如，确定是通过 URL Path 实现，是通过 QueryString 实现，还是通过 HTTP 头实现。这三种实现方式的代码如下： + +//通过URL Path实现版本控制 + +@GetMapping("/v1/api/user") + +public int right1(){ + + return 1; + +} + +//通过QueryString中的version参数实现版本控制 + +@GetMapping(value = "/api/user", params = "version=2") + +public int right2(@RequestParam("version") int version) { + + return 2; + +} + +//通过请求头中的X-API-VERSION参数实现版本控制 + +@GetMapping(value = "/api/user", headers = "X-API-VERSION=3") + +public int right3(@RequestHeader("X-API-VERSION") int version) { + + return 3; + +} + + + +这样，客户端就可以在配置中处理相关版本控制的参数，有可能实现版本的动态切换。 + +这三种方式中，URL Path 的方式最直观也最不容易出错；QueryString 不易携带，不太推荐作为公开 API 的版本策略；HTTP 头的方式比较没有侵入性，如果仅仅是部分接口需要进行版本控制，可以考虑这种方式。 + +第二，版本实现方式要统一。 + +之前，我就遇到过一个 O2O 项目，需要针对商品、商店和用户实现 REST 接口。虽然大家约定通过 URL Path 方式实现 API 版本控制，但实现方式不统一，有的是 /api/item/v1，有的是 /api/v1/shop，还有的是 /v1/api/merchant： + +@GetMapping("/api/item/v1") + +public void wrong1(){ + +} + + +@GetMapping("/api/v1/shop") + +public void wrong2(){ + +} + + + +@GetMapping("/v1/api/merchant") + +public void wrong3(){ + +} + + + +显然，商品、商店和商户的接口开发同学，没有按照一致的 URL 格式来实现接口的版本控制。更要命的是，我们可能开发出两个 URL 类似接口，比如一个是 /api/v1/user，另一个是 /api/user/v1，这到底是一个接口还是两个接口呢？ + +相比于在每一个接口的 URL Path 中设置版本号，更理想的方式是在框架层面实现统一。如果你使用 Spring 框架的话，可以按照下面的方式自定义 RequestMappingHandlerMapping 来实现。 + +首先，创建一个注解来定义接口的版本。@APIVersion 自定义注解可以应用于方法或 Controller 上： + +@Target({ElementType.METHOD, ElementType.TYPE}) + +@Retention(RetentionPolicy.RUNTIME) + +public @interface APIVersion { + + String[] value(); + +} + + + +然后，定义一个 APIVersionHandlerMapping 类继承 RequestMappingHandlerMapping。 + +RequestMappingHandlerMapping 的作用，是根据类或方法上的 @RequestMapping 来生成 RequestMappingInfo 的实例。我们覆盖 registerHandlerMethod 方法的实现，从 @APIVersion 自定义注解中读取版本信息，拼接上原有的、不带版本号的 URL Pattern，构成新的 RequestMappingInfo，来通过注解的方式为接口增加基于 URL 的版本号： + +public class APIVersionHandlerMapping extends RequestMappingHandlerMapping { + + @Override + + protected boolean isHandler(Class beanType) { + + return AnnotatedElementUtils.hasAnnotation(beanType, Controller.class); + + } + + + + @Override + + protected void registerHandlerMethod(Object handler, Method method, RequestMappingInfo mapping) { + + Class controllerClass = method.getDeclaringClass(); + + //类上的APIVersion注解 + + APIVersion apiVersion = AnnotationUtils.findAnnotation(controllerClass, APIVersion.class); + + //方法上的APIVersion注解 + + APIVersion methodAnnotation = AnnotationUtils.findAnnotation(method, APIVersion.class); + + //以方法上的注解优先 + + if (methodAnnotation != null) { + + apiVersion = methodAnnotation; + + } + + String[] urlPatterns = apiVersion == null ? new String[0] : apiVersion.value(); + + + + PatternsRequestCondition apiPattern = new PatternsRequestCondition(urlPatterns); + + PatternsRequestCondition oldPattern = mapping.getPatternsCondition(); + + PatternsRequestCondition updatedFinalPattern = apiPattern.combine(oldPattern); + + //重新构建RequestMappingInfo + + mapping = new RequestMappingInfo(mapping.getName(), updatedFinalPattern, mapping.getMethodsCondition(), + + mapping.getParamsCondition(), mapping.getHeadersCondition(), mapping.getConsumesCondition(), + + mapping.getProducesCondition(), mapping.getCustomCondition()); + + super.registerHandlerMethod(handler, method, mapping); + + } + +} + + + +最后，也是特别容易忽略的一点，要通过实现 WebMvcRegistrations 接口，来生效自定义的 APIVersionHandlerMapping： + +@SpringBootApplication + +public class CommonMistakesApplication implements WebMvcRegistrations { + +... + + @Override + + public RequestMappingHandlerMapping getRequestMappingHandlerMapping() { + + return new APIVersionHandlerMapping(); + + } + +} + + + +这样，就实现了在 Controller 上或接口方法上通过注解，来实现以统一的 Pattern 进行版本号控制： + +@GetMapping(value = "/api/user") + +@APIVersion("v4") + +public int right4() { + + return 4; + +} + + + +加上注解后，访问浏览器查看效果： + + + +使用框架来明确 API 版本的指定策略，不仅实现了标准化，更实现了强制的 API 版本控制。对上面代码略做修改，我们就可以实现不设置 @APIVersion 接口就给予报错提示。 + +接口处理方式要明确同步还是异步 + +看到这个标题，你可能感觉不太好理解，我们直接看一个实际案例吧。 + +有一个文件上传服务 FileService，其中一个 upload 文件上传接口特别慢，原因是这个上传接口在内部需要进行两步操作，首先上传原图，然后压缩后上传缩略图。如果每一步都耗时 5 秒的话，那么这个接口返回至少需要 10 秒的时间。 + +于是，开发同学把接口改为了异步处理，每一步操作都限定了超时时间，也就是分别把上传原文件和上传缩略图的操作提交到线程池，然后等待一定的时间： + +private ExecutorService threadPool = Executors.newFixedThreadPool(2); + +//我没有贴出两个文件上传方法uploadFile和uploadThumbnailFile的实现，它们在内部只是随机进行休眠然后返回文件名，对于本例来说不是很重要 + +public UploadResponse upload(UploadRequest request) { + + UploadResponse response = new UploadResponse(); + + //上传原始文件任务提交到线程池处理 + + Future uploadFile = threadPool.submit(() -> uploadFile(request.getFile())); + + //上传缩略图任务提交到线程池处理 + + Future uploadThumbnailFile = threadPool.submit(() -> uploadThumbnailFile(request.getFile())); + + //等待上传原始文件任务完成，最多等待1秒 + + try { + + response.setDownloadUrl(uploadFile.get(1, TimeUnit.SECONDS)); + + } catch (Exception e) { + + e.printStackTrace(); + + } + + //等待上传缩略图任务完成，最多等待1秒 + + try { + + response.setThumbnailDownloadUrl(uploadThumbnailFile.get(1, TimeUnit.SECONDS)); + + } catch (Exception e) { + + e.printStackTrace(); + + } + + return response; + +} + + + +上传接口的请求和响应比较简单，传入二进制文件，传出原文件和缩略图下载地址： + +@Data + +public class UploadRequest { + + private byte[] file; + +} + +@Data + +public class UploadResponse { + + private String downloadUrl; + + private String thumbnailDownloadUrl; + +} + + + +到这里，你能看出这种实现方式的问题是什么吗？ + +从接口命名上看虽然是同步上传操作，但其内部通过线程池进行异步上传，并因为设置了较短超时所以接口整体响应挺快。但是，一旦遇到超时，接口就不能返回完整的数据，不是无法拿到原文件下载地址，就是无法拿到缩略图下载地址，接口的行为变得不可预测： + + + +所以，这种优化接口响应速度的方式并不可取，更合理的方式是，让上传接口要么是彻底的同步处理，要么是彻底的异步处理： + +所谓同步处理，接口一定是同步上传原文件和缩略图的，调用方可以自己选择调用超时，如果来得及可以一直等到上传完成，如果等不及可以结束等待，下一次再重试； + +所谓异步处理，接口是两段式的，上传接口本身只是返回一个任务 ID，然后异步做上传操作，上传接口响应很快，客户端需要之后再拿着任务 ID 调用任务查询接口查询上传的文件 URL。 + +同步上传接口的实现代码如下，把超时的选择留给客户端： + +public SyncUploadResponse syncUpload(SyncUploadRequest request) { + + SyncUploadResponse response = new SyncUploadResponse(); + + response.setDownloadUrl(uploadFile(request.getFile())); + + response.setThumbnailDownloadUrl(uploadThumbnailFile(request.getFile())); + + return response; + +} + + + +这里的 SyncUploadRequest 和 SyncUploadResponse 类，与之前定义的 UploadRequest 和 UploadResponse 是一致的。对于接口的入参和出参 DTO 的命名，我比较建议的方式是，使用接口名 +Request 和 Response 后缀。 + +接下来，我们看看异步的上传文件接口如何实现。异步上传接口在出参上有点区别，不再返回文件 URL，而是返回一个任务 ID： + +@Data + +public class AsyncUploadRequest { + + private byte[] file; + +} + +@Data + +public class AsyncUploadResponse { + + private String taskId; + +} + + + +在接口实现上，我们同样把上传任务提交到线程池处理，但是并不会同步等待任务完成，而是完成后把结果写入一个 HashMap，任务查询接口通过查询这个 HashMap 来获得文件的 URL： + +//计数器，作为上传任务的ID + +private AtomicInteger atomicInteger = new AtomicInteger(0); + +//暂存上传操作的结果，生产代码需要考虑数据持久化 + +private ConcurrentHashMap downloadUrl = new ConcurrentHashMap<>(); + +//异步上传操作 + +public AsyncUploadResponse asyncUpload(AsyncUploadRequest request) { + + AsyncUploadResponse response = new AsyncUploadResponse(); + + //生成唯一的上传任务ID + + String taskId = "upload" + atomicInteger.incrementAndGet(); + + //异步上传操作只返回任务ID + + response.setTaskId(taskId); + + //提交上传原始文件操作到线程池异步处理 + + threadPool.execute(() -> { + + String url = uploadFile(request.getFile()); + + //如果ConcurrentHashMap不包含Key，则初始化一个SyncQueryUploadTaskResponse，然后设置DownloadUrl + + downloadUrl.computeIfAbsent(taskId, id -> new SyncQueryUploadTaskResponse(id)).setDownloadUrl(url); + + }); + + //提交上传缩略图操作到线程池异步处理 + + threadPool.execute(() -> { + + String url = uploadThumbnailFile(request.getFile()); + + downloadUrl.computeIfAbsent(taskId, id -> new SyncQueryUploadTaskResponse(id)).setThumbnailDownloadUrl(url); + + }); + + return response; + +} + + + +文件上传查询接口则以任务 ID 作为入参，返回两个文件的下载地址，因为文件上传查询接口是同步的，所以直接命名为 syncQueryUploadTask： + +//syncQueryUploadTask接口入参 + +@Data + +@RequiredArgsConstructor + +public class SyncQueryUploadTaskRequest { + + private final String taskId;//使用上传文件任务ID查询上传结果 + +} + +//syncQueryUploadTask接口出参 + +@Data + +@RequiredArgsConstructor + +public class SyncQueryUploadTaskResponse { + + private final String taskId; //任务ID + + private String downloadUrl; //原始文件下载URL + + private String thumbnailDownloadUrl; //缩略图下载URL + +} + +public SyncQueryUploadTaskResponse syncQueryUploadTask(SyncQueryUploadTaskRequest request) { + + SyncQueryUploadTaskResponse response = new SyncQueryUploadTaskResponse(request.getTaskId()); + + //从之前定义的downloadUrl ConcurrentHashMap查询结果 + +response.setDownloadUrl(downloadUrl.getOrDefault(request.getTaskId(), response).getDownloadUrl()); + + response.setThumbnailDownloadUrl(downloadUrl.getOrDefault(request.getTaskId(), response).getThumbnailDownloadUrl()); + + return response; + +} + + + +经过改造的 FileService 不再提供一个看起来是同步上传，内部却是异步上传的 upload 方法，改为提供很明确的： + +同步上传接口 syncUpload； + +异步上传接口 asyncUpload，搭配 syncQueryUploadTask 查询上传结果。 + +使用方可以根据业务性质选择合适的方法：如果是后端批处理使用，那么可以使用同步上传，多等待一些时间问题不大；如果是面向用户的接口，那么接口响应时间不宜过长，可以调用异步上传接口，然后定时轮询上传结果，拿到结果再显示。 + +重点回顾 + +今天，我针对接口设计，和你深入探讨了三个方面的问题。 + +第一，针对响应体的设计混乱、响应结果的不明确问题，服务端需要明确响应体每一个字段的意义，以一致的方式进行处理，并确保不透传下游服务的错误。 + +第二，针对接口版本控制问题，主要就是在开发接口之前明确版本控制策略，以及尽量使用统一的版本控制策略两方面。 + +第三，针对接口的处理方式，我认为需要明确要么是同步要么是异步。如果 API 列表中既有同步接口也有异步接口，那么最好直接在接口名中明确。 + +一个良好的接口文档不仅仅需要说明如何调用接口，更需要补充接口使用的最佳实践以及接口的 SLA 标准。我看到的大部分接口文档只给出了参数定义，但诸如幂等性、同步异步、缓存策略等看似内部实现相关的一些设计，其实也会影响调用方对接口的使用策略，最好也可以体现在接口文档中。 + +最后，我再额外提一下，对于服务端出错的时候是否返回 200 响应码的问题，其实一直有争论。从 RESTful 设计原则来看，我们应该尽量利用 HTTP 状态码来表达错误，但也不是这么绝对。 + +如果我们认为 HTTP 状态码是协议层面的履约，那么当这个错误已经不涉及 HTTP 协议时（换句话说，服务端已经收到请求进入服务端业务处理后产生的错误），不一定需要硬套协议本身的错误码。但涉及非法 URL、非法参数、没有权限等无法处理请求的情况，还是应该使用正确的响应码来应对。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在第一节的例子中，接口响应结构体中的 code 字段代表执行结果的错误码，对于业务特别复杂的接口，可能会有很多错误情况，code 可能会有几十甚至几百个。客户端开发人员需要根据每一种错误情况逐一写 if-else 进行不同交互处理，会非常麻烦，你觉得有什么办法来改进吗？作为服务端，是否有必要告知客户端接口执行的错误码呢？ + +在第二节的例子中，我们在类或方法上标记 @APIVersion 自定义注解，实现了 URL 方式统一的接口版本定义。你可以用类似的方式（也就是自定义 RequestMappingHandlerMapping），来实现一套统一的基于请求头方式的版本控制吗？ + +关于接口设计，你还遇到过其他问题吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/23缓存设计：缓存可以锦上添花也可以落井下石.md b/专栏/Java业务开发常见错误100例/23缓存设计：缓存可以锦上添花也可以落井下石.md new file mode 100644 index 0000000..172ec34 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/23缓存设计：缓存可以锦上添花也可以落井下石.md @@ -0,0 +1,587 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 23 缓存设计：缓存可以锦上添花也可以落井下石 + 今天，我从设计的角度，与你聊聊缓存。 + +通常我们会使用更快的介质（比如内存）作为缓存，来解决较慢介质（比如磁盘）读取数据慢的问题，缓存是用空间换时间，来解决性能问题的一种架构设计模式。更重要的是，磁盘上存储的往往是原始数据，而缓存中保存的可以是面向呈现的数据。这样一来，缓存不仅仅是加快了 IO，还可以减少原始数据的计算工作。 + +此外，缓存系统一般设计简单，功能相对单一，所以诸如 Redis 这种缓存系统的整体吞吐量，能达到关系型数据库的几倍甚至几十倍，因此缓存特别适用于互联网应用的高并发场景。 + +使用 Redis 做缓存虽然简单好用，但使用和设计缓存并不是 set 一下这么简单，需要注意缓存的同步、雪崩、并发、穿透等问题。今天，我们就来详细聊聊。 + +不要把 Redis 当作数据库 + +通常，我们会使用 Redis 等分布式缓存数据库来缓存数据，但是千万别把 Redis 当做数据库来使用。我就见过许多案例，因为 Redis 中数据消失导致业务逻辑错误，并且因为没有保留原始数据，业务都无法恢复。 + +Redis 的确具有数据持久化功能，可以实现服务重启后数据不丢失。这一点，很容易让我们误认为 Redis 可以作为高性能的 KV 数据库。 + +其实，从本质上来看，Redis（免费版）是一个内存数据库，所有数据保存在内存中，并且直接从内存读写数据响应操作，只不过具有数据持久化能力。所以，Redis 的特点是，处理请求很快，但无法保存超过内存大小的数据。 + +备注：VM 模式虽然可以保存超过内存大小的数据，但是因为性能原因从 2.6 开始已经被废弃。此外，Redis 企业版提供了 Redis on Flash 可以实现 Key+ 字典 + 热数据保存在内存中，冷数据保存在 SSD 中。 + +因此，把 Redis 用作缓存，我们需要注意两点。 + +第一，从客户端的角度来说，缓存数据的特点一定是有原始数据来源，且允许丢失，即使设置的缓存时间是 1 分钟，在 30 秒时缓存数据因为某种原因消失了，我们也要能接受。当数据丢失后，我们需要从原始数据重新加载数据，不能认为缓存系统是绝对可靠的，更不能认为缓存系统不会删除没有过期的数据。 + +第二，从 Redis 服务端的角度来说，缓存系统可以保存的数据量一定是小于原始数据的。首先，我们应该限制 Redis 对内存的使用量，也就是设置 maxmemory 参数；其次，我们应该根据数据特点，明确 Redis 应该以怎样的算法来驱逐数据。 + +从Redis 的文档可以看到，常用的数据淘汰策略有： + +allkeys-lru，针对所有 Key，优先删除最近最少使用的 Key； + +volatile-lru，针对带有过期时间的 Key，优先删除最近最少使用的 Key； + +volatile-ttl，针对带有过期时间的 Key，优先删除即将过期的 Key（根据 TTL 的值）； + +allkeys-lfu（Redis 4.0 以上），针对所有 Key，优先删除最少使用的 Key； + +volatile-lfu（Redis 4.0 以上），针对带有过期时间的 Key，优先删除最少使用的 Key。 + +其实，这些算法是 Key 范围 +Key 选择算法的搭配组合，其中范围有 allkeys 和 volatile 两种，算法有 LRU、TTL 和 LFU 三种。接下来，我就从 Key 范围和算法角度，和你说说如何选择合适的驱逐算法。 + +首先，从算法角度来说，Redis 4.0 以后推出的 LFU 比 LRU 更“实用”。试想一下，如果一个 Key 访问频率是 1 天一次，但正好在 1 秒前刚访问过，那么 LRU 可能不会选择优先淘汰这个 Key，反而可能会淘汰一个 5 秒访问一次但最近 2 秒没有访问过的 Key，而 LFU 算法不会有这个问题。而 TTL 会比较“头脑简单”一点，优先删除即将过期的 Key，但有可能这个 Key 正在被大量访问。 + +然后，从 Key 范围角度来说，allkeys 可以确保即使 Key 没有 TTL 也能回收，如果使用的时候客户端总是“忘记”设置缓存的过期时间，那么可以考虑使用这个系列的算法。而 volatile 会更稳妥一些，万一客户端把 Redis 当做了长效缓存使用，只是启动时候初始化一次缓存，那么一旦删除了此类没有 TTL 的数据，可能就会导致客户端出错。 + +所以，不管是使用者还是管理者都要考虑 Redis 的使用方式，使用者需要考虑应该以缓存的姿势来使用 Redis，管理者应该为 Redis 设置内存限制和合适的驱逐策略，避免出现 OOM。 + +注意缓存雪崩问题 + +由于缓存系统的 IOPS 比数据库高很多，因此要特别小心短时间内大量缓存失效的情况。这种情况一旦发生，可能就会在瞬间有大量的数据需要回源到数据库查询，对数据库造成极大的压力，极限情况下甚至导致后端数据库直接崩溃。这就是我们常说的缓存失效，也叫作缓存雪崩。 + +从广义上说，产生缓存雪崩的原因有两种： + +第一种是，缓存系统本身不可用，导致大量请求直接回源到数据库； + +第二种是，应用设计层面大量的 Key 在同一时间过期，导致大量的数据回源。 + +第一种原因，主要涉及缓存系统本身高可用的配置，不属于缓存设计层面的问题，所以今天我主要和你说说如何确保大量 Key 不在同一时间被动过期。 + +程序初始化的时候放入 1000 条城市数据到 Redis 缓存中，过期时间是 30 秒；数据过期后从数据库获取数据然后写入缓存，每次从数据库获取数据后计数器 +1；在程序启动的同时，启动一个定时任务线程每隔一秒输出计数器的值，并把计数器归零。 + +压测一个随机查询某城市信息的接口，观察一下数据库的 QPS： + +@Autowired + +private StringRedisTemplate stringRedisTemplate; + +private AtomicInteger atomicInteger = new AtomicInteger(); + +@PostConstruct + +public void wrongInit() { + + //初始化1000个城市数据到Redis，所有缓存数据有效期30秒 + + IntStream.rangeClosed(1, 1000).forEach(i -> stringRedisTemplate.opsForValue().set("city" + i, getCityFromDb(i), 30, TimeUnit.SECONDS)); + + log.info("Cache init finished"); + + + + //每秒一次，输出数据库访问的QPS + + + + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> { + + log.info("DB QPS : {}", atomicInteger.getAndSet(0)); + + }, 0, 1, TimeUnit.SECONDS); + +} + +@GetMapping("city") + +public String city() { + + //随机查询一个城市 + + int id = ThreadLocalRandom.current().nextInt(1000) + 1; + + String key = "city" + id; + + String data = stringRedisTemplate.opsForValue().get(key); + + if (data == null) { + + //回源到数据库查询 + + data = getCityFromDb(id); + + if (!StringUtils.isEmpty(data)) + + //缓存30秒过期 + + stringRedisTemplate.opsForValue().set(key, data, 30, TimeUnit.SECONDS); + + } + + return data; + +} + +private String getCityFromDb(int cityId) { + + //模拟查询数据库，查一次增加计数器加一 + + atomicInteger.incrementAndGet(); + + return "citydata" + System.currentTimeMillis(); + +} + + + +使用 wrk 工具，设置 10 线程 10 连接压测 city 接口： + +wrk -c10 -t10 -d 100s http://localhost:45678/cacheinvalid/city + + + +启动程序 30 秒后缓存过期，回源的数据库 QPS 最高达到了 700 多： + + + +解决缓存 Key 同时大规模失效需要回源，导致数据库压力激增问题的方式有两种。 + +方案一，差异化缓存过期时间，不要让大量的 Key 在同一时间过期。比如，在初始化缓存的时候，设置缓存的过期时间是 30 秒 +10 秒以内的随机延迟（扰动值）。这样，这些 Key 不会集中在 30 秒这个时刻过期，而是会分散在 30~40 秒之间过期： + +@PostConstruct + +public void rightInit1() { + + //这次缓存的过期时间是30秒+10秒内的随机延迟 + + IntStream.rangeClosed(1, 1000).forEach(i -> stringRedisTemplate.opsForValue().set("city" + i, getCityFromDb(i), 30 + ThreadLocalRandom.current().nextInt(10), TimeUnit.SECONDS)); + + log.info("Cache init finished"); + + //同样1秒一次输出数据库QPS： + + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> { + + log.info("DB QPS : {}", atomicInteger.getAndSet(0)); + + }, 0, 1, TimeUnit.SECONDS); + +} + + + +修改后，缓存过期时的回源不会集中在同一秒，数据库的 QPS 从 700 多降到了最高 100 左右： + + + +方案二，让缓存不主动过期。初始化缓存数据的时候设置缓存永不过期，然后启动一个后台线程 30 秒一次定时把所有数据更新到缓存，而且通过适当的休眠，控制从数据库更新数据的频率，降低数据库压力： + +@PostConstruct + +public void rightInit2() throws InterruptedException { + + CountDownLatch countDownLatch = new CountDownLatch(1); + + //每隔30秒全量更新一次缓存 + + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> { + + IntStream.rangeClosed(1, 1000).forEach(i -> { + + String data = getCityFromDb(i); + + //模拟更新缓存需要一定的时间 + + try { + + TimeUnit.MILLISECONDS.sleep(20); + + } catch (InterruptedException e) { } + + if (!StringUtils.isEmpty(data)) { + + //缓存永不过期，被动更新 + + stringRedisTemplate.opsForValue().set("city" + i, data); + + } + + }); + + log.info("Cache update finished"); + + //启动程序的时候需要等待首次更新缓存完成 + + countDownLatch.countDown(); + + }, 0, 30, TimeUnit.SECONDS); + + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> { + + log.info("DB QPS : {}", atomicInteger.getAndSet(0)); + + }, 0, 1, TimeUnit.SECONDS); + + countDownLatch.await(); + +} + + + +这样修改后，虽然缓存整体更新的耗时在 21 秒左右，但数据库的压力会比较稳定： + + + +关于这两种解决方案，我们需要特别注意以下三点： + +方案一和方案二是截然不同的两种缓存方式，如果无法全量缓存所有数据，那么只能使用方案一； + +即使使用了方案二，缓存永不过期，同样需要在查询的时候，确保有回源的逻辑。正如之前所说，我们无法确保缓存系统中的数据永不丢失。 + +不管是方案一还是方案二，在把数据从数据库加入缓存的时候，都需要判断来自数据库的数据是否合法，比如进行最基本的判空检查。 + +之前我就遇到过这样一个重大事故，某系统会在缓存中对基础数据进行长达半年的缓存，在某个时间点 DBA 把数据库中的原始数据进行了归档（可以认为是删除）操作。因为缓存中的数据一直在所以一开始没什么问题，但半年后的一天缓存中数据过期了，就从数据库中查询到了空数据加入缓存，爆发了大面积的事故。 + +这个案例说明，缓存会让我们更不容易发现原始数据的问题，所以在把数据加入缓存之前一定要校验数据，如果发现有明显异常要及时报警。 + +说到这里，我们再仔细看一下回源 QPS 超过 700 的截图，可以看到在并发情况下，总共 1000 条数据回源达到了 1002 次，说明有一些条目出现了并发回源。这，就是我后面要讲到的缓存并发问题。 + +注意缓存击穿问题 + +在某些 Key 属于极端热点数据，且并发量很大的情况下，如果这个 Key 过期，可能会在某个瞬间出现大量的并发请求同时回源，相当于大量的并发请求直接打到了数据库。这种情况，就是我们常说的缓存击穿或缓存并发问题。 + +我们来重现下这个问题。在程序启动的时候，初始化一个热点数据到 Redis 中，过期时间设置为 5 秒，每隔 1 秒输出一下回源的 QPS： + +@PostConstruct + +public void init() { + + //初始化一个热点数据到Redis中，过期时间设置为5秒 + + stringRedisTemplate.opsForValue().set("hotsopt", getExpensiveData(), 5, TimeUnit.SECONDS); + + //每隔1秒输出一下回源的QPS + + + + Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> { + + log.info("DB QPS : {}", atomicInteger.getAndSet(0)); + + }, 0, 1, TimeUnit.SECONDS); + +} + +@GetMapping("wrong") + +public String wrong() { + + String data = stringRedisTemplate.opsForValue().get("hotsopt"); + + if (StringUtils.isEmpty(data)) { + + data = getExpensiveData(); + + //重新加入缓存，过期时间还是5秒 + + stringRedisTemplate.opsForValue().set("hotsopt", data, 5, TimeUnit.SECONDS); + + } + + return data; + +} + + + +可以看到，每隔 5 秒数据库都有 20 左右的 QPS： + + + +如果回源操作特别昂贵，那么这种并发就不能忽略不计。这时，我们可以考虑使用锁机制来限制回源的并发。比如如下代码示例，使用 Redisson 来获取一个基于 Redis 的分布式锁，在查询数据库之前先尝试获取锁： + +@Autowired + +private RedissonClient redissonClient; + +@GetMapping("right") + +public String right() { + + String data = stringRedisTemplate.opsForValue().get("hotsopt"); + + if (StringUtils.isEmpty(data)) { + + RLock locker = redissonClient.getLock("locker"); + + //获取分布式锁 + + if (locker.tryLock()) { + + try { + + data = stringRedisTemplate.opsForValue().get("hotsopt"); + + //双重检查，因为可能已经有一个B线程过了第一次判断，在等锁，然后A线程已经把数据写入了Redis中 + + if (StringUtils.isEmpty(data)) { + + //回源到数据库查询 + + data = getExpensiveData(); + + stringRedisTemplate.opsForValue().set("hotsopt", data, 5, TimeUnit.SECONDS); + + } + + } finally { + + //别忘记释放，另外注意写法，获取锁后整段代码try+finally，确保unlock万无一失 + + locker.unlock(); + + } + + } + + } + + return data; + +} + + + +这样，可以把回源到数据库的并发限制在 1： + + + +在真实的业务场景下，不一定要这么严格地使用双重检查分布式锁进行全局的并发限制，因为这样虽然可以把数据库回源并发降到最低，但也限制了缓存失效时的并发。可以考虑的方式是： + +方案一，使用进程内的锁进行限制，这样每一个节点都可以以一个并发回源数据库； + +方案二，不使用锁进行限制，而是使用类似 Semaphore 的工具限制并发数，比如限制为 10，这样既限制了回源并发数不至于太大，又能使得一定量的线程可以同时回源。 + +注意缓存穿透问题 + +在之前的例子中，缓存回源的逻辑都是当缓存中查不到需要的数据时，回源到数据库查询。这里容易出现的一个漏洞是，缓存中没有数据不一定代表数据没有缓存，还有一种可能是原始数据压根就不存在。 + +比如下面的例子。数据库中只保存有 ID 介于 0（不含）和 10000（包含）之间的用户，如果从数据库查询 ID 不在这个区间的用户，会得到空字符串，所以缓存中缓存的也是空字符串。如果使用 ID=0 去压接口的话，从缓存中查出了空字符串，认为是缓存中没有数据回源查询，其实相当于每次都回源： + +@GetMapping("wrong") + +public String wrong(@RequestParam("id") int id) { + + String key = "user" + id; + + String data = stringRedisTemplate.opsForValue().get(key); + + //无法区分是无效用户还是缓存失效 + + if (StringUtils.isEmpty(data)) { + + data = getCityFromDb(id); + + stringRedisTemplate.opsForValue().set(key, data, 30, TimeUnit.SECONDS); + + } + + return data; + +} + +private String getCityFromDb(int id) { + + atomicInteger.incrementAndGet(); + + //注意，只有ID介于0（不含）和10000（包含）之间的用户才是有效用户，可以查询到用户信息 + + if (id > 0 && id <= 10000) return "userdata"; + + //否则返回空字符串 + + return ""; + +} + + + +压测后数据库的 QPS 达到了几千： + + + +如果这种漏洞被恶意利用的话，就会对数据库造成很大的性能压力。这就是缓存穿透。 + +这里需要注意，缓存穿透和缓存击穿的区别： + +缓存穿透是指，缓存没有起到压力缓冲的作用； + +而缓存击穿是指，缓存失效时瞬时的并发打到数据库。 + +解决缓存穿透有以下两种方案。 + +方案一，对于不存在的数据，同样设置一个特殊的 Value 到缓存中，比如当数据库中查出的用户信息为空的时候，设置 NODATA 这样具有特殊含义的字符串到缓存中。这样下次请求缓存的时候还是可以命中缓存，即直接从缓存返回结果，不查询数据库： + +@GetMapping("right") + +public String right(@RequestParam("id") int id) { + + String key = "user" + id; + + String data = stringRedisTemplate.opsForValue().get(key); + + if (StringUtils.isEmpty(data)) { + + data = getCityFromDb(id); + + //校验从数据库返回的数据是否有效 + + if (!StringUtils.isEmpty(data)) { + + stringRedisTemplate.opsForValue().set(key, data, 30, TimeUnit.SECONDS); + + } + + else { + + //如果无效，直接在缓存中设置一个NODATA，这样下次查询时即使是无效用户还是可以命中缓存 + + stringRedisTemplate.opsForValue().set(key, "NODATA", 30, TimeUnit.SECONDS); + + } + + } + + return data; + +} + + + +但，这种方式可能会把大量无效的数据加入缓存中，如果担心大量无效数据占满缓存的话还可以考虑方案二，即使用布隆过滤器做前置过滤。 + +布隆过滤器是一种概率型数据库结构，由一个很长的二进制向量和一系列随机映射函数组成。它的原理是，当一个元素被加入集合时，通过 k 个散列函数将这个元素映射成一个 m 位 bit 数组中的 k 个点，并置为 1。 + +检索时，我们只要看看这些点是不是都是 1 就（大概）知道集合中有没有它了。如果这些点有任何一个 0，则被检元素一定不在；如果都是 1，则被检元素很可能在。 + +原理如下图所示： + + + +布隆过滤器不保存原始值，空间效率很高，平均每一个元素占用 2.4 字节就可以达到万分之一的误判率。这里的误判率是指，过滤器判断值存在而实际并不存在的概率。我们可以设置布隆过滤器使用更大的存储空间，来得到更小的误判率。 + +你可以把所有可能的值保存在布隆过滤器中，从缓存读取数据前先过滤一次： + +如果布隆过滤器认为值不存在，那么值一定是不存在的，无需查询缓存也无需查询数据库； + +对于极小概率的误判请求，才会最终让非法 Key 的请求走到缓存或数据库。 + +要用上布隆过滤器，我们可以使用 Google 的 Guava 工具包提供的 BloomFilter 类改造一下程序：启动时，初始化一个具有所有有效用户 ID 的、10000 个元素的 BloomFilter，在从缓存查询数据之前调用其 mightContain 方法，来检测用户 ID 是否可能存在；如果布隆过滤器说值不存在，那么一定是不存在的，直接返回： + +private BloomFilter bloomFilter; + +@PostConstruct + +public void init() { + + //创建布隆过滤器，元素数量10000，期望误判率1% + + bloomFilter = BloomFilter.create(Funnels.integerFunnel(), 10000, 0.01); + + //填充布隆过滤器 + + IntStream.rangeClosed(1, 10000).forEach(bloomFilter::put); + +} + +@GetMapping("right2") + +public String right2(@RequestParam("id") int id) { + + String data = ""; + + //通过布隆过滤器先判断 + + if (bloomFilter.mightContain(id)) { + + String key = "user" + id; + + //走缓存查询 + + data = stringRedisTemplate.opsForValue().get(key); + + if (StringUtils.isEmpty(data)) { + + //走数据库查询 + + data = getCityFromDb(id); + + stringRedisTemplate.opsForValue().set(key, data, 30, TimeUnit.SECONDS); + + } + + } + + return data; + +} + + + +对于方案二，我们需要同步所有可能存在的值并加入布隆过滤器，这是比较麻烦的地方。如果业务规则明确的话，你也可以考虑直接根据业务规则判断值是否存在。 + +其实，方案二可以和方案一同时使用，即将布隆过滤器前置，对于误判的情况再保存特殊值到缓存，双重保险避免无效数据查询请求打到数据库。 + +注意缓存数据同步策略 + +前面提到的 3 个案例，其实都属于缓存数据过期后的被动删除。在实际情况下，修改了原始数据后，考虑到缓存数据更新的及时性，我们可能会采用主动更新缓存的策略。这些策略可能是： + +先更新缓存，再更新数据库； + +先更新数据库，再更新缓存； + +先删除缓存，再更新数据库，访问的时候按需加载数据到缓存； + +先更新数据库，再删除缓存，访问的时候按需加载数据到缓存。 + +那么，我们应该选择哪种更新策略呢？我来和你逐一分析下这 4 种策略： + +“先更新缓存再更新数据库”策略不可行。数据库设计复杂，压力集中，数据库因为超时等原因更新操作失败的可能性较大，此外还会涉及事务，很可能因为数据库更新失败，导致缓存和数据库的数据不一致。 + +“先更新数据库再更新缓存”策略不可行。一是，如果线程 A 和 B 先后完成数据库更新，但更新缓存时却是 B 和 A 的顺序，那很可能会把旧数据更新到缓存中引起数据不一致；二是，我们不确定缓存中的数据是否会被访问，不一定要把所有数据都更新到缓存中去。 + +“先删除缓存再更新数据库，访问的时候按需加载数据到缓存”策略也不可行。在并发的情况下，很可能删除缓存后还没来得及更新数据库，就有另一个线程先读取了旧值到缓存中，如果并发量很大的话这个概率也会很大。 + +“先更新数据库再删除缓存，访问的时候按需加载数据到缓存”策略是最好的。虽然在极端情况下，这种策略也可能出现数据不一致的问题，但概率非常低，基本可以忽略。举一个“极端情况”的例子，比如更新数据的时间节点恰好是缓存失效的瞬间，这时 A 先读取到了旧值，随后在 B 操作数据库完成更新并且删除了缓存之后，A 再把旧值加入缓存。 + +需要注意的是，更新数据库后删除缓存的操作可能失败，如果失败则考虑把任务加入延迟队列进行延迟重试，确保数据可以删除，缓存可以及时更新。因为删除操作是幂等的，所以即使重复删问题也不是太大，这又是删除比更新好的一个原因。 + +因此，针对缓存更新更推荐的方式是，缓存中的数据不由数据更新操作主动触发，统一在需要使用的时候按需加载，数据更新后及时删除缓存中的数据即可。 + +重点回顾 + +今天，我主要是从设计的角度，和你分享了数据缓存的三大问题。 + +第一，我们不能把诸如 Redis 的缓存数据库完全当作数据库来使用。我们不能假设缓存始终可靠，也不能假设没有过期的数据必然可以被读取到，需要处理好缓存的回源逻辑；而且要显式设置 Redis 的最大内存使用和数据淘汰策略，避免出现 OOM 的问题。 + +第二，缓存的性能比数据库好很多，我们需要考虑大量请求绕过缓存直击数据库造成数据库瘫痪的各种情况。对于缓存瞬时大面积失效的缓存雪崩问题，可以通过差异化缓存过期时间解决；对于高并发的缓存 Key 回源问题，可以使用锁来限制回源并发数；对于不存在的数据穿透缓存的问题，可以通过布隆过滤器进行数据存在性的预判，或在缓存中也设置一个值来解决。 + +第三，当数据库中的数据有更新的时候，需要考虑如何确保缓存中数据的一致性。我们看到，“先更新数据库再删除缓存，访问的时候按需加载数据到缓存”的策略是最为妥当的，并且要尽量设置合适的缓存过期时间，这样即便真的发生不一致，也可以在缓存过期后数据得到及时同步。 + +最后，我要提醒你的是，在使用缓存系统的时候，要监控缓存系统的内存使用量、命中率、对象平均过期时间等重要指标，以便评估系统的有效性，并及时发现问题。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在聊到缓存并发问题时，我们说到热点 Key 回源会对数据库产生的压力问题，如果 Key 特别热的话，可能缓存系统也无法承受，毕竟所有的访问都集中打到了一台缓存服务器。如果我们使用 Redis 来做缓存，那可以把一个热点 Key 的缓存查询压力，分散到多个 Redis 节点上吗？ + +大 Key 也是数据缓存容易出现的一个问题。如果一个 Key 的 Value 特别大，那么可能会对 Redis 产生巨大的性能影响，因为 Redis 是单线程模型，对大 Key 进行查询或删除等操作，可能会引起 Redis 阻塞甚至是高可用切换。你知道怎么查询 Redis 中的大 Key，以及如何在设计上实现大 Key 的拆分吗？ + +关于缓存设计，你还遇到过哪些坑呢？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/24业务代码写完，就意味着生产就绪了？.md b/专栏/Java业务开发常见错误100例/24业务代码写完，就意味着生产就绪了？.md new file mode 100644 index 0000000..e759e04 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/24业务代码写完，就意味着生产就绪了？.md @@ -0,0 +1,946 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 24 业务代码写完，就意味着生产就绪了？ + 今天，我们来聊聊业务代码写完，是不是就意味着生产就绪，可以直接投产了。 + +所谓生产就绪（Production-ready），是指应用开发完成要投入生产环境，开发层面需要额外做的一些工作。在我看来，如果应用只是开发完成了功能代码，然后就直接投产，那意味着应用其实在裸奔。在这种情况下，遇到问题因为缺乏有效的监控导致无法排查定位问题，同时很可能遇到问题我们自己都不知道，需要依靠用户反馈才知道应用出了问题。 + +那么，生产就绪需要做哪些工作呢？我认为，以下三方面的工作最重要。 + +第一，提供健康检测接口。传统采用 ping 的方式对应用进行探活检测并不准确。有的时候，应用的关键内部或外部依赖已经离线，导致其根本无法正常工作，但其对外的 Web 端口或管理端口是可以 ping 通的。我们应该提供一个专有的监控检测接口，并尽可能触达一些内部组件。 + +第二，暴露应用内部信息。应用内部诸如线程池、内存队列等组件，往往在应用内部扮演了重要的角色，如果应用或应用框架可以对外暴露这些重要信息，并加以监控，那么就有可能在诸如 OOM 等重大问题暴露之前发现蛛丝马迹，避免出现更大的问题。 + +第三，建立应用指标 Metrics 监控。Metrics 可以翻译为度量或者指标，指的是对于一些关键信息以可聚合的、数值的形式做定期统计，并绘制出各种趋势图表。这里的指标监控，包括两个方面：一是，应用内部重要组件的指标监控，比如 JVM 的一些指标、接口的 QPS 等；二是，应用的业务数据的监控，比如电商订单量、游戏在线人数等。 + +今天，我就通过实际案例，和你聊聊如何快速实现这三方面的工作。 + +准备工作：配置 Spring Boot Actuator + +Spring Boot 有一个 Actuator 模块，封装了诸如健康检测、应用内部信息、Metrics 指标等生产就绪的功能。今天这一讲后面的内容都是基于 Actuator 的，因此我们需要先完成 Actuator 的引入和配置。 + +我们可以像这样在 pom 中通过添加依赖的方式引入 Actuator： + + + + org.springframework.boot + + spring-boot-starter-actuator + + + + + +之后，你就可以直接使用 Actuator 了，但还要注意一些重要的配置： + +如果你不希望 Web 应用的 Actuator 管理端口和应用端口重合的话，可以使用 management.server.port 设置独立的端口。 + +Actuator 自带了很多开箱即用提供信息的端点（Endpoint），可以通过 JMX 或 Web 两种方式进行暴露。考虑到有些信息比较敏感，这些内置的端点默认不是完全开启的，你可以通过官网查看这些默认值。在这里，为了方便后续 Demo，我们设置所有端点通过 Web 方式开启。 + +默认情况下，Actuator 的 Web 访问方式的根地址为 /actuator，可以通过 management.endpoints.web.base-path 参数进行修改。我来演示下，如何将其修改为 /admin。 + +management.server.port=45679 + +management.endpoints.web.exposure.include=* + +management.endpoints.web.base-path=/admin + + + +现在，你就可以访问 http://localhost:45679/admin ，来查看 Actuator 的所有功能 URL 了： + + + +其中，大部分端点提供的是只读信息，比如查询 Spring 的 Bean、ConfigurableEnvironment、定时任务、SpringBoot 自动配置、Spring MVC 映射等；少部分端点还提供了修改功能，比如优雅关闭程序、下载线程 Dump、下载堆 Dump、修改日志级别等。 + +你可以访问这里，查看所有这些端点的功能，详细了解它们提供的信息以及实现的操作。此外，我再分享一个不错的 Spring Boot 管理工具Spring Boot Admin，它把大部分 Actuator 端点提供的功能封装为了 Web UI。 + +健康检测需要触达关键组件 + +在这一讲开始我们提到，健康检测接口可以让监控系统或发布工具知晓应用的真实健康状态，比 ping 应用端口更可靠。不过，要达到这种效果最关键的是，我们能确保健康检测接口可以探查到关键组件的状态。 + +好在 Spring Boot Actuator 帮我们预先实现了诸如数据库、InfluxDB、Elasticsearch、Redis、RabbitMQ 等三方系统的健康检测指示器 HealthIndicator。 + +通过 Spring Boot 的自动配置，这些指示器会自动生效。当这些组件有问题的时候，HealthIndicator 会返回 DOWN 或 OUT_OF_SERVICE 状态，health 端点 HTTP 响应状态码也会变为 503，我们可以以此来配置程序健康状态监控报警。 + +为了演示，我们可以修改配置文件，把 management.endpoint.health.show-details 参数设置为 always，让所有用户都可以直接查看各个组件的健康情况（如果配置为 when-authorized，那么可以结合 management.endpoint.health.roles 配置授权的角色）： + +management.endpoint.health.show-details=always + + + +访问 health 端点可以看到，数据库、磁盘、RabbitMQ、Redis 等组件健康状态是 UP，整个应用的状态也是 UP： + + + +在了解了基本配置之后，我们考虑一下，如果程序依赖一个很重要的三方服务，我们希望这个服务无法访问的时候，应用本身的健康状态也是 DOWN。 + +比如三方服务有一个 user 接口，出现异常的概率是 50%： + +@Slf4j + +@RestController + +@RequestMapping("user") + +public class UserServiceController { + + @GetMapping + + public User getUser(@RequestParam("userId") long id) { + + //一半概率返回正确响应，一半概率抛异常 + + if (ThreadLocalRandom.current().nextInt() % 2 == 0) + + return new User(id, "name" + id); + + else + + throw new RuntimeException("error"); + + } + +} + + + +要实现这个 user 接口是否正确响应和程序整体的健康状态挂钩的话，很简单，只需定义一个 UserServiceHealthIndicator 实现 HealthIndicator 接口即可。 + +在 health 方法中，我们通过 RestTemplate 来访问这个 user 接口，如果结果正确则返回 Health.up()，并把调用执行耗时和结果作为补充信息加入 Health 对象中。如果调用接口出现异常，则返回 Health.down()，并把异常信息作为补充信息加入 Health 对象中： + +@Component + +@Slf4j + +public class UserServiceHealthIndicator implements HealthIndicator { + + @Autowired + + private RestTemplate restTemplate; + + @Override + + public Health health() { + + long begin = System.currentTimeMillis(); + + long userId = 1L; + + User user = null; + + try { + + //访问远程接口 + + user = restTemplate.getForObject("http://localhost:45678/user?userId=" + userId, User.class); + + if (user != null && user.getUserId() == userId) { + + //结果正确，返回UP状态，补充提供耗时和用户信息 + + return Health.up() + + .withDetail("user", user) + + .withDetail("took", System.currentTimeMillis() - begin) + + .build(); + + } else { + + //结果不正确，返回DOWN状态，补充提供耗时 + + return Health.down().withDetail("took", System.currentTimeMillis() - begin).build(); + + } + + } catch (Exception ex) { + + //出现异常，先记录异常，然后返回DOWN状态，补充提供异常信息和耗时 + + log.warn("health check failed!", ex); + + return Health.down(ex).withDetail("took", System.currentTimeMillis() - begin).build(); + + } + + } + +} + + + +我们再来看一个聚合多个 HealthIndicator 的案例，也就是定义一个 CompositeHealthContributor 来聚合多个 HealthContributor，实现一组线程池的监控。 + +首先，在 ThreadPoolProvider 中定义两个线程池，其中 demoThreadPool 是包含一个工作线程的线程池，类型是 ArrayBlockingQueue，阻塞队列的长度为 10；还有一个 ioThreadPool 模拟 IO 操作线程池，核心线程数 10，最大线程数 50： + +public class ThreadPoolProvider { + + //一个工作线程的线程池，队列长度10 + + private static ThreadPoolExecutor demoThreadPool = new ThreadPoolExecutor( + + 1, 1, + + 2, TimeUnit.SECONDS, + + new ArrayBlockingQueue<>(10), + + new ThreadFactoryBuilder().setNameFormat("demo-threadpool-%d").get()); + + //核心线程数10，最大线程数50的线程池，队列长度50 + + private static ThreadPoolExecutor ioThreadPool = new ThreadPoolExecutor( + + 10, 50, + + 2, TimeUnit.SECONDS, + + new ArrayBlockingQueue<>(100), + + new ThreadFactoryBuilder().setNameFormat("io-threadpool-%d").get()); + + public static ThreadPoolExecutor getDemoThreadPool() { + + return demoThreadPool; + + } + + public static ThreadPoolExecutor getIOThreadPool() { + + return ioThreadPool; + + } + +} + + +然后，我们定义一个接口，来把耗时很长的任务提交到这个 demoThreadPool 线程池，以模拟线程池队列满的情况： + +@GetMapping("slowTask") + +public void slowTask() { + + ThreadPoolProvider.getDemoThreadPool().execute(() -> { + + try { + + TimeUnit.HOURS.sleep(1); + + } catch (InterruptedException e) { + + } + + }); + +} + + +做了这些准备工作后，让我们来真正实现自定义的 HealthIndicator 类，用于单一线程池的健康状态。 + +我们可以传入一个 ThreadPoolExecutor，通过判断队列剩余容量来确定这个组件的健康状态，有剩余量则返回 UP，否则返回 DOWN，并把线程池队列的两个重要数据，也就是当前队列元素个数和剩余量，作为补充信息加入 Health： + +public class ThreadPoolHealthIndicator implements HealthIndicator { + + private ThreadPoolExecutor threadPool; + + public ThreadPoolHealthIndicator(ThreadPoolExecutor threadPool) { + + this.threadPool = threadPool; + + } + + @Override + + public Health health() { + + //补充信息 + + Map detail = new HashMap<>(); + + //队列当前元素个数 + + detail.put("queue_size", threadPool.getQueue().size()); + + //队列剩余容量 + + detail.put("queue_remaining", threadPool.getQueue().remainingCapacity()); + + //如果还有剩余量则返回UP，否则返回DOWN + + if (threadPool.getQueue().remainingCapacity() > 0) { + + return Health.up().withDetails(detail).build(); + + } else { + + return Health.down().withDetails(detail).build(); + + } + + } + +} + + + +再定义一个 CompositeHealthContributor，来聚合两个 ThreadPoolHealthIndicator 的实例，分别对应 ThreadPoolProvider 中定义的两个线程池： + +@Component + +public class ThreadPoolsHealthContributor implements CompositeHealthContributor { + + //保存所有的子HealthContributor + + private Map contributors = new HashMap<>(); + + ThreadPoolsHealthContributor() { + + //对应ThreadPoolProvider中定义的两个线程池 + + this.contributors.put("demoThreadPool", new ThreadPoolHealthIndicator(ThreadPoolProvider.getDemoThreadPool())); + + this.contributors.put("ioThreadPool", new ThreadPoolHealthIndicator(ThreadPoolProvider.getIOThreadPool())); + + } + + @Override + + public HealthContributor getContributor(String name) { + + //根据name找到某一个HealthContributor + + return contributors.get(name); + + } + + @Override + + public Iterator> iterator() { + + //返回NamedContributor的迭代器，NamedContributor也就是Contributor实例+一个命名 + + return contributors.entrySet().stream() + + .map((entry) -> NamedContributor.of(entry.getKey(), entry.getValue())).iterator(); + + } + +} + + + +程序启动后可以看到，health 接口展现了线程池和外部服务 userService 的健康状态，以及一些具体信息： + + + +我们看到一个 demoThreadPool 为 DOWN 导致父 threadPools 为 DOWN，进一步导致整个程序的 status 为 DOWN： + + + +以上，就是通过自定义 HealthContributor 和 CompositeHealthContributor，来实现监控检测触达程序内部诸如三方服务、线程池等关键组件，是不是很方便呢？ + +额外补充一下，Spring Boot 2.3.0增强了健康检测的功能，细化了 Liveness 和 Readiness 两个端点，便于 Spring Boot 应用程序和 Kubernetes 整合。 + +对外暴露应用内部重要组件的状态 + +除了可以把线程池的状态作为整个应用程序是否健康的依据外，我们还可以通过 Actuator 的 InfoContributor 功能，对外暴露程序内部重要组件的状态数据。这里，我会用一个例子演示使用 info 的 HTTP 端点、JMX MBean 这两种方式，如何查看状态数据。 + +我们看一个具体案例，实现一个 ThreadPoolInfoContributor 来展现线程池的信息。 + +@Component + +public class ThreadPoolInfoContributor implements InfoContributor { + + private static Map threadPoolInfo(ThreadPoolExecutor threadPool) { + + Map info = new HashMap<>(); + + info.put("poolSize", threadPool.getPoolSize());//当前池大小 + + info.put("corePoolSize", threadPool.getCorePoolSize());//设置的核心池大小 + + info.put("largestPoolSize", threadPool.getLargestPoolSize());//最大达到过的池大小 + + info.put("maximumPoolSize", threadPool.getMaximumPoolSize());//设置的最大池大小 + + info.put("completedTaskCount", threadPool.getCompletedTaskCount());//总完成任务数 + + return info; + + } + + @Override + + public void contribute(Info.Builder builder) { + + builder.withDetail("demoThreadPool", threadPoolInfo(ThreadPoolProvider.getDemoThreadPool())); + + builder.withDetail("ioThreadPool", threadPoolInfo(ThreadPoolProvider.getIOThreadPool())); + + } + +} + + +访问 /admin/info 接口，可以看到这些数据： + + + +此外，如果设置开启 JMX 的话： + +spring.jmx.enabled=true + + + +可以通过 jconsole 工具，在 org.springframework.boot.Endpoint 中找到 Info 这个 MBean，然后执行 info 操作可以看到，我们刚才自定义的 InfoContributor 输出的有关两个线程池的信息： + + + +这里，我再额外补充一点。对于查看和操作 MBean，除了使用 jconsole 之外，你可以使用 jolokia 把 JMX 转换为 HTTP 协议，引入依赖： + + + + org.jolokia + + jolokia-core + + + + + +然后，你就可以通过 jolokia，来执行 org.springframework.boot:type=Endpoint,name=Info 这个 MBean 的 info 操作： + + + +指标 Metrics 是快速定位问题的“金钥匙” + +指标是指一组和时间关联的、衡量某个维度能力的量化数值。通过收集指标并展现为曲线图、饼图等图表，可以帮助我们快速定位、分析问题。 + +我们通过一个实际的案例，来看看如何通过图表快速定位问题。 + +有一个外卖订单的下单和配送流程，如下图所示。OrderController 进行下单操作，下单操作前先判断参数，如果参数正确调用另一个服务查询商户状态，如果商户在营业的话继续下单，下单成功后发一条消息到 RabbitMQ 进行异步配送流程；然后另一个 DeliverOrderHandler 监听这条消息进行配送操作。 + + + +对于这样一个涉及同步调用和异步调用的业务流程，如果用户反馈下单失败，那我们如何才能快速知道是哪个环节出了问题呢？ + +这时，指标体系就可以发挥作用了。我们可以分别为下单和配送这两个重要操作，建立一些指标进行监控。 + +对于下单操作，可以建立 4 个指标： + +下单总数量指标，监控整个系统当前累计的下单量； + +下单请求指标，对于每次收到下单请求，在处理之前 +1； + +下单成功指标，每次下单成功完成 +1； + +下单失败指标，下单操作处理出现异常 +1，并且把异常原因附加到指标上。 + +对于配送操作，也是建立类似的 4 个指标。我们可以使用 Micrometer 框架实现指标的收集，它也是 Spring Boot Actuator 选用的指标框架。它实现了各种指标的抽象，常用的有三种： + +gauge（红色），它反映的是指标当前的值，是多少就是多少，不能累计，比如本例中的下单总数量指标，又比如游戏的在线人数、JVM 当前线程数都可以认为是 gauge。 + +counter（绿色），每次调用一次方法值增加 1，是可以累计的，比如本例中的下单请求指标。举一个例子，如果 5 秒内我们调用了 10 次方法，Micrometer 也是每隔 5 秒把指标发送给后端存储系统一次，那么它可以只发送一次值，其值为 10。 + +timer（蓝色），类似 counter，只不过除了记录次数，还记录耗时，比如本例中的下单成功和下单失败两个指标。 + +所有的指标还可以附加一些 tags 标签，作为补充数据。比如，当操作执行失败的时候，我们就会附加一个 reason 标签到指标上。 + +Micrometer 除了抽象了指标外，还抽象了存储。你可以把 Micrometer 理解为类似 SLF4J 这样的框架，只不过后者针对日志抽象，而 Micrometer 是针对指标进行抽象。Micrometer 通过引入各种 registry，可以实现无缝对接各种监控系统或时间序列数据库。 + +在这个案例中，我们引入了 micrometer-registry-influx 依赖，目的是引入 Micrometer 的核心依赖，以及通过 Micrometer 对于InfluxDB（InfluxDB 是一个时间序列数据库，其专长是存储指标数据）的绑定，以实现指标数据可以保存到 InfluxDB： + + + + io.micrometer + + micrometer-registry-influx + + + + + +然后，修改配置文件，启用指标输出到 InfluxDB 的开关、配置 InfluxDB 的地址，以及设置指标每秒在客户端聚合一次，然后发送到 InfluxDB： + +management.metrics.export.influx.enabled=true + +management.metrics.export.influx.uri=http://localhost:8086 + +management.metrics.export.influx.step=1S + + + +接下来，我们在业务逻辑中增加相关的代码来记录指标。 + +下面是 OrderController 的实现，代码中有详细注释，我就不一一说明了。你需要注意观察如何通过 Micrometer 框架，来实现下单总数量、下单请求、下单成功和下单失败这四个指标，分别对应代码的第 17、25、43、47 行： + +//下单操作，以及商户服务的接口 + +@Slf4j + +@RestController + +@RequestMapping("order") + +public class OrderController { + + //总订单创建数量 + + private AtomicLong createOrderCounter = new AtomicLong(); + + @Autowired + + private RabbitTemplate rabbitTemplate; + + @Autowired + + private RestTemplate restTemplate; + + + + @PostConstruct + + public void init() { + + //注册createOrder.received指标，gauge指标只需要像这样初始化一次，直接关联到AtomicLong引用即可 + + Metrics.gauge("createOrder.totalSuccess", createOrderCounter); + + } + + + + //下单接口，提供用户ID和商户ID作为入参 + + @GetMapping("createOrder") + + public void createOrder(@RequestParam("userId") long userId, @RequestParam("merchantId") long merchantId) { + + //记录一次createOrder.received指标，这是一个counter指标，表示收到下单请求 + + Metrics.counter("createOrder.received").increment(); + + Instant begin = Instant.now(); + + try { + + TimeUnit.MILLISECONDS.sleep(200); + + //模拟无效用户的情况，ID<10为无效用户 + + if (userId < 10) + + throw new RuntimeException("invalid user"); + + //查询商户服务 + + Boolean merchantStatus = restTemplate.getForObject("http://localhost:45678/order/getMerchantStatus?merchantId=" + merchantId, Boolean.class); + + if (merchantStatus == null || !merchantStatus) + + throw new RuntimeException("closed merchant"); + + Order order = new Order(); + + order.setId(createOrderCounter.incrementAndGet()); //gauge指标可以得到自动更新 + + order.setUserId(userId); + + order.setMerchantId(merchantId); + + //发送MQ消息 + + rabbitTemplate.convertAndSend(Consts.EXCHANGE, Consts.ROUTING_KEY, order); + + //记录一次createOrder.success指标，这是一个timer指标，表示下单成功，同时提供耗时 + + Metrics.timer("createOrder.success").record(Duration.between(begin, Instant.now())); + + } catch (Exception ex) { + + log.error("creareOrder userId {} failed", userId, ex); + + //记录一次createOrder.failed指标，这是一个timer指标，表示下单失败，同时提供耗时，并且以tag记录失败原因 + + Metrics.timer("createOrder.failed", "reason", ex.getMessage()).record(Duration.between(begin, Instant.now())); + + } + + } + + + + //商户查询接口 + + @GetMapping("getMerchantStatus") + + public boolean getMerchantStatus(@RequestParam("merchantId") long merchantId) throws InterruptedException { + + //只有商户ID为2的商户才是营业的 + + TimeUnit.MILLISECONDS.sleep(200); + + return merchantId == 2; + + } + +} + + + +当用户 ID + +接下来是 DeliverOrderHandler 配送服务的实现。 + +其中，deliverOrder 方法监听 OrderController 发出的 MQ 消息模拟配送。如下代码所示，第 17、25、32 和 36 行代码，实现了配送相关四个指标的记录： + +//配送服务消息处理程序 + +@RestController + +@Slf4j + +@RequestMapping("deliver") + +public class DeliverOrderHandler { + + //配送服务运行状态 + + private volatile boolean deliverStatus = true; + + private AtomicLong deliverCounter = new AtomicLong(); + + //通过一个外部接口来改变配送状态模拟配送服务停工 + + @PostMapping("status") + + public void status(@RequestParam("status") boolean status) { + + deliverStatus = status; + + } + + @PostConstruct + + public void init() { + + //同样注册一个gauge指标deliverOrder.totalSuccess，代表总的配送单量，只需注册一次即可 + + Metrics.gauge("deliverOrder.totalSuccess", deliverCounter); + + } + + //监听MQ消息 + + @RabbitListener(queues = Consts.QUEUE_NAME) + + public void deliverOrder(Order order) { + + Instant begin = Instant.now(); + + //对deliverOrder.received进行递增，代表收到一次订单消息，counter类型 + + Metrics.counter("deliverOrder.received").increment(); + + try { + + if (!deliverStatus) + + throw new RuntimeException("deliver outofservice"); + + TimeUnit.MILLISECONDS.sleep(500); + + deliverCounter.incrementAndGet(); + + //配送成功指标deliverOrder.success，timer类型 + + Metrics.timer("deliverOrder.success").record(Duration.between(begin, Instant.now())); + + } catch (Exception ex) { + + log.error("deliver Order {} failed", order, ex); + + //配送失败指标deliverOrder.failed，同样附加了失败原因作为tags，timer类型 + + Metrics.timer("deliverOrder.failed", "reason", ex.getMessage()).record(Duration.between(begin, Instant.now())); + + } + + } + +} + + + +同时，我们模拟了一个配送服务整体状态的开关，调用 status 接口可以修改其状态。至此，我们完成了场景准备，接下来开始配置指标监控。 + +首先，我们来安装 Grafana。然后进入 Grafana 配置一个 InfluxDB 数据源： + + + +配置好数据源之后，就可以添加一个监控面板，然后在面板中添加各种监控图表。比如，我们在一个下单次数图表中添加了下单收到、成功和失败三个指标。 + + + +关于这张图中的配置： + +红色框数据源配置，选择刚才配置的数据源。 + +蓝色框 FROM 配置，选择我们的指标名。 + +绿色框 SELECT 配置，选择我们要查询的指标字段，也可以应用一些聚合函数。在这里，我们取 count 字段的值，然后使用 sum 函数进行求和。 + +紫色框 GROUP BY 配置，我们配置了按 1 分钟时间粒度和 reason 字段进行分组，这样指标的 Y 轴代表 QPM（每分钟请求数），且每种失败的情况都会绘制单独的曲线。 + +黄色框 ALIAS BY 配置中设置了每一个指标的别名，在别名中引用了 reason 这个 tag。 + +使用 Grafana 配置 InfluxDB 指标的详细方式，你可以参考这里。其中的 FROM、SELECT、GROUP BY 的含义和 SQL 类似，理解起来应该不困难。 + +类似地， 我们配置出一个完整的业务监控面板，包含之前实现的 8 个指标： + +配置 2 个 Gauge 图表分别呈现总订单完成次数、总配送完成次数。 + +配置 4 个 Graph 图表分别呈现下单操作的次数和性能，以及配送操作的次数和性能。 + +下面我们进入实战，使用 wrk 针对四种情况进行压测，然后通过曲线来分析定位问题。 + +第一种情况是，使用合法的用户 ID 和营业的商户 ID 运行一段时间： + +wrk -t 1 -c 1 -d 3600s http://localhost:45678/order/createOrder\?userId\=20\&merchantId\=2 + + + +从监控面板可以一目了然地看到整个系统的运作情况。可以看到，目前系统运行良好，不管是下单还是配送操作都是成功的，且下单操作平均处理时间 400ms、配送操作则是在 500ms 左右，符合预期（注意，下单次数曲线中的绿色和黄色两条曲线其实是重叠在一起的，表示所有下单都成功了）： + + + +第二种情况是，模拟无效用户 ID 运行一段时间： + +wrk -t 1 -c 1 -d 3600s http://localhost:45678/order/createOrder\?userId\=2\&merchantId\=2 + + + +使用无效用户下单，显然会导致下单全部失败。接下来，我们就看看从监控图中是否能看到这个现象。 + +绿色框可以看到，下单现在出现了 invalid user 这条蓝色的曲线，并和绿色收到下单请求的曲线是吻合的，表示所有下单都失败了，原因是无效用户错误，说明源头并没有问题。 + +红色框可以看到，虽然下单都是失败的，但是下单操作时间从 400ms 减少为 200ms 了，说明下单失败之前也消耗了 200ms（和代码符合）。而因为下单失败操作的响应时间减半了，反而导致吞吐翻倍了。 + +观察两个配送监控可以发现，配送曲线出现掉 0 现象，是因为下单失败导致的，下单失败 MQ 消息压根就不会发出。再注意下蓝色那条线，可以看到配送曲线掉 0 延后于下单成功曲线的掉 0，原因是配送走的是异步流程，虽然从某个时刻开始下单全部失败了，但是 MQ 队列中还有一些之前未处理的消息。 + + + +第三种情况是，尝试一下因为商户不营业导致的下单失败： + +wrk -t 1 -c 1 -d 3600s http://localhost:45678/order/createOrder\?userId\=20\&merchantId\=1 + + + +我把变化的地方圈了出来，你可以自己尝试分析一下： + + + +第四种情况是，配送停止。我们通过 curl 调用接口，来设置配送停止开关： + +curl -X POST 'http://localhost:45678/deliver/status?status=false' + + + +从监控可以看到，从开关关闭那刻开始，所有的配送消息全部处理失败了，原因是 deliver outofservice，配送操作性能从 500ms 左右到了 0ms，说明配送失败是一个本地快速失败，并不是因为服务超时等导致的失败。而且虽然配送失败，但下单操作都是正常的： + + + +最后希望说的是，除了手动添加业务监控指标外，Micrometer 框架还帮我们自动做了很多有关 JVM 内部各种数据的指标。进入 InfluxDB 命令行客户端，你可以看到下面的这些表（指标），其中前 8 个是我们自己建的业务指标，后面都是框架帮我们建的 JVM、各种组件状态的指标： + +\> USE mydb + +Using database mydb + +\> SHOW MEASUREMENTS + +name: measurements + +name + +\---- + +createOrder_failed + +createOrder_received + +createOrder_success + +createOrder_totalSuccess + +deliverOrder_failed + +deliverOrder_received + +deliverOrder_success + +deliverOrder_totalSuccess + +hikaricp_connections + +hikaricp_connections_acquire + +hikaricp_connections_active + +hikaricp_connections_creation + +hikaricp_connections_idle + +hikaricp_connections_max + +hikaricp_connections_min + +hikaricp_connections_pending + +hikaricp_connections_timeout + +hikaricp_connections_usage + +http_server_requests + +jdbc_connections_max + +jdbc_connections_min + +jvm_buffer_count + +jvm_buffer_memory_used + +jvm_buffer_total_capacity + +jvm_classes_loaded + +jvm_classes_unloaded + +jvm_gc_live_data_size + +jvm_gc_max_data_size + +jvm_gc_memory_allocated + +jvm_gc_memory_promoted + +jvm_gc_pause + +jvm_memory_committed + +jvm_memory_max + +jvm_memory_used + +jvm_threads_daemon + +jvm_threads_live + +jvm_threads_peak + +jvm_threads_states + +logback_events + +process_cpu_usage + +process_files_max + +process_files_open + +process_start_time + +process_uptime + +rabbitmq_acknowledged + +rabbitmq_acknowledged_published + +rabbitmq_channels + +rabbitmq_connections + +rabbitmq_consumed + +rabbitmq_failed_to_publish + +rabbitmq_not_acknowledged_published + +rabbitmq_published + +rabbitmq_rejected + +rabbitmq_unrouted_published + +spring_rabbitmq_listener + +system_cpu_count + +system_cpu_usage + +system_load_average_1m + +tomcat_sessions_active_current + +tomcat_sessions_active_max + +tomcat_sessions_alive_max + +tomcat_sessions_created + +tomcat_sessions_expired + +tomcat_sessions_rejected + + + +我们可以按照自己的需求，选取其中的一些指标，在 Grafana 中配置应用监控面板： + + + +看到这里，通过监控图表来定位问题，是不是比日志方便了很多呢？ + +重点回顾 + +今天，我和你介绍了如何使用 Spring Boot Actuaor 实现生产就绪的几个关键点，包括健康检测、暴露应用信息和指标监控。 + +所谓磨刀不误砍柴工，健康检测可以帮我们实现负载均衡的联动；应用信息以及 Actuaor 提供的各种端点，可以帮我们查看应用内部情况，甚至对应用的一些参数进行调整；而指标监控，则有助于我们整体观察应用运行情况，帮助我们快速发现和定位问题。 + +其实，完整的应用监控体系一般由三个方面构成，包括日志 Logging、指标 Metrics 和追踪 Tracing。其中，日志和指标我相信你应该已经比较清楚了。追踪一般不涉及开发工作就没有展开阐述，我和你简单介绍一下。 + +追踪也叫做全链路追踪，比较有代表性的开源系统是SkyWalking和Pinpoint。一般而言，接入此类系统无需额外开发，使用其提供的 javaagent 来启动 Java 程序，就可以通过动态修改字节码实现各种组件的改写，以加入追踪代码（类似 AOP）。 + +全链路追踪的原理是： + +请求进入第一个组件时，先生成一个 TraceID，作为整个调用链（Trace）的唯一标识； + +对于每次操作，都记录耗时和相关信息形成一个 Span 挂载到调用链上，Span 和 Span 之间同样可以形成树状关联，出现远程调用、跨系统调用的时候，把 TraceID 进行透传（比如，HTTP 调用通过请求透传，MQ 消息则通过消息透传）； + +把这些数据汇总提交到数据库中，通过一个 UI 界面查询整个树状调用链。 + +同时，我们一般会把 TraceID 记录到日志中，方便实现日志和追踪的关联。 + +我用一张图对比了日志、指标和追踪的区别和特点： + + + +在我看来，完善的监控体系三者缺一不可，它们还可以相互配合，比如通过指标发现性能问题，通过追踪定位性能问题所在的应用和操作，最后通过日志定位出具体请求的明细参数。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +Spring Boot Actuator 提供了大量内置端点，你觉得端点和自定义一个 @RestController 有什么区别呢？你能否根据官方文档，开发一个自定义端点呢？ + +在介绍指标 Metrics 时我们看到，InfluxDB 中保存了由 Micrometer 框架自动帮我们收集的一些应用指标。你能否参考源码中两个 Grafana 配置的 JSON 文件，把这些指标在 Grafana 中配置出一个完整的应用监控面板呢？ + +应用投产之前，你还会做哪些生产就绪方面的工作呢？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/25异步处理好用，但非常容易用错.md b/专栏/Java业务开发常见错误100例/25异步处理好用，但非常容易用错.md new file mode 100644 index 0000000..5eda5a0 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/25异步处理好用，但非常容易用错.md @@ -0,0 +1,918 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 25 异步处理好用，但非常容易用错 + 今天，我来和你聊聊好用但容易出错的异步处理。 + +异步处理是互联网应用不可或缺的一种架构模式，大多数业务项目都是由同步处理、异步处理和定时任务处理三种模式相辅相成实现的。 + +区别于同步处理，异步处理无需同步等待流程处理完毕，因此适用场景主要包括： + +服务于主流程的分支流程。比如，在注册流程中，把数据写入数据库的操作是主流程，但注册后给用户发优惠券或欢迎短信的操作是分支流程，时效性不那么强，可以进行异步处理。 + +用户不需要实时看到结果的流程。比如，下单后的配货、送货流程完全可以进行异步处理，每个阶段处理完成后，再给用户发推送或短信让用户知晓即可。 + +同时，异步处理因为可以有 MQ 中间件的介入用于任务的缓冲的分发，所以相比于同步处理，在应对流量洪峰、实现模块解耦和消息广播方面有功能优势。 + +不过，异步处理虽然好用，但在实现的时候却有三个最容易犯的错，分别是异步处理流程的可靠性问题、消息发送模式的区分问题，以及大量死信消息堵塞队列的问题。今天，我就用三个代码案例结合目前常用的 MQ 系统 RabbitMQ，来和你具体聊聊。 + +今天这一讲的演示，我都会使用 Spring AMQP 来操作 RabbitMQ，所以你需要先引入 amqp 依赖： + + + + org.springframework.boot + + spring-boot-starter-amqp + + + + + +异步处理需要消息补偿闭环 + +使用类似 RabbitMQ、RocketMQ 等 MQ 系统来做消息队列实现异步处理，虽然说消息可以落地到磁盘保存，即使 MQ 出现问题消息数据也不会丢失，但是异步流程在消息发送、传输、处理等环节，都可能发生消息丢失。此外，任何 MQ 中间件都无法确保 100% 可用，需要考虑不可用时异步流程如何继续进行。 + +因此，对于异步处理流程，必须考虑补偿或者说建立主备双活流程。 + +我们来看一个用户注册后异步发送欢迎消息的场景。用户注册落数据库的流程为同步流程，会员服务收到消息后发送欢迎消息的流程为异步流程。 + + + +我们来分析一下： + +蓝色的线，使用 MQ 进行的异步处理，我们称作主线，可能存在消息丢失的情况（虚线代表异步调用）； + +绿色的线，使用补偿 Job 定期进行消息补偿，我们称作备线，用来补偿主线丢失的消息； + +考虑到极端的 MQ 中间件失效的情况，我们要求备线的处理吞吐能力达到主线的能力水平。 + +我们来看一下相关的实现代码。 + +首先，定义 UserController 用于注册 + 发送异步消息。对于注册方法，我们一次性注册 10 个用户，用户注册消息不能发送出去的概率为 50%。 + +@RestController + +@Slf4j + +@RequestMapping("user") + +public class UserController { + + @Autowired + + private UserService userService; + + @Autowired + + private RabbitTemplate rabbitTemplate; + + @GetMapping("register") + + public void register() { + + //模拟10个用户注册 + + IntStream.rangeClosed(1, 10).forEach(i -> { + + //落库 + + User user = userService.register(); + + //模拟50%的消息可能发送失败 + + if (ThreadLocalRandom.current().nextInt(10) % 2 == 0) { + + //通过RabbitMQ发送消息 + + rabbitTemplate.convertAndSend(RabbitConfiguration.EXCHANGE, RabbitConfiguration.ROUTING_KEY, user); + + log.info("sent mq user {}", user.getId()); + + } + + }); + + } + +} + + + +然后，定义 MemberService 类用于模拟会员服务。会员服务监听用户注册成功的消息，并发送欢迎短信。我们使用 ConcurrentHashMap 来存放那些发过短信的用户 ID 实现幂等，避免相同的用户进行补偿时重复发送短信： + +@Component + +@Slf4j + +public class MemberService { + + //发送欢迎消息的状态 + + private Map welcomeStatus = new ConcurrentHashMap<>(); + + //监听用户注册成功的消息，发送欢迎消息 + + @RabbitListener(queues = RabbitConfiguration.QUEUE) + + public void listen(User user) { + + log.info("receive mq user {}", user.getId()); + + welcome(user); + + } + + //发送欢迎消息 + + public void welcome(User user) { + + //去重操作 + + if (welcomeStatus.putIfAbsent(user.getId(), true) == null) { + + try { + + TimeUnit.SECONDS.sleep(2); + + } catch (InterruptedException e) { + + } + + log.info("memberService: welcome new user {}", user.getId()); + + } + + } + +} + + + +对于 MQ 消费程序，处理逻辑务必考虑去重（支持幂等），原因有几个： + +MQ 消息可能会因为中间件本身配置错误、稳定性等原因出现重复。 + +自动补偿重复，比如本例，同一条消息可能既走 MQ 也走补偿，肯定会出现重复，而且考虑到高内聚，补偿 Job 本身不会做去重处理。 + +人工补偿重复。出现消息堆积时，异步处理流程必然会延迟。如果我们提供了通过后台进行补偿的功能，那么在处理遇到延迟的时候，很可能会先进行人工补偿，过了一段时间后处理程序又收到消息了，重复处理。我之前就遇到过一次由 MQ 故障引发的事故，MQ 中堆积了几十万条发放资金的消息，导致业务无法及时处理，运营以为程序出错了就先通过后台进行了人工处理，结果 MQ 系统恢复后消息又被重复处理了一次，造成大量资金重复发放。 + +接下来，定义补偿 Job 也就是备线操作。 + +我们在 CompensationJob 中定义一个 @Scheduled 定时任务，5 秒做一次补偿操作，因为 Job 并不知道哪些用户注册的消息可能丢失，所以是全量补偿，补偿逻辑是：每 5 秒补偿一次，按顺序一次补偿 5 个用户，下一次补偿操作从上一次补偿的最后一个用户 ID 开始；对于补偿任务我们提交到线程池进行“异步”处理，提高处理能力。 + +@Component + +@Slf4j + +public class CompensationJob { + + //补偿Job异步处理线程池 + + private static ThreadPoolExecutor compensationThreadPool = new ThreadPoolExecutor( + + 10, 10, + + 1, TimeUnit.HOURS, + + new ArrayBlockingQueue<>(1000), + + new ThreadFactoryBuilder().setNameFormat("compensation-threadpool-%d").get()); + + @Autowired + + private UserService userService; + + @Autowired + + private MemberService memberService; + + //目前补偿到哪个用户ID + + private long offset = 0; + + //10秒后开始补偿，5秒补偿一次 + + @Scheduled(initialDelay = 10_000, fixedRate = 5_000) + + public void compensationJob() { + + log.info("开始从用户ID {} 补偿", offset); + + //获取从offset开始的用户 + + userService.getUsersAfterIdWithLimit(offset, 5).forEach(user -> { + + compensationThreadPool.execute(() -> memberService.welcome(user)); + + offset = user.getId(); + + }); + + } + +} + + + +为了实现高内聚，主线和备线处理消息，最好使用同一个方法。比如，本例中 MemberService 监听到 MQ 消息和 CompensationJob 补偿，调用的都是 welcome 方法。 + +此外值得一说的是，Demo 中的补偿逻辑比较简单，生产级的代码应该在以下几个方面进行加强： + +考虑配置补偿的频次、每次处理数量，以及补偿线程池大小等参数为合适的值，以满足补偿的吞吐量。 + +考虑备线补偿数据进行适当延迟。比如，对注册时间在 30 秒之前的用户再进行补偿，以方便和主线 MQ 实时流程错开，避免冲突。 + +诸如当前补偿到哪个用户的 offset 数据，需要落地数据库。 + +补偿 Job 本身需要高可用，可以使用类似 XXLJob 或 ElasticJob 等任务系统。 + +运行程序，执行注册方法注册 10 个用户，输出如下： + +[17:01:16.570] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.a.compensation.UserController:28 ] - sent mq user 1 + +[17:01:16.571] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.a.compensation.UserController:28 ] - sent mq user 5 + +[17:01:16.572] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.a.compensation.UserController:28 ] - sent mq user 7 + +[17:01:16.573] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.a.compensation.UserController:28 ] - sent mq user 8 + +[17:01:16.594] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:18 ] - receive mq user 1 + +[17:01:18.597] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 1 + +[17:01:18.601] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:18 ] - receive mq user 5 + +[17:01:20.603] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 5 + +[17:01:20.604] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:18 ] - receive mq user 7 + +[17:01:22.605] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 7 + +[17:01:22.606] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:18 ] - receive mq user 8 + +[17:01:24.611] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 8 + +[17:01:25.498] [scheduling-1] [INFO ] [o.g.t.c.a.compensation.CompensationJob:29 ] - 开始从用户ID 0 补偿 + +[17:01:27.510] [compensation-threadpool-1] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 2 + +[17:01:27.510] [compensation-threadpool-3] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 4 + +[17:01:27.511] [compensation-threadpool-2] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 3 + +[17:01:30.496] [scheduling-1] [INFO ] [o.g.t.c.a.compensation.CompensationJob:29 ] - 开始从用户ID 5 补偿 + +[17:01:32.500] [compensation-threadpool-6] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 6 + +[17:01:32.500] [compensation-threadpool-9] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 9 + +[17:01:35.496] [scheduling-1] [INFO ] [o.g.t.c.a.compensation.CompensationJob:29 ] - 开始从用户ID 9 补偿 + +[17:01:37.501] [compensation-threadpool-0] [INFO ] [o.g.t.c.a.compensation.MemberService:28 ] - memberService: welcome new user 10 + +[17:01:40.495] [scheduling-1] [INFO ] [o.g.t.c.a.compensation.CompensationJob:29 ] - 开始从用户ID 10 补偿 + + + +可以看到： + +总共 10 个用户，MQ 发送成功的用户有四个，分别是用户 1、5、7、8。 + +补偿任务第一次运行，补偿了用户 2、3、4，第二次运行补偿了用户 6、9，第三次运行补充了用户 10。 + +最后提一下，针对消息的补偿闭环处理的最高标准是，能够达到补偿全量数据的吞吐量。也就是说，如果补偿备线足够完善，即使直接把 MQ 停机，虽然会略微影响处理的及时性，但至少确保流程都能正常执行。 + +注意消息模式是广播还是工作队列 + +在今天这一讲的一开始，我们提到异步处理的一个重要优势，是实现消息广播。 + +消息广播，和我们平时说的“广播”意思差不多，就是希望同一条消息，不同消费者都能分别消费；而队列模式，就是不同消费者共享消费同一个队列的数据，相同消息只能被某一个消费者消费一次。 + +比如，同一个用户的注册消息，会员服务需要监听以发送欢迎短信，营销服务同样需要监听以发送新用户小礼物。但是，会员服务、营销服务都可能有多个实例，我们期望的是同一个用户的消息，可以同时广播给不同的服务（广播模式），但对于同一个服务的不同实例（比如会员服务 1 和会员服务 2），不管哪个实例来处理，处理一次即可（工作队列模式）： + + + +在实现代码的时候，我们务必确认 MQ 系统的机制，确保消息的路由按照我们的期望。 + +对于类似 RocketMQ 这样的 MQ 来说，实现类似功能比较简单直白：如果消费者属于一个组，那么消息只会由同一个组的一个消费者来消费；如果消费者属于不同组，那么每个组都能消费一遍消息。 + +而对于 RabbitMQ 来说，消息路由的模式采用的是队列 + 交换器，队列是消息的载体，交换器决定了消息路由到队列的方式，配置比较复杂，容易出错。所以，接下来我重点和你讲讲 RabbitMQ 的相关代码实现。 + +我们还是以上面的架构图为例，来演示使用 RabbitMQ 实现广播模式和工作队列模式的坑。 + +第一步，实现会员服务监听用户服务发出的新用户注册消息的那部分逻辑。 + +如果我们启动两个会员服务，那么同一个用户的注册消息应该只能被其中一个实例消费。 + +我们分别实现 RabbitMQ 队列、交换器、绑定三件套。其中，队列用的是匿名队列，交换器用的是直接交换器 DirectExchange，交换器绑定到匿名队列的路由 Key 是空字符串。在收到消息之后，我们会打印所在实例使用的端口： + +//为了代码简洁直观，我们把消息发布者、消费者、以及MQ的配置代码都放在了一起 + +@Slf4j + +@Configuration + +@RestController + +@RequestMapping("workqueuewrong") + +public class WorkQueueWrong { + + private static final String EXCHANGE = "newuserExchange"; + + @Autowired + + private RabbitTemplate rabbitTemplate; + + @GetMapping + + public void sendMessage() { + + rabbitTemplate.convertAndSend(EXCHANGE, "", UUID.randomUUID().toString()); + + } + + //使用匿名队列作为消息队列 + + @Bean + + public Queue queue() { + + return new AnonymousQueue(); + + } + + + + //声明DirectExchange交换器，绑定队列到交换器 + + @Bean + + public Declarables declarables() { + + DirectExchange exchange = new DirectExchange(EXCHANGE); + + return new Declarables(queue(), exchange, + + BindingBuilder.bind(queue()).to(exchange).with("")); + + } + + //监听队列，队列名称直接通过SpEL表达式引用Bean + + @RabbitListener(queues = "#{queue.name}") + + public void memberService(String userName) { + + log.info("memberService: welcome message sent to new user {} from {}", userName, System.getProperty("server.port")); + + } + +} + + + +使用 12345 和 45678 两个端口启动两个程序实例后，调用 sendMessage 接口发送一条消息，输出的日志，显示同一个会员服务两个实例都收到了消息： + + + + + +出现这个问题的原因是，我们没有理清楚 RabbitMQ 直接交换器和队列的绑定关系。 + +如下图所示，RabbitMQ 的直接交换器根据 routingKey 对消息进行路由。由于我们的程序每次启动都会创建匿名（随机命名）的队列，所以相当于每一个会员服务实例都对应独立的队列，以空 routingKey 绑定到直接交换器。用户服务发出消息的时候也设置了 routingKey 为空，所以直接交换器收到消息之后，发现有两条队列匹配，于是都转发了消息： + + + +要修复这个问题其实很简单，对于会员服务不要使用匿名队列，而是使用同一个队列即可。把上面代码中的匿名队列替换为一个普通队列： + +private static final String QUEUE = "newuserQueue"; + +@Bean + +public Queue queue() { + + return new Queue(QUEUE); + +} + + + +测试发现，对于同一条消息来说，两个实例中只有一个实例可以收到，不同的消息按照轮询分发给不同的实例。现在，交换器和队列的关系是这样的： + + + +第二步，进一步完整实现用户服务需要广播消息给会员服务和营销服务的逻辑。 + +我们希望会员服务和营销服务都可以收到广播消息，但会员服务或营销服务中的每个实例只需要收到一次消息。 + +代码如下，我们声明了一个队列和一个广播交换器 FanoutExchange，然后模拟两个用户服务和两个营销服务： + +@Slf4j + +@Configuration + +@RestController + +@RequestMapping("fanoutwrong") + +public class FanoutQueueWrong { + + private static final String QUEUE = "newuser"; + + private static final String EXCHANGE = "newuser"; + + @Autowired + + private RabbitTemplate rabbitTemplate; + + @GetMapping + + public void sendMessage() { + + rabbitTemplate.convertAndSend(EXCHANGE, "", UUID.randomUUID().toString()); + + } + + //声明FanoutExchange，然后绑定到队列，FanoutExchange绑定队列的时候不需要routingKey + + @Bean + + public Declarables declarables() { + + Queue queue = new Queue(QUEUE); + + FanoutExchange exchange = new FanoutExchange(EXCHANGE); + + return new Declarables(queue, exchange, + + BindingBuilder.bind(queue).to(exchange)); + + } + + //会员服务实例1 + + @RabbitListener(queues = QUEUE) + + public void memberService1(String userName) { + + log.info("memberService1: welcome message sent to new user {}", userName); + + } + + //会员服务实例2 + + @RabbitListener(queues = QUEUE) + + public void memberService2(String userName) { + + log.info("memberService2: welcome message sent to new user {}", userName); + + } + + //营销服务实例1 + + @RabbitListener(queues = QUEUE) + + public void promotionService1(String userName) { + + log.info("promotionService1: gift sent to new user {}", userName); + + } + + //营销服务实例2 + + @RabbitListener(queues = QUEUE) + + public void promotionService2(String userName) { + + log.info("promotionService2: gift sent to new user {}", userName); + + } + +} + + + +我们请求四次 sendMessage 接口，注册四个用户。通过日志可以发现，一条用户注册的消息，要么被会员服务收到，要么被营销服务收到，显然这不是广播。那，我们使用的 FanoutExchange，看名字就应该是实现广播的交换器，为什么根本没有起作用呢？ + + + +其实，广播交换器非常简单，它会忽略 routingKey，广播消息到所有绑定的队列。在这个案例中，两个会员服务和两个营销服务都绑定了同一个队列，所以这四个服务只能收到一次消息： + + + +修改方式很简单，我们把队列进行拆分，会员和营销两组服务分别使用一条独立队列绑定到广播交换器即可： + +@Slf4j + +@Configuration + +@RestController + +@RequestMapping("fanoutright") + +public class FanoutQueueRight { + + private static final String MEMBER_QUEUE = "newusermember"; + + private static final String PROMOTION_QUEUE = "newuserpromotion"; + + private static final String EXCHANGE = "newuser"; + + @Autowired + + private RabbitTemplate rabbitTemplate; + + @GetMapping + + public void sendMessage() { + + rabbitTemplate.convertAndSend(EXCHANGE, "", UUID.randomUUID().toString()); + + } + + @Bean + + public Declarables declarables() { + + //会员服务队列 + + Queue memberQueue = new Queue(MEMBER_QUEUE); + + //营销服务队列 + + Queue promotionQueue = new Queue(PROMOTION_QUEUE); + + //广播交换器 + + FanoutExchange exchange = new FanoutExchange(EXCHANGE); + + //两个队列绑定到同一个交换器 + + return new Declarables(memberQueue, promotionQueue, exchange, + + BindingBuilder.bind(memberQueue).to(exchange), + + BindingBuilder.bind(promotionQueue).to(exchange)); + + } + + @RabbitListener(queues = MEMBER_QUEUE) + + public void memberService1(String userName) { + + log.info("memberService1: welcome message sent to new user {}", userName); + + } + + @RabbitListener(queues = MEMBER_QUEUE) + + public void memberService2(String userName) { + + log.info("memberService2: welcome message sent to new user {}", userName); + + } + + @RabbitListener(queues = PROMOTION_QUEUE) + + public void promotionService1(String userName) { + + log.info("promotionService1: gift sent to new user {}", userName); + + } + + @RabbitListener(queues = PROMOTION_QUEUE) + + public void promotionService2(String userName) { + + log.info("promotionService2: gift sent to new user {}", userName); + + } + +} + + + +现在，交换器和队列的结构是这样的： + + + +从日志输出可以验证，对于每一条 MQ 消息，会员服务和营销服务分别都会收到一次，一条消息广播到两个服务的同时，在每一个服务的两个实例中通过轮询接收： + + + +所以说，理解了 RabbitMQ 直接交换器、广播交换器的工作方式之后，我们对消息的路由方式了解得很清晰了，实现代码就不会出错。 + +对于异步流程来说，消息路由模式一旦配置出错，轻则可能导致消息的重复处理，重则可能导致重要的服务无法接收到消息，最终造成业务逻辑错误。 + +每个 MQ 中间件对消息的路由处理的配置各不相同，我们一定要先了解原理再着手编码。 + +别让死信堵塞了消息队列 + +我们在介绍线程池的时候提到，如果线程池的任务队列没有上限，那么最终可能会导致 OOM。使用消息队列处理异步流程的时候，我们也同样要注意消息队列的任务堆积问题。对于突发流量引起的消息队列堆积，问题并不大，适当调整消费者的消费能力应该就可以解决。但在很多时候，消息队列的堆积堵塞，是因为有大量始终无法处理的消息。 + +比如，用户服务在用户注册后发出一条消息，会员服务监听到消息后给用户派发优惠券，但因为用户并没有保存成功，会员服务处理消息始终失败，消息重新进入队列，然后还是处理失败。这种在 MQ 中像幽灵一样回荡的同一条消息，就是死信。 + +随着 MQ 被越来越多的死信填满，消费者需要花费大量时间反复处理死信，导致正常消息的消费受阻，最终 MQ 可能因为数据量过大而崩溃。 + +我们来测试一下这个场景。首先，定义一个队列、一个直接交换器，然后把队列绑定到交换器： + +@Bean + +public Declarables declarables() { + + //队列 + + Queue queue = new Queue(Consts.QUEUE); + + //交换器 + + DirectExchange directExchange = new DirectExchange(Consts.EXCHANGE); + + //快速声明一组对象，包含队列、交换器，以及队列到交换器的绑定 + + return new Declarables(queue, directExchange, + + BindingBuilder.bind(queue).to(directExchange).with(Consts.ROUTING_KEY)); + +} + + + +然后，实现一个 sendMessage 方法来发送消息到 MQ，访问一次提交一条消息，使用自增标识作为消息内容： + + +//自增消息标识 + +AtomicLong atomicLong = new AtomicLong(); + +@Autowired + +private RabbitTemplate rabbitTemplate; + +@GetMapping("sendMessage") + +public void sendMessage() { + + String msg = "msg" + atomicLong.incrementAndGet(); + + log.info("send message {}", msg); + + //发送消息 + + rabbitTemplate.convertAndSend(Consts.EXCHANGE, msg); + +} + + + +收到消息后，直接抛出空指针异常，模拟处理出错的情况： + +@RabbitListener(queues = Consts.QUEUE) + +public void handler(String data) { + + log.info("got message {}", data); + + throw new NullPointerException("error"); + +} + + + +调用 sendMessage 接口发送两条消息，然后来到 RabbitMQ 管理台，可以看到这两条消息始终在队列中，不断被重新投递，导致重新投递 QPS 达到了 1063。 + + + +同时，在日志中可以看到大量异常信息： + + +[20:02:31.533] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [WARN ] [o.s.a.r.l.ConditionalRejectingErrorHandler:129 ] - Execution of Rabbit message listener failed. + +org.springframework.amqp.rabbit.support.ListenerExecutionFailedException: Listener method 'public void org.geekbang.time.commonmistakes.asyncprocess.deadletter.MQListener.handler(java.lang.String)' threw exception + + at org.springframework.amqp.rabbit.listener.adapter.MessagingMessageListenerAdapter.invokeHandler(MessagingMessageListenerAdapter.java:219) + + at org.springframework.amqp.rabbit.listener.adapter.MessagingMessageListenerAdapter.invokeHandlerAndProcessResult(MessagingMessageListenerAdapter.java:143) + + at org.springframework.amqp.rabbit.listener.adapter.MessagingMessageListenerAdapter.onMessage(MessagingMessageListenerAdapter.java:132) + + at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:1569) + + at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.actualInvokeListener(AbstractMessageListenerContainer.java:1488) + + at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:1476) + + at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:1467) + + at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.executeListener(AbstractMessageListenerContainer.java:1411) + + at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.doReceiveAndExecute(SimpleMessageListenerContainer.java:958) + + at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.receiveAndExecute(SimpleMessageListenerContainer.java:908) + + at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.access$1600(SimpleMessageListenerContainer.java:81) + + at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.mainLoop(SimpleMessageListenerContainer.java:1279) + + at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1185) + + at java.lang.Thread.run(Thread.java:748) + +Caused by: java.lang.NullPointerException: error + + at org.geekbang.time.commonmistakes.asyncprocess.deadletter.MQListener.handler(MQListener.java:14) + + at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source) + + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) + + at java.lang.reflect.Method.invoke(Method.java:498) + + at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:171) + + at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:120) + + at org.springframework.amqp.rabbit.listener.adapter.HandlerAdapter.invoke(HandlerAdapter.java:50) + + at org.springframework.amqp.rabbit.listener.adapter.MessagingMessageListenerAdapter.invokeHandler(MessagingMessageListenerAdapter.java:211) + + ... 13 common frames omitted + + + +解决死信无限重复进入队列最简单的方式是，在程序处理出错的时候，直接抛出 AmqpRejectAndDontRequeueException 异常，避免消息重新进入队列： + +throw new AmqpRejectAndDontRequeueException("error"); + + + +但，我们更希望的逻辑是，对于同一条消息，能够先进行几次重试，解决因为网络问题导致的偶发消息处理失败，如果还是不行的话，再把消息投递到专门的一个死信队列。对于来自死信队列的数据，我们可能只是记录日志发送报警，即使出现异常也不会再重复投递。整个逻辑如下图所示： + + + +针对这个问题，Spring AMQP 提供了非常方便的解决方案： + +首先，定义死信交换器和死信队列。其实，这些都是普通的交换器和队列，只不过被我们专门用于处理死信消息。 + +然后，通过 RetryInterceptorBuilder 构建一个 RetryOperationsInterceptor，用于处理失败时候的重试。这里的策略是，最多尝试 5 次（重试 4 次）；并且采取指数退避重试，首次重试延迟 1 秒，第二次 2 秒，以此类推，最大延迟是 10 秒；如果第 4 次重试还是失败，则使用 RepublishMessageRecoverer 把消息重新投入一个“死信交换器”中。 + +最后，定义死信队列的处理程序。这个案例中，我们只是简单记录日志。 + +对应的实现代码如下： + +//定义死信交换器和队列，并且进行绑定 + +@Bean + +public Declarables declarablesForDead() { + + Queue queue = new Queue(Consts.DEAD_QUEUE); + + DirectExchange directExchange = new DirectExchange(Consts.DEAD_EXCHANGE); + + return new Declarables(queue, directExchange, + + BindingBuilder.bind(queue).to(directExchange).with(Consts.DEAD_ROUTING_KEY)); + +} + +//定义重试操作拦截器 + +@Bean + +public RetryOperationsInterceptor interceptor() { + + return RetryInterceptorBuilder.stateless() + + .maxAttempts(5) //最多尝试（不是重试）5次 + + .backOffOptions(1000, 2.0, 10000) //指数退避重试 + + .recoverer(new RepublishMessageRecoverer(rabbitTemplate, Consts.DEAD_EXCHANGE, Consts.DEAD_ROUTING_KEY)) //重新投递重试达到上限的消息 + + .build(); + +} + +//通过定义SimpleRabbitListenerContainerFactory，设置其adviceChain属性为之前定义的RetryOperationsInterceptor来启用重试拦截器 + +@Bean + +public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) { + + SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); + + factory.setConnectionFactory(connectionFactory); + + factory.setAdviceChain(interceptor()); + + return factory; + +} + +//死信队列处理程序 + +@RabbitListener(queues = Consts.DEAD_QUEUE) + +public void deadHandler(String data) { + + log.error("got dead message {}", data); + +} + + +执行程序，发送两条消息，日志如下： + +[11:22:02.193] [http-nio-45688-exec-1] [INFO ] [o.g.t.c.a.d.DeadLetterController:24 ] - send message msg1 + +[11:22:02.219] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg1 + +[11:22:02.614] [http-nio-45688-exec-2] [INFO ] [o.g.t.c.a.d.DeadLetterController:24 ] - send message msg2 + +[11:22:03.220] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg1 + +[11:22:05.221] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg1 + +[11:22:09.223] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg1 + +[11:22:17.224] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg1 + +[11:22:17.226] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [WARN ] [o.s.a.r.retry.RepublishMessageRecoverer:172 ] - Republishing failed message to exchange 'deadtest' with routing key deadtest + +[11:22:17.227] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg2 + +[11:22:17.229] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#1-1] [ERROR] [o.g.t.c.a.deadletter.MQListener:20 ] - got dead message msg1 + +[11:22:18.232] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg2 + +[11:22:20.237] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg2 + +[11:22:24.241] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg2 + +[11:22:32.245] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [INFO ] [o.g.t.c.a.deadletter.MQListener:13 ] - got message msg2 + +[11:22:32.246] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#0-1] [WARN ] [o.s.a.r.retry.RepublishMessageRecoverer:172 ] - Republishing failed message to exchange 'deadtest' with routing key deadtest + +[11:22:32.250] [org.springframework.amqp.rabbit.RabbitListenerEndpointContainer#1-1] [ERROR] [o.g.t.c.a.deadletter.MQListener:20 ] - got dead message msg2 + + + +可以看到： + +msg1 的 4 次重试间隔分别是 1 秒、2 秒、4 秒、8 秒，再加上首次的失败，所以最大尝试次数是 5。 + +4 次重试后，RepublishMessageRecoverer 把消息发往了死信交换器。 + +死信处理程序输出了 got dead message 日志。 + +这里需要尤其注意的一点是，虽然我们几乎同时发送了两条消息，但是 msg2 是在 msg1 的四次重试全部结束后才开始处理。原因是，默认情况下 SimpleMessageListenerContainer 只有一个消费线程。可以通过增加消费线程来避免性能问题，如下我们直接设置 concurrentConsumers 参数为 10，来增加到 10 个工作线程： + +@Bean + +public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) { + + SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); + + factory.setConnectionFactory(connectionFactory); + + factory.setAdviceChain(interceptor()); + + factory.setConcurrentConsumers(10); + + return factory; + +} + + + +当然，我们也可以设置 maxConcurrentConsumers 参数，来让 SimpleMessageListenerContainer 自己动态地调整消费者线程数。不过，我们需要特别注意它的动态开启新线程的策略。你可以通过官方文档，来了解这个策略。 + +重点回顾 + +在使用异步处理这种架构模式的时候，我们一般都会使用 MQ 中间件配合实现异步流程，需要重点考虑四个方面的问题。 + +第一，要考虑异步流程丢消息或处理中断的情况，异步流程需要有备线进行补偿。比如，我们今天介绍的全量补偿方式，即便异步流程彻底失效，通过补偿也能让业务继续进行。 + +第二，异步处理的时候需要考虑消息重复的可能性，处理逻辑需要实现幂等，防止重复处理。 + +第三，微服务场景下不同服务多个实例监听消息的情况，一般不同服务需要同时收到相同的消息，而相同服务的多个实例只需要轮询接收消息。我们需要确认 MQ 的消息路由配置是否满足需求，以避免消息重复或漏发问题。 + +第四，要注意始终无法处理的死信消息，可能会引发堵塞 MQ 的问题。一般在遇到消息处理失败的时候，我们可以设置一定的重试策略。如果重试还是不行，那可以把这个消息扔到专有的死信队列特别处理，不要让死信影响到正常消息的处理。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +在用户注册后发送消息到 MQ，然后会员服务监听消息进行异步处理的场景下，有些时候我们会发现，虽然用户服务先保存数据再发送 MQ，但会员服务收到消息后去查询数据库，却发现数据库中还没有新用户的信息。你觉得，这可能是什么问题呢，又该如何解决呢？ + +除了使用 Spring AMQP 实现死信消息的重投递外，RabbitMQ 2.8.0 后支持的死信交换器 DLX 也可以实现类似功能。你能尝试用 DLX 实现吗，并比较下这两种处理机制？ + +关于使用 MQ 进行异步处理流程，你还遇到过其他问题吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/26数据存储：NoSQL与RDBMS如何取长补短、相辅相成？.md b/专栏/Java业务开发常见错误100例/26数据存储：NoSQL与RDBMS如何取长补短、相辅相成？.md new file mode 100644 index 0000000..d07b2b4 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/26数据存储：NoSQL与RDBMS如何取长补短、相辅相成？.md @@ -0,0 +1,897 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 26 数据存储：NoSQL与RDBMS如何取长补短、相辅相成？ + 今天，我来和你聊聊数据存储的常见错误。 + +近几年，各种非关系型数据库，也就是 NoSQL 发展迅猛，在项目中也非常常见。其中不乏一些使用上的极端情况，比如直接把关系型数据库（RDBMS）全部替换为 NoSQL，或是在不合适的场景下错误地使用 NoSQL。 + +其实，每种 NoSQL 的特点不同，都有其要着重解决的某一方面的问题。因此，我们在使用 NoSQL 的时候，要尽量让它去处理擅长的场景，否则不但发挥不出它的功能和优势，还可能会导致性能问题。 + +NoSQL 一般可以分为缓存数据库、时间序列数据库、全文搜索数据库、文档数据库、图数据库等。今天，我会以缓存数据库 Redis、时间序列数据库 InfluxDB、全文搜索数据库 ElasticSearch 为例，通过一些测试案例，和你聊聊这些常见 NoSQL 的特点，以及它们擅长和不擅长的地方。最后，我也还会和你说说 NoSQL 如何与 RDBMS 相辅相成，来构成一套可以应对高并发的复合数据库体系。 + +取长补短之 Redis vs MySQL + +Redis 是一款设计简洁的缓存数据库，数据都保存在内存中，所以读写单一 Key 的性能非常高。 + +我们来做一个简单测试，分别填充 10 万条数据到 Redis 和 MySQL 中。MySQL 中的 name 字段做了索引，相当于 Redis 的 Key，data 字段为 100 字节的数据，相当于 Redis 的 Value： + +@SpringBootApplication + +@Slf4j + +public class CommonMistakesApplication { + + //模拟10万条数据存到Redis和MySQL + + public static final int ROWS = 100000; + + public static final String PAYLOAD = IntStream.rangeClosed(1, 100).mapToObj(__ -> "a").collect(Collectors.joining("")); + + @Autowired + + private StringRedisTemplate stringRedisTemplate; + + @Autowired + + private JdbcTemplate jdbcTemplate; + + @Autowired + + private StandardEnvironment standardEnvironment; + + + + public static void main(String[] args) { + + SpringApplication.run(CommonMistakesApplication.class, args); + + } + + @PostConstruct + + public void init() { + + //使用-Dspring.profiles.active=init启动程序进行初始化 + + if (Arrays.stream(standardEnvironment.getActiveProfiles()).anyMatch(s -> s.equalsIgnoreCase("init"))) { + + initRedis(); + + initMySQL(); + + } + + } + + //填充数据到MySQL + + private void initMySQL() { + + //删除表 + + jdbcTemplate.execute("DROP TABLE IF EXISTS `r`;"); + + //新建表，name字段做了索引 + + jdbcTemplate.execute("CREATE TABLE `r` (\n" + + + " `id` bigint(20) NOT NULL AUTO_INCREMENT,\n" + + + " `data` varchar(2000) NOT NULL,\n" + + + " `name` varchar(20) NOT NULL,\n" + + + " PRIMARY KEY (`id`),\n" + + + " KEY `name` (`name`) USING BTREE\n" + + + ") ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;"); + + //批量插入数据 + + String sql = "INSERT INTO `r` (`data`,`name`) VALUES (?,?)"; + + jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() { + + @Override + + public void setValues(PreparedStatement preparedStatement, int i) throws SQLException { + + preparedStatement.setString(1, PAYLOAD); + + preparedStatement.setString(2, "item" + i); + + } + + @Override + + public int getBatchSize() { + + return ROWS; + + } + + }); + + log.info("init mysql finished with count {}", jdbcTemplate.queryForObject("SELECT COUNT(*) FROM `r`", Long.class)); + + } + + //填充数据到Redis + + private void initRedis() { + + IntStream.rangeClosed(1, ROWS).forEach(i -> stringRedisTemplate.opsForValue().set("item" + i, PAYLOAD)); + + log.info("init redis finished with count {}", stringRedisTemplate.keys("item*")); + + } + +} + + + +启动程序后，输出了如下日志，数据全部填充完毕： + +[14:22:47.195] [main] [INFO ] [o.g.t.c.n.r.CommonMistakesApplication:80 ] - init redis finished with count 100000 + +[14:22:50.030] [main] [INFO ] [o.g.t.c.n.r.CommonMistakesApplication:74 ] - init mysql finished with count 100000 + + + +然后，比较一下从 MySQL 和 Redis 随机读取单条数据的性能。“公平”起见，像 Redis 那样，我们使用 MySQL 时也根据 Key 来查 Value，也就是根据 name 字段来查 data 字段，并且我们给 name 字段做了索引： + +@Autowired + +private JdbcTemplate jdbcTemplate; + +@Autowired + +private StringRedisTemplate stringRedisTemplate; + +@GetMapping("redis") + +public void redis() { + + //使用随机的Key来查询Value，结果应该等于PAYLOAD + + Assert.assertTrue(stringRedisTemplate.opsForValue().get("item" + (ThreadLocalRandom.current().nextInt(CommonMistakesApplication.ROWS) + 1)).equals(CommonMistakesApplication.PAYLOAD)); + +} + +@GetMapping("mysql") + +public void mysql() { + + //根据随机name来查data，name字段有索引，结果应该等于PAYLOAD + + Assert.assertTrue(jdbcTemplate.queryForObject("SELECT data FROM `r` WHERE name=?", new Object[]{("item" + (ThreadLocalRandom.current().nextInt(CommonMistakesApplication.ROWS) + 1))}, String.class) + + .equals(CommonMistakesApplication.PAYLOAD)); + +} + + + +在我的电脑上，使用 wrk 加 10 个线程 50 个并发连接做压测。可以看到，MySQL 90% 的请求需要 61ms，QPS 为 1460；而 Redis 90% 的请求在 5ms 左右，QPS 达到了 14008，几乎是 MySQL 的十倍： + + + +但 Redis 薄弱的地方是，不擅长做 Key 的搜索。对 MySQL，我们可以使用 LIKE 操作前匹配走 B+ 树索引实现快速搜索；但对 Redis，我们使用 Keys 命令对 Key 的搜索，其实相当于在 MySQL 里做全表扫描。 + +我写一段代码来对比一下性能： + +@GetMapping("redis2") + +public void redis2() { + + Assert.assertTrue(stringRedisTemplate.keys("item71*").size() == 1111); + +} + +@GetMapping("mysql2") + +public void mysql2() { + + Assert.assertTrue(jdbcTemplate.queryForList("SELECT name FROM `r` WHERE name LIKE 'item71%'", String.class).size() == 1111); + +} + + + +可以看到，在 QPS 方面，MySQL 的 QPS 达到了 Redis 的 157 倍；在延迟方面，MySQL 的延迟只有 Redis 的十分之一。 + + + +Redis 慢的原因有两个： + +Redis 的 Keys 命令是 O(n) 时间复杂度。如果数据库中 Key 的数量很多，就会非常慢。 + +Redis 是单线程的，对于慢的命令如果有并发，串行执行就会非常耗时。 + +一般而言，我们使用 Redis 都是针对某一个 Key 来使用，而不能在业务代码中使用 Keys 命令从 Redis 中“搜索数据”，因为这不是 Redis 的擅长。对于 Key 的搜索，我们可以先通过关系型数据库进行，然后再从 Redis 存取数据（如果实在需要搜索 Key 可以使用 SCAN 命令）。在生产环境中，我们一般也会配置 Redis 禁用类似 Keys 这种比较危险的命令，你可以参考这里。 + +总结一下，正如“缓存设计”一讲中提到的，对于业务开发来说，大多数业务场景下 Redis 是作为关系型数据库的辅助用于缓存的，我们一般不会把它当作数据库独立使用。 + +此外值得一提的是，Redis 提供了丰富的数据结构（Set、SortedSet、Hash、List），并围绕这些数据结构提供了丰富的 API。如果我们好好利用这个特点的话，可以直接在 Redis 中完成一部分服务端计算，避免“读取缓存 -> 计算数据 -> 保存缓存”三部曲中的读取和保存缓存的开销，进一步提高性能。 + +取长补短之 InfluxDB vs MySQL + +InfluxDB 是一款优秀的时序数据库。在“生产就绪”这一讲中，我们就是使用 InfluxDB 来做的 Metrics 打点。时序数据库的优势，在于处理指标数据的聚合，并且读写效率非常高。 + +同样的，我们使用一些测试来对比下 InfluxDB 和 MySQL 的性能。 + +在如下代码中，我们分别填充了 1000 万条数据到 MySQL 和 InfluxDB 中。其中，每条数据只有 ID、时间戳、10000 以内的随机值这 3 列信息，对于 MySQL 我们把时间戳列做了索引： + +@SpringBootApplication + +@Slf4j + +public class CommonMistakesApplication { + + public static void main(String[] args) { + + SpringApplication.run(CommonMistakesApplication.class, args); + + } + + //测试数据量 + + public static final int ROWS = 10000000; + + @Autowired + + private JdbcTemplate jdbcTemplate; + + @Autowired + + private StandardEnvironment standardEnvironment; + + @PostConstruct + + public void init() { + + //使用-Dspring.profiles.active=init启动程序进行初始化 + + if (Arrays.stream(standardEnvironment.getActiveProfiles()).anyMatch(s -> s.equalsIgnoreCase("init"))) { + + initInfluxDB(); + + initMySQL(); + + } + + } + + //初始化MySQL + + private void initMySQL() { + + long begin = System.currentTimeMillis(); + + jdbcTemplate.execute("DROP TABLE IF EXISTS `m`;"); + + //只有ID、值和时间戳三列 + + jdbcTemplate.execute("CREATE TABLE `m` (\n" + + + " `id` bigint(20) NOT NULL AUTO_INCREMENT,\n" + + + " `value` bigint NOT NULL,\n" + + + " `time` timestamp NOT NULL,\n" + + + " PRIMARY KEY (`id`),\n" + + + " KEY `time` (`time`) USING BTREE\n" + + + ") ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;"); + + String sql = "INSERT INTO `m` (`value`,`time`) VALUES (?,?)"; + + //批量插入数据 + + jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() { + + @Override + + public void setValues(PreparedStatement preparedStatement, int i) throws SQLException { + + preparedStatement.setLong(1, ThreadLocalRandom.current().nextInt(10000)); + + preparedStatement.setTimestamp(2, Timestamp.valueOf(LocalDateTime.now().minusSeconds(5 * i))); + + } + + @Override + + public int getBatchSize() { + + return ROWS; + + } + + }); + + log.info("init mysql finished with count {} took {}ms", jdbcTemplate.queryForObject("SELECT COUNT(*) FROM `m`", Long.class), System.currentTimeMillis()-begin); + + } + + //初始化InfluxDB + + private void initInfluxDB() { + + long begin = System.currentTimeMillis(); + + OkHttpClient.Builder okHttpClientBuilder = new OkHttpClient().newBuilder() + + .connectTimeout(1, TimeUnit.SECONDS) + + .readTimeout(10, TimeUnit.SECONDS) + + .writeTimeout(10, TimeUnit.SECONDS); + + try (InfluxDB influxDB = InfluxDBFactory.connect("http://127.0.0.1:8086", "root", "root", okHttpClientBuilder)) { + + String db = "performance"; + + influxDB.query(new Query("DROP DATABASE " + db)); + + influxDB.query(new Query("CREATE DATABASE " + db)); + + //设置数据库 + + influxDB.setDatabase(db); + + //批量插入，10000条数据刷一次，或1秒刷一次 + + influxDB.enableBatch(BatchOptions.DEFAULTS.actions(10000).flushDuration(1000)); + + IntStream.rangeClosed(1, ROWS).mapToObj(i -> Point + + .measurement("m") + + .addField("value", ThreadLocalRandom.current().nextInt(10000)) + + .time(LocalDateTime.now().minusSeconds(5 * i).toInstant(ZoneOffset.UTC).toEpochMilli(), TimeUnit.MILLISECONDS).build()) + + .forEach(influxDB::write); + + influxDB.flush(); + + log.info("init influxdb finished with count {} took {}ms", influxDB.query(new Query("SELECT COUNT(*) FROM m")).getResults().get(0).getSeries().get(0).getValues().get(0).get(1), System.currentTimeMillis()-begin); + + } + + } + +} + + + +启动后，程序输出了如下日志： + +[16:08:25.062] [main] [INFO ] [o.g.t.c.n.i.CommonMistakesApplication:104 ] - init influxdb finished with count 1.0E7 took 54280ms + +[16:11:50.462] [main] [INFO ] [o.g.t.c.n.i.CommonMistakesApplication:80 ] - init mysql finished with count 10000000 took 205394ms + + + +InfluxDB 批量插入 1000 万条数据仅用了 54 秒，相当于每秒插入 18 万条数据，速度相当快；MySQL 的批量插入，速度也挺快达到了每秒 4.8 万。 + +接下来，我们测试一下。 + +对这 1000 万数据进行一个统计，查询最近 60 天的数据，按照 1 小时的时间粒度聚合，统计 value 列的最大值、最小值和平均值，并将统计结果绘制成曲线图： + +@Autowired + +private JdbcTemplate jdbcTemplate; + +@GetMapping("mysql") + +public void mysql() { + + long begin = System.currentTimeMillis(); + + //使用SQL从MySQL查询，按照小时分组 + + Object result = jdbcTemplate.queryForList("SELECT date_format(time,'%Y%m%d%H'),max(value),min(value),avg(value) FROM m WHERE time>now()- INTERVAL 60 DAY GROUP BY date_format(time,'%Y%m%d%H')"); + + log.info("took {} ms result {}", System.currentTimeMillis() - begin, result); + +} + + + +@GetMapping("influxdb") + +public void influxdb() { + + long begin = System.currentTimeMillis(); + + try (InfluxDB influxDB = InfluxDBFactory.connect("http://127.0.0.1:8086", "root", "root")) { + + //切换数据库 + + influxDB.setDatabase("performance"); + + //InfluxDB的查询语法InfluxQL类似SQL + + Object result = influxDB.query(new Query("SELECT MEAN(value),MIN(value),MAX(value) FROM m WHERE time > now() - 60d GROUP BY TIME(1h)")); + + log.info("took {} ms result {}", System.currentTimeMillis() - begin, result); + + } + +} + + + +因为数据量非常大，单次查询就已经很慢了，所以这次我们不进行压测。分别调用两个接口，可以看到 MySQL 查询一次耗时 29 秒左右，而 InfluxDB 耗时 980ms： + +[16:19:26.562] [http-nio-45678-exec-1] [INFO ] [o.g.t.c.n.i.PerformanceController:31 ] - took 28919 ms result [{date_format(time,'%Y%m%d%H')=2019121308, max(value)=9993, min(value)=4, avg(value)=5129.5639}, {date_format(time,'%Y%m%d%H')=2019121309, max(value)=9990, min(value)=12, avg(value)=4856.0556}, {date_format(time,'%Y%m%d%H')=2019121310, max(value)=9998, min(value)=8, avg(value)=4948.9347}, {date_format(time,'%Y%m%d%H')... + +[16:20:08.170] [http-nio-45678-exec-6] [INFO ] [o.g.t.c.n.i.PerformanceController:40 ] - took 981 ms result QueryResult [results=[Result [series=[Series [name=m, tags=null, columns=[time, mean, min, max], values=[[2019-12-13T08:00:00Z, 5249.2468619246865, 21.0, 9992.0],... + + + +在按照时间区间聚合的案例上，我们看到了 InfluxDB 的性能优势。但，我们肯定不能把 InfluxDB 当作普通数据库，原因是： + +InfluxDB 不支持数据更新操作，毕竟时间数据只能随着时间产生新数据，肯定无法对过去的数据做修改； + +从数据结构上说，时间序列数据数据没有单一的主键标识，必须包含时间戳，数据只能和时间戳进行关联，不适合普通业务数据。 + +此外需要注意，即便只是使用 InfluxDB 保存和时间相关的指标数据，我们也要注意不能滥用 tag。 + +InfluxDB 提供的 tag 功能，可以为每一个指标设置多个标签，并且 tag 有索引，可以对 tag 进行条件搜索或分组。但是，tag 只能保存有限的、可枚举的标签，不能保存 URL 等信息，否则可能会出现high series cardinality 问题，导致占用大量内存，甚至是 OOM。你可以点击这里，查看 series 和内存占用的关系。对于 InfluxDB，我们无法把 URL 这种原始数据保存到数据库中，只能把数据进行归类，形成有限的 tag 进行保存。 + +总结一下，对于 MySQL 而言，针对大量的数据使用全表扫描的方式来聚合统计指标数据，性能非常差，一般只能作为临时方案来使用。此时，引入 InfluxDB 之类的时间序列数据库，就很有必要了。时间序列数据库可以作为特定场景（比如监控、统计）的主存储，也可以和关系型数据库搭配使用，作为一个辅助数据源，保存业务系统的指标数据。 + +取长补短之 Elasticsearch vs MySQL + +Elasticsearch（以下简称 ES），是目前非常流行的分布式搜索和分析数据库，独特的倒排索引结构尤其适合进行全文搜索。 + +简单来讲，倒排索引可以认为是一个 Map，其 Key 是分词之后的关键字，Value 是文档 ID/ 片段 ID 的列表。我们只要输入需要搜索的单词，就可以直接在这个 Map 中得到所有包含这个单词的文档 ID/ 片段 ID 列表，然后再根据其中的文档 ID/ 片段 ID 查询出实际的文档内容。 + +我们来测试一下，对比下使用 ES 进行关键字全文搜索、在 MySQL 中使用 LIKE 进行搜索的效率差距。 + +首先，定义一个实体 News，包含新闻分类、标题、内容等字段。这个实体同时会用作 Spring Data JPA 和 Spring Data Elasticsearch 的实体： + +@Entity + +@Document(indexName = "news", replicas = 0) //@Document注解定义了这是一个ES的索引，索引名称news，数据不需要冗余 + +@Table(name = "news", indexes = {@Index(columnList = "cateid")}) //@Table注解定义了这是一个MySQL表，表名news，对cateid列做索引 + +@Data + +@AllArgsConstructor + +@NoArgsConstructor + +@DynamicUpdate + +public class News { + + @Id + + private long id; + + @Field(type = FieldType.Keyword) + + private String category;//新闻分类名称 + + private int cateid;//新闻分类ID + + @Column(columnDefinition = "varchar(500)")//@Column注解定义了在MySQL中字段，比如这里定义title列的类型是varchar(500) + + @Field(type = FieldType.Text, analyzer = "ik_max_word", searchAnalyzer = "ik_smart")//@Field注解定义了ES字段的格式，使用ik分词器进行分词 + + private String title;//新闻标题 + + @Column(columnDefinition = "text") + + @Field(type = FieldType.Text, analyzer = "ik_max_word", searchAnalyzer = "ik_smart") + + private String content;//新闻内容 + +} + + + +接下来，我们实现主程序。在启动时，我们会从一个 csv 文件中加载 4000 条新闻数据，然后复制 100 份，拼成 40 万条数据，分别写入 MySQL 和 ES： + +@SpringBootApplication + +@Slf4j + +@EnableElasticsearchRepositories(includeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, value = NewsESRepository.class)) //明确设置哪个是ES的Repository + +@EnableJpaRepositories(excludeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, value = NewsESRepository.class)) //其他的是MySQL的Repository + +public class CommonMistakesApplication { + + public static void main(String[] args) { + + Utils.loadPropertySource(CommonMistakesApplication.class, "es.properties"); + + SpringApplication.run(CommonMistakesApplication.class, args); + + } + + @Autowired + + private StandardEnvironment standardEnvironment; + + @Autowired + + private NewsESRepository newsESRepository; + + @Autowired + + private NewsMySQLRepository newsMySQLRepository; + + @PostConstruct + + public void init() { + + //使用-Dspring.profiles.active=init启动程序进行初始化 + + if (Arrays.stream(standardEnvironment.getActiveProfiles()).anyMatch(s -> s.equalsIgnoreCase("init"))) { + + //csv中的原始数据只有4000条 + + List news = loadData(); + + AtomicLong atomicLong = new AtomicLong(); + + news.forEach(item -> item.setTitle("%%" + item.getTitle())); + + //我们模拟100倍的数据量，也就是40万条 + + IntStream.rangeClosed(1, 100).forEach(repeat -> { + + news.forEach(item -> { + + //重新设置主键ID + + item.setId(atomicLong.incrementAndGet()); + + //每次复制数据稍微改一下title字段，在前面加上一个数字，代表这是第几次复制 + + item.setTitle(item.getTitle().replaceFirst("%%", String.valueOf(repeat))); + + }); + + initMySQL(news, repeat == 1); + + log.info("init MySQL finished for {}", repeat); + + initES(news, repeat == 1); + + log.info("init ES finished for {}", repeat); + + }); + + } + + } + + //从news.csv中解析得到原始数据 + + private List loadData() { + + //使用jackson-dataformat-csv实现csv到POJO的转换 + + CsvMapper csvMapper = new CsvMapper(); + + CsvSchema schema = CsvSchema.emptySchema().withHeader(); + + ObjectReader objectReader = csvMapper.readerFor(News.class).with(schema); + + ClassLoader classLoader = getClass().getClassLoader(); + + File file = new File(classLoader.getResource("news.csv").getFile()); + + try (Reader reader = new FileReader(file)) { + + return objectReader.readValues(reader).readAll(); + + } catch (Exception e) { + + e.printStackTrace(); + + } + + return null; + + } + + //把数据保存到ES中 + + private void initES(List news, boolean clear) { + + if (clear) { + + //首次调用的时候先删除历史数据 + + newsESRepository.deleteAll(); + + } + + newsESRepository.saveAll(news); + + } + + //把数据保存到MySQL中 + + private void initMySQL(List news, boolean clear) { + + if (clear) { + + //首次调用的时候先删除历史数据 + + newsMySQLRepository.deleteAll(); + + } + + newsMySQLRepository.saveAll(news); + + } + +} + + + +由于我们使用了 Spring Data，直接定义两个 Repository，然后直接定义查询方法，无需实现任何逻辑即可实现查询，Spring Data 会根据方法名生成相应的 SQL 语句和 ES 查询 DSL，其中 ES 的翻译逻辑详见这里。 + +在这里，我们定义一个 countByCateidAndContentContainingAndContentContaining 方法，代表查询条件是：搜索分类等于 cateid 参数，且内容同时包含关键字 keyword1 和 keyword2，计算符合条件的新闻总数量： + +@Repository + +public interface NewsMySQLRepository extends JpaRepository { + + //JPA：搜索分类等于cateid参数，且内容同时包含关键字keyword1和keyword2，计算符合条件的新闻总数量 + + long countByCateidAndContentContainingAndContentContaining(int cateid, String keyword1, String keyword2); + +} + +@Repository + +public interface NewsESRepository extends ElasticsearchRepository { + + //ES：搜索分类等于cateid参数，且内容同时包含关键字keyword1和keyword2，计算符合条件的新闻总数量 + + long countByCateidAndContentContainingAndContentContaining(int cateid, String keyword1, String keyword2); + +} + + + +对于 ES 和 MySQL，我们使用相同的条件进行搜索，搜素分类是 1，关键字是社会和苹果，然后输出搜索结果和耗时： + +//测试MySQL搜索，最后输出耗时和结果 + +@GetMapping("mysql") + +public void mysql(@RequestParam(value = "cateid", defaultValue = "1") int cateid, + + @RequestParam(value = "keyword1", defaultValue = "社会") String keyword1, + + @RequestParam(value = "keyword2", defaultValue = "苹果") String keyword2) { + + long begin = System.currentTimeMillis(); + + Object result = newsMySQLRepository.countByCateidAndContentContainingAndContentContaining(cateid, keyword1, keyword2); + + log.info("took {} ms result {}", System.currentTimeMillis() - begin, result); + +} + +//测试ES搜索，最后输出耗时和结果 + +@GetMapping("es") + +public void es(@RequestParam(value = "cateid", defaultValue = "1") int cateid, + + @RequestParam(value = "keyword1", defaultValue = "社会") String keyword1, + + @RequestParam(value = "keyword2", defaultValue = "苹果") String keyword2) { + + long begin = System.currentTimeMillis(); + + Object result = newsESRepository.countByCateidAndContentContainingAndContentContaining(cateid, keyword1, keyword2); + + log.info("took {} ms result {}", System.currentTimeMillis() - begin, result); + +} + + + +分别调用接口可以看到，ES 耗时仅仅 48ms，MySQL 耗时 6 秒多是 ES 的 100 倍。很遗憾，虽然新闻分类 ID 已经建了索引，但是这个索引只能起到加速过滤分类 ID 这一单一条件的作用，对于文本内容的全文搜索，B+ 树索引无能为力。 + +[22:04:00.951] [http-nio-45678-exec-6] [INFO ] [o.g.t.c.n.esvsmyql.PerformanceController:48 ] - took 48 ms result 2100 + +Hibernate: select count(news0_.id) as col_0_0_ from news news0_ where news0_.cateid=? and (news0_.content like ? escape ?) and (news0_.content like ? escape ?) + +[22:04:11.946] [http-nio-45678-exec-7] [INFO ] [o.g.t.c.n.esvsmyql.PerformanceController:39 ] - took 6637 ms result 2100 + + + +但 ES 这种以索引为核心的数据库，也不是万能的，频繁更新就是一个大问题。 + +MySQL 可以做到仅更新某行数据的某个字段，但 ES 里每次数据字段更新都相当于整个文档索引重建。即便 ES 提供了文档部分更新的功能，但本质上只是节省了提交文档的网络流量，以及减少了更新冲突，其内部实现还是文档删除后重新构建索引。因此，如果要在 ES 中保存一个类似计数器的值，要实现不断更新，其执行效率会非常低。 + +我们来验证下，分别使用 JdbcTemplate+SQL 语句、ElasticsearchTemplate+ 自定义 UpdateQuery，实现部分更新 MySQL 表和 ES 索引的一个字段，每个方法都是循环更新 1000 次： + +@GetMapping("mysql2") + +public void mysql2(@RequestParam(value = "id", defaultValue = "400000") long id) { + + long begin = System.currentTimeMillis(); + + //对于MySQL，使用JdbcTemplate+SQL语句，实现直接更新某个category字段，更新1000次 + + IntStream.rangeClosed(1, 1000).forEach(i -> { + + jdbcTemplate.update("UPDATE `news` SET category=? WHERE id=?", new Object[]{"test" + i, id}); + + }); + + log.info("mysql took {} ms result {}", System.currentTimeMillis() - begin, newsMySQLRepository.findById(id)); + +} + +@GetMapping("es2") + +public void es(@RequestParam(value = "id", defaultValue = "400000") long id) { + + long begin = System.currentTimeMillis(); + + IntStream.rangeClosed(1, 1000).forEach(i -> { + + //对于ES，通过ElasticsearchTemplate+自定义UpdateQuery，实现文档的部分更新 + + UpdateQuery updateQuery = null; + + try { + + updateQuery = new UpdateQueryBuilder() + + .withIndexName("news") + + .withId(String.valueOf(id)) + + .withType("_doc") + + .withUpdateRequest(new UpdateRequest().doc( + + jsonBuilder() + + .startObject() + + .field("category", "test" + i) + + .endObject())) + + .build(); + + } catch (IOException e) { + + e.printStackTrace(); + + } + + elasticsearchTemplate.update(updateQuery); + + }); + + log.info("es took {} ms result {}", System.currentTimeMillis() - begin, newsESRepository.findById(id).get()); + +} + + + +可以看到，MySQL 耗时仅仅 1.5 秒，而 ES 耗时 6.8 秒： + + + +ES 是一个分布式的全文搜索数据库，所以与 MySQL 相比的优势在于文本搜索，而且因为其分布式的特性，可以使用一个大 ES 集群处理大规模数据的内容搜索。但，由于 ES 的索引是文档维度的，所以不适用于频繁更新的 OLTP 业务。 + +一般而言，我们会把 ES 和 MySQL 结合使用，MySQL 直接承担业务系统的增删改操作，而 ES 作为辅助数据库，直接扁平化保存一份业务数据，用于复杂查询、全文搜索和统计。接下来，我也会继续和你分析这一点。 + +结合 NoSQL 和 MySQL 应对高并发的复合数据库架构 + +现在，我们通过一些案例看到了 Redis、InfluxDB、ES 这些 NoSQL 数据库，都有擅长和不擅长的场景。那么，有没有全能的数据库呢？ + +我认为没有。每一个存储系统都有其独特的数据结构，数据结构的设计就决定了其擅长和不擅长的场景。 + +比如，MySQL InnoDB 引擎的 B+ 树对排序和范围查询友好，频繁数据更新的代价不是太大，因此适合 OLTP（On-Line Transaction Processing）。 + +又比如，ES 的 Lucene 采用了 FST（Finite State Transducer）索引 + 倒排索引，空间效率高，适合对变动不频繁的数据做索引，实现全文搜索。存储系统本身不可能对一份数据使用多种数据结构保存，因此不可能适用于所有场景。 + +虽然在大多数业务场景下，MySQL 的性能都不算太差，但对于数据量大、访问量大、业务复杂的互联网应用来说，MySQL 因为实现了 ACID（原子性、一致性、隔离性、持久性）会比较重，而且横向扩展能力较差、功能单一，无法扛下所有数据量和流量，无法应对所有功能需求。因此，我们需要通过架构手段，来组合使用多种存储系统，取长补短，实现 1+1>2 的效果。 + +我来举个例子。我们设计了一个包含多个数据库系统的、能应对各种高并发场景的一套数据服务的系统架构，其中包含了同步写服务、异步写服务和查询服务三部分，分别实现主数据库写入、辅助数据库写入和查询路由。 + +我们按照服务来依次分析下这个架构。 + + + +首先要明确的是，重要的业务主数据只能保存在 MySQL 这样的关系型数据库中，原因有三点： + +RDBMS 经过了几十年的验证，已经非常成熟； + +RDBMS 的用户数量众多，Bug 修复快、版本稳定、可靠性很高； + +RDBMS 强调 ACID，能确保数据完整。 + +有两种类型的查询任务可以交给 MySQL 来做，性能会比较好，这也是 MySQL 擅长的地方： + +按照主键 ID 的查询。直接查询聚簇索引，其性能会很高。但是单表数据量超过亿级后，性能也会衰退，而且单个数据库无法承受超大的查询并发，因此我们可以把数据表进行 Sharding 操作，均匀拆分到多个数据库实例中保存。我们把这套数据库集群称作 Sharding 集群。 + +按照各种条件进行范围查询，查出主键 ID。对二级索引进行查询得到主键，只需要查询一棵 B+ 树，效率同样很高。但索引的值不宜过大，比如对 varchar(1000) 进行索引不太合适，而索引外键（一般是 int 或 bigint 类型）性能就会比较好。因此，我们可以在 MySQL 中建立一张“索引表”，除了保存主键外，主要是保存各种关联表的外键，以及尽可能少的 varchar 类型的字段。这张索引表的大部分列都可以建上二级索引，用于进行简单搜索，搜索的结果是主键的列表，而不是完整的数据。由于索引表字段轻量并且数量不多（一般控制在 10 个以内），所以即便索引表没有进行 Sharding 拆分，问题也不会很大。 + +如图上蓝色线所示，写入两种 MySQL 数据表和发送 MQ 消息的这三步，我们用一个同步写服务完成了。我在“异步处理”中提到，所有异步流程都需要补偿，这里的异步流程同样需要。只不过为了简洁，我在这里省略了补偿流程。 + +然后，如图中绿色线所示，有一个异步写服务，监听 MQ 的消息，继续完成辅助数据的更新操作。这里我们选用了 ES 和 InfluxDB 这两种辅助数据库，因此整个异步写数据操作有三步： + +MQ 消息不一定包含完整的数据，甚至可能只包含一个最新数据的主键 ID，我们需要根据 ID 从查询服务查询到完整的数据。 + +写入 InfluxDB 的数据一般可以按时间间隔进行简单聚合，定时写入 InfluxDB。因此，这里会进行简单的客户端聚合，然后写入 InfluxDB。 + +ES 不适合在各索引之间做连接（Join）操作，适合保存扁平化的数据。比如，我们可以把订单下的用户、商户、商品列表等信息，作为内嵌对象嵌入整个订单 JSON，然后把整个扁平化的 JSON 直接存入 ES。 + +对于数据写入操作，我们认为操作返回的时候同步数据一定是写入成功的，但是由于各种原因，异步数据写入无法确保立即成功，会有一定延迟，比如： + +异步消息丢失的情况，需要补偿处理； + +写入 ES 的索引操作本身就会比较慢； + +写入 InfluxDB 的数据需要客户端定时聚合。 + +因此，对于查询服务，如图中红色线所示，我们需要根据一定的上下文条件（比如查询一致性要求、时效性要求、搜索的条件、需要返回的数据字段、搜索时间区间等）来把请求路由到合适的数据库，并且做一些聚合处理： + +需要根据主键查询单条数据，可以从 MySQL Sharding 集群或 Redis 查询，如果对实时性要求不高也可以从 ES 查询。 + +按照多个条件搜索订单的场景，可以从 MySQL 索引表查询出主键列表，然后再根据主键从 MySQL Sharding 集群或 Redis 获取数据详情。 + +各种后台系统需要使用比较复杂的搜索条件，甚至全文搜索来查询订单数据，或是定时分析任务需要一次查询大量数据，这些场景对数据实时性要求都不高，可以到 ES 进行搜索。此外，MySQL 中的数据可以归档，我们可以在 ES 中保留更久的数据，而且查询历史数据一般并发不会很大，可以统一路由到 ES 查询。 + +监控系统或后台报表系统需要呈现业务监控图表或表格，可以把请求路由到 InfluxDB 查询。 + +重点回顾 + +今天，我通过三个案例分别对比了缓存数据库 Redis、时间序列数据库 InfluxDB、搜索数据库 ES 和 MySQL 的性能。我们看到： + +Redis 对单条数据的读取性能远远高于 MySQL，但不适合进行范围搜索。 + +InfluxDB 对于时间序列数据的聚合效率远远高于 MySQL，但因为没有主键，所以不是一个通用数据库。 + +ES 对关键字的全文搜索能力远远高于 MySQL，但是字段的更新效率较低，不适合保存频繁更新的数据。 + +最后，我们给出了一个混合使用 MySQL + Redis + InfluxDB + ES 的架构方案，充分发挥了各种数据库的特长，相互配合构成了一个可以应对各种复杂查询，以及高并发读写的存储架构。 + +主数据由两种 MySQL 数据表构成，其中索引表承担简单条件的搜索来得到主键，Sharding 表承担大并发的主键查询。主数据由同步写服务写入，写入后发出 MQ 消息。 + +辅助数据可以根据需求选用合适的 NoSQL，由单独一个或多个异步写服务监听 MQ 后异步写入。 + +由统一的查询服务，对接所有查询需求，根据不同的查询需求路由查询到合适的存储，确保每一个存储系统可以根据场景发挥所长，并分散各数据库系统的查询压力。 + +今天用到的代码，我都放在了 GitHub 上，你可以点击这个链接查看。 + +思考与讨论 + +我们提到，InfluxDB 不能包含太多 tag。你能写一段测试代码，来模拟这个问题，并观察下 InfluxDB 的内存使用情况吗？ + +文档数据库 MongoDB，也是一种常用的 NoSQL。你觉得 MongoDB 的优势和劣势是什么呢？它适合用在什么场景下呢？ + +关于数据存储，你还有其他心得吗？我是朱晔，欢迎在评论区与我留言分享你的想法，也欢迎你把今天的内容分享给你的朋友或同事，一起交流。 + + + + \ No newline at end of file diff --git a/专栏/Java业务开发常见错误100例/27数据源头：任何客户端的东西都不可信任.md b/专栏/Java业务开发常见错误100例/27数据源头：任何客户端的东西都不可信任.md new file mode 100644 index 0000000..c3801f9 --- /dev/null +++ b/专栏/Java业务开发常见错误100例/27数据源头：任何客户端的东西都不可信任.md @@ -0,0 +1,532 @@ + + + 因收到Google相关通知，网站将会择期关闭。相关通知内容 + + + 27 数据源头：任何客户端的东西都不可信任 + 从今天开始，我要和你讨论几个有关安全的话题。首先声明，我不是安全专家，但我发现有这么一个问题，那就是许多做业务开发的同学往往一点点安全意识都没有。如果有些公司没有安全部门或专家的话，安全问题就会非常严重。 + +如果只是用一些所谓的渗透服务浅层次地做一下扫描和渗透，而不在代码和逻辑层面做进一步分析的话，能够发现的安全问题非常有限。要做好安全，还是要靠一线程序员和产品经理点点滴滴的意识。 + +所以接下来的几篇文章，我会从业务开发的角度，和你说说我们应该最应该具备的安全意识。 + +对于 HTTP 请求，我们要在脑子里有一个根深蒂固的概念，那就是任何客户端传过来的数据都是不能直接信任的。客户端传给服务端的数据只是信息收集，数据需要经过有效性验证、权限验证等后才能使用，并且这些数据只能认为是用户操作的意图，不能直接代表数据当前的状态。 + +举一个简单的例子，我们打游戏的时候，客户端发给服务端的只是用户的操作，比如移动了多少位置，由服务端根据用户当前的状态来设置新的位置再返回给客户端。为了防止作弊，不可能由客户端直接告诉服务端用户当前的位置。 + +因此，客户端发给服务端的指令，代表的只是操作指令，并不能直接决定用户的状态，对于状态改变的计算在服务端。而网络不好时，我们往往会遇到走了 10 步又被服务端拉回来的现象，就是因为有指令丢失，客户端使用服务端计算的实际位置修正了客户端玩家的位置。 + +今天，我通过四个案例来和你说说，为什么“任何客户端的东西都不可信任”。 + +客户端的计算不可信 + +我们先看一个电商下单操作的案例。 + +在这个场景下，可能会暴露这么一个 /order 的 POST 接口给客户端，让客户端直接把组装后的订单信息 Order 传给服务端： + +@PostMapping("/order") + +public void wrong(@RequestBody Order order) { + + this.createOrder(order); + +} + + + +订单信息 Order 可能包括商品 ID、商品价格、数量、商品总价： + +@Data + +public class Order { + + private long itemId; //商品ID + + private BigDecimal itemPrice; //商品价格 + + private int quantity; //商品数量 + + private BigDecimal itemTotalPrice; //商品总价 + +} + + + +虽然用户下单时客户端肯定有商品的价格等信息，也会计算出订单的总价给用户确认，但是这些信息只能用于呈现和核对。即使客户端传给服务端的 POJO 中包含了这些信息，服务端也一定要重新从数据库来初始化商品的价格，重新计算最终的订单价格。如果不这么做的话，很可能会被黑客利用，商品总价被恶意修改为比较低的价格。 + +因此，我们真正直接使用的、可信赖的只是客户端传过来的商品 ID 和数量，服务端会根据这些信息重新计算最终的总价。如果服务端计算出来的商品价格和客户端传过来的价格不匹配的话，可以给客户端友好提示，让用户重新下单。修改后的代码如下： + +@PostMapping("/orderRight") + +public void right(@RequestBody Order order) { + + //根据ID重新查询商品 + + Item item = Db.getItem(order.getItemId()); + + //客户端传入的和服务端查询到的商品单价不匹配的时候，给予友好提示 + + if (!order.getItemPrice().equals(item.getItemPrice())) { + + throw new RuntimeException("您选购的商品价格有变化，请重新下单"); + + } + + //重新设置商品单价 + + order.setItemPrice(item.getItemPrice()); + + //重新计算商品总价 + + BigDecimal totalPrice = item.getItemPrice().multiply(BigDecimal.valueOf(order.getQuantity())); + + //客户端传入的和服务端查询到的商品总价不匹配的时候，给予友好提示 + + if (order.getItemTotalPrice().compareTo(totalPrice)!=0) { + + throw new RuntimeException("您选购的商品总价有变化，请重新下单"); + + } + + //重新设置商品总价 + + order.setItemTotalPrice(totalPrice); + + createOrder(order); + +} + + + +还有一种可行的做法是，让客户端仅传入需要的数据给服务端，像这样重新定义一个 POJO CreateOrderRequest 作为接口入参，比直接使用领域模型 Order 更合理。在设计接口时，我们会思考哪些数据需要客户端提供，而不是把一个大而全的对象作为参数提供给服务端，以避免因为忘记在服务端重置客户端数据而导致的安全问题。 + +下单成功后，服务端处理完成后会返回诸如商品单价、总价等信息给客户端。此时，客户端可以进行一次判断，如果和之前客户端的数据不一致的话，给予用户提示，用户确认没问题后再进入支付阶段： + +@Data + +public class CreateOrderRequest { + + private long itemId; //商品ID + + private int quantity; //商品数量 + +} + +@PostMapping("orderRight2") + +public Order right2(@RequestBody CreateOrderRequest createOrderRequest) { + + //商品ID和商品数量是可信的没问题，其他数据需要由服务端计算 + + Item item = Db.getItem(createOrderRequest.getItemId()); + + Order order = new Order(); + + order.setItemPrice(item.getItemPrice()); + + order.setItemTotalPrice(item.getItemPrice().multiply(BigDecimal.valueOf(order.getQuantity()))); + + createOrder(order); + + return order; + +} + + + +通过这个案例我们可以看到，在处理客户端提交过来的数据时，服务端需要明确区分，哪些数据是需要客户端提供的，哪些数据是客户端从服务端获取后在客户端计算的。其中，前者可以信任；而后者不可信任，服务端需要重新计算，如果客户端和服务端计算结果不一致的话，可以给予友好提示。 + +客户端提交的参数需要校验 + +对于客户端的数据，我们还容易忽略的一点是，误以为客户端的数据来源是服务端，客户端就不可能提交异常数据。我们看一个案例。 + +有一个用户注册页面要让用户选择所在国家，我们会把服务端支持的国家列表返回给页面，供用户选择。如下代码所示，我们的注册只支持中国、美国和英国三个国家，并不对其他国家开放，因此从数据库中筛选了 id 的国家返回给页面进行填充： + +@Slf4j + +@RequestMapping("trustclientdata") + +@Controller + +public class TrustClientDataController { + + //所有支持的国家 + + private HashMap allCountries = new HashMap<>(); + + public TrustClientDataController() { + + allCountries.put(1, new Country(1, "China")); + + allCountries.put(2, new Country(2, "US")); + + allCountries.put(3, new Country(3, "UK")); + + allCountries.put(4, new Country(4, "Japan")); + + } + + @GetMapping("/") + + public String index(ModelMap modelMap) { + + List countries = new ArrayList<>(); + + //从数据库查出ID<4的三个国家作为白名单在页面显示 + + countries.addAll(allCountries.values().stream().filter(country -> country.getId()<4).collect(Collectors.toList())); + + modelMap.addAttribute("countries", countries); + + return "index"; + + } + +} + + + +我们通过服务端返回的数据来渲染模板： + +... + +
+ + + + + + + +