为什么spring中的controller跳转出错_你的业务代码中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@DatapublicclassUserEntity{ @Id @GeneratedValue(strategy=AUTO) privateLongid; privateStringname; publicUserEntity(){ } publicUserEntity(Stringname){ this.name=name; }}
为了方便理解,我使用 Spring JPA 做数据库访问,实现这样一个 Repository,新增一个根据用户名查询所有数据的方法:
@RepositorypublicinterfaceUserRepositoryextendsJpaRepository { List findByName(String name);}
定义一个 UserService 类,负责业务逻辑处理。如果不清楚 @Transactional 的实现方式,只考虑代码逻辑的话,这段代码看起来没有问题。
定义一个入口方法 createUserWrong1 来调用另一个私有方法 createUserPrivate,私有方法上标记了 @Transactional 注解。当传入的用户名包含 test 关键字时判断为用户名不合法,抛出异常,让用户创建操作失败,期望事务可以回滚:
@Service@Slf4jpublicclassUserService{ @Autowired privateUserRepository userRepository; //一个公共方法供Controller调用,内部调用事务性的私有方法 publicintcreateUserWrong1(String name) { try{ this.createUserPrivate(newUserEntity(name)); } catch(Exception ex) { log.error("create user failed because {}", ex.getMessage()); } returnuserRepository.findByName(name).size(); } //标记了@Transactional的private方法 @Transactional privatevoidcreateUserPrivate(UserEntity entity) { userRepository.save(entity); if(entity.getName().contains("test")) thrownewRuntimeException("invalid username!"); } //根据用户名查询用户数 publicintgetUserCount(String name) { returnuserRepository.findByName(name).size(); }}
下面是 Controller 的实现,只是调用一下刚才定义的 UserService 中的入口方法createUserWrong1。
@AutowiredprivateUserServiceuserService;@GetMapping("wrong1")publicintwrong1(@RequestParam("name")Stringname){ returnuserService.createUserWrong1(name);}
调用接口后发现,即便用户名不合法,用户也能创建成功。刷新浏览器,多次发现有十几个的非法用户注册。
这里给出 @Transactional 生效原则 1,除非特殊配置(比如使用 AspectJ 静态织入实现AOP),否则只有定义在 public 方法上的 @Transactional 才能生效。原因是,Spring默认通过动态代理的方式实现 AOP,对目标方法进行增强,private 方法无法代理到,Spring 自然也无法动态增强事务处理逻辑。
你可能会说,修复方式很简单,把标记了事务注解的 createUserPrivate 方法改为 public即可。在 UserService 中再建一个入口方法 createUserWrong2,来调用这个 public 方法再次尝试:
publicintcreateUserWrong2(Stringname){ try{ this.createUserPublic(newUserEntity(name)); } catch(Exceptionex){ log.error("createuserfailedbecause{}",ex.getMessage()); } returnuserRepository.findByName(name).size();}//标记了@Transactional的public方法@Transactionalpublic void createUserPublic(UserEntity entity) { userRepository.save(entity); if(entity.getName().contains("test")) thrownewRuntimeException("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")publicintright2(@RequestParam("name")Stringname){ try{ userService.createUserPublic(newUserEntity(name)); } catch(Exceptionex){ log.error("createuserfailedbecause{}",ex.getMessage()); } returnuserService.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.JpaTransactionManag//在Controller中通过注入的UserServiceBean调用createUserPublic[10:10:47.750][http-nio-45678-exec-6][DEBUG][o.s.orm.jpa.JpaTransactionManag
你可能还会考虑一个问题,这种实现在 Controller 里处理了异常显得有点繁琐,还不如直接把 createUserWrong2 方法加上 @Transactional 注解,然后在 Controller 中直接调用这个方法。这样一来,既能从外部(Controller 中)调用 UserService 中的方法,方法又是 public 的能够被动态代理 AOP 增强。
你可以试一下这种方法,但很容易就会踩第二个坑,即因为没有正确处理异常,导致事务即便生效也不一定能回滚。
二、事务即便生效也不一定能回滚
通过 AOP 实现事务处理可以理解为,使用 try…catch…来包裹标记了 @Transactional 注解的方法,当方法出现了异常并且满足一定条件的时候,在 catch 里面我们可以设置事务回滚,没有异常则直接提交事务。
这里的“一定条件”,主要包括两点。
第一,只有异常传播出了标记了 @Transactional 注解的方法,事务才能回滚。在 Spring的 TransactionAspectSupport 里有个 invokeWithinTransaction 方法,里面就是处理事务的逻辑。可以看到,只有捕获到异常才能进行后续事务处理:
try{ //Thisisanaroundadvice:Invokethenextinterceptorinthechain.//Thiswillnormallyresultinatargetobjectbeinginvoked. retVal=invocation.proceedWithInvocation();}catch(Throwableex){ //targetinvocationexception completeTransactionAfterThrowing(txInfo,ex); throwex;}finally{ cleanupTransactionInfo(txInfo);}
第二,**默认情况下,出现 RuntimeException(非受检异常)或 Error 的时候,Spring才会回滚事务
。
打开 Spring 的 DefaultTransactionAttribute 类能看到如下代码块,可以发现相关证据,通过注释也能看到 Spring 这么做的原因,大概的意思是受检异常一般是业务异常,或者说是类似另一种方法的返回值,出现这样的异常可能业务还能完成,所以不会主动回滚;而Error 或 RuntimeException 代表了非预期的结果,应该回滚:
/** *ThedefaultbehaviorisaswithEJB:rollbackonuncheckedexception *({@linkRuntimeException}),assuminganunexpectedoutcomeoutsideofany *businessrules.Additionally,wealsoattempttorollbackon{@linkError}w *isclearlyanunexpectedoutcomeaswell.Bycontrast,acheckedexceptioni *consideredabusinessexceptionandthereforearegularexpectedoutcomeof *transactionalbusinessmethodi.e.akindofalternativereturnvaluewhich, *stillallowsforregularcompletionofresourceoperations. *p>ThisislargelyconsistentwithTransactionTemplate'sdefaultbehavior, *exceptthatTransactionTemplatealsorollsbackonundeclaredcheckedexcept *(acornercase).Fordeclarativetransactions,weexpectcheckedexceptions *intentionallydeclaredasbusinessexceptions,leadingtoacommitbydefaul *@seeorg.springframework.transaction.support.TransactionTemplate#execute*/@OverridepublicbooleanrollbackOn(Throwableex){ return(exinstanceofRuntimeException||exinstanceofError);}
接下来,我和你分享 2 个反例。
重新实现一下 UserService 中的注册用户操作:
- 在 createUserWrong1 方法中会抛出一个 RuntimeException,但由于方法内 catch 了所有异常,异常无法从方法传播出去,事务自然无法回滚。
- 在 createUserWrong2 方法中,注册用户的同时会有一次 otherTask 文件读取操作,如果文件读取失败,我们希望用户注册的数据库操作回滚。虽然这里没有捕获异常,但因为 otherTask 方法抛出的是受检异常,createUserWrong2 传播出去的也是受检异常,事务同样不会回滚。
@Service@Slf4jpublicclassUserService{ @Autowired privateUserRepositoryuserRepository; //异常无法传播出方法,导致事务无法回滚 @Transactional publicvoidcreateUserWrong1(Stringname){ try{ userRepository.save(newUserEntity(name)); thrownewRuntimeException("error"); } catch(Exceptionex){ log.error("createuserfailed",ex); } } //即使出了受检异常也无法让事务回滚 @Transactional publicvoidcreateUserWrong2(Stringname)throwsIOException{ userRepository.save(newUserEntity(name)); otherTask(); } //因为文件不存在,一定会抛出一个IOException privatevoidotherTask()throwsIOException{ Files.readAllLines(Paths.get("file-that-not-exist")); }}
Controller 中的实现,仅仅是调用 UserService 的 createUserWrong1 和createUserWrong2 方法,这里就贴出实现了。这 2 个方法的实现和调用,虽然完全避开了事务不生效的坑,但因为异常处理不当,导致程序没有如我们期望的文件操作出现异常时回滚事务。
现在,我们来看下修复方式,以及如何通过日志来验证是否修复成功。针对这 2 种情况,对应的修复方法如下。
第一,如果你希望自己捕获异常进行处理的话,也没关系,可以手动设置让当前事务处于回滚状态:
@TransactionalpublicvoidcreateUserRight1(Stringname){ try{ userRepository.save(newUserEntity(name)); thrownewRuntimeException("error"); } catch(Exceptionex){ log.error("createuserfailed",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.JpaTransactionManag[22:14:49.353][http-nio-45678-exec-4][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:14:49.353][http-nio-45678-exec-4][DEBUG][o.s.orm.jpa.JpaTransactionManag
第二,在注解中声明,期望遇到所有的 Exception 都回滚事务(来突破默认不回滚受检异常的限制):
@Transactional(rollbackFor=Exception.class)publicvoidcreateUserRight2(Stringname)throwsIOException{ userRepository.save(newUserEntity(name)); otherTask();}
运行后,同样可以在日志中看到回滚的提示:
[22:10:47.980][http-nio-45678-exec-4][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:10:47.981][http-nio-45678-exec-4][DEBUG][o.s.orm.jpa.JpaTransactionManag
在这个例子中,我们展现的是一个复杂的业务逻辑,其中有数据库操作、IO 操作,在 IO操作出现问题时希望让数据库事务也回滚,以确保逻辑的一致性。在有些业务逻辑中,可能会包含多次数据库操作,我们不一定希望将两次操作作为一个事务来处理,这时候就需要仔细考虑事务传播的配置了,否则也可能踩坑。
三、请确认事务传播配置是否符合自己的业务逻辑
有这么一个场景:一个用户注册的操作,会插入一个主用户到用户表,还会注册一个关联的子用户。我们希望将子用户注册的数据库操作作为一个独立事务来处理,即使失败也不会影响主流程,即不影响主用户的注册。
接下来,我们模拟一个实现类似业务逻辑的 UserService:
@AutowiredprivateUserRepositoryuserRepository;@AutowiredprivateSubUserServicesubUserService;@TransactionalpublicvoidcreateUserWrong(UserEntityentity){ createMainUser(entity); subUserService.createSubUserWithExceptionWrong(entity);}privatevoidcreateMainUser(UserEntityentity){ userRepository.save(entity); log.info("createMainUserfinish");}
SubUserService 的 createSubUserWithExceptionWrong 实现正如其名,因为最后我们抛出了一个运行时异常,错误原因是用户状态无效,所以子用户的注册肯定是失败的。我们期望子用户的注册作为一个事务单独回滚,不影响主用户的注册,这样的逻辑可以实现吗?
@Service@Slf4jpublicclassSubUserService{ @Autowired privateUserRepositoryuserRepository; @Transactional publicvoidcreateSubUserWithExceptionWrong(UserEntityentity){ log.info("createSubUserWithExceptionWrongstart"); userRepository.save(entity); thrownewRuntimeException("invalidstatus"); }}
我们在 Controller 里实现一段测试代码,调用 UserService:
@GetMapping("wrong")publicintwrong(@RequestParam("name")Stringname){ try{ userService.createUserWrong(newUserEntity(name)); } catch(Exceptionex){ log.error("createUserWrongfailed,reason:{}",ex.getMessage()); } returnuserService.getUserCount(name);}
调用后可以在日志中发现如下信息,很明显事务回滚了,最后 Controller 打出了创建子用户抛出的运行时异常:
[22:50:42.866][http-nio-45678-exec-8][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:50:42.869][http-nio-45678-exec-8][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:50:42.869][http-nio-45678-exec-8][ERROR][t.d.TransactionPropagationCont
你马上就会意识到,不对呀,因为运行时异常逃出了 @Transactional 注解标记的createUserWrong 方法,Spring 当然会回滚事务了。如果我们希望主方法不回滚,应该把子方法抛出的异常捕获了。
也就是这么改,把 subUserService.createSubUserWithExceptionWrong 包裹上catch,这样外层主方法就不会出现异常了:
@TransactionalpublicvoidcreateUserWrong2(UserEntityentity){ createMainUser(entity); try{ subUserService.createSubUserWithExceptionWrong(entity); } catch(Exceptionex){ //虽然捕获了异常,但是因为没有开启新事务,而当前事务因为异常已经被标记为rollback了 log.error("createsubusererror:{}",ex.getMessage()); }}
运行程序后可以看到如下日志:
[22:57:21.722][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.739][http-nio-45678-exec-3][INFO][t.c.transaction.demo3.SubUserSe[22:57:21.739][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.739][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.740][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.740][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.740][http-nio-45678-exec-3][ERROR][.g.t.c.transaction.demo3.UserSe[22:57:21.740][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.740][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.743][http-nio-45678-exec-3][DEBUG][o.s.orm.jpa.JpaTransactionManag[22:57:21.743][http-nio-45678-exec-3][ERROR][t.d.TransactionPropagationContorg.springframework.transaction.UnexpectedRollbackException:Transactionsilent...
需要注意以下几点:
- 如第 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)publicvoidcreateSubUserWithExceptionRight(UserEntityentity){ log.info("createSubUserWithExceptionRightstart"); userRepository.save(entity); thrownewRuntimeException("invalidstatus");}
主方法没什么变化,同样需要捕获异常,防止异常漏出去导致主事务回滚,重新命名为createUserRight:
@TransactionalpublicvoidcreateUserRight(UserEntityentity){ createMainUser(entity); try{ subUserService.createSubUserWithExceptionRight(entity); } catch(Exceptionex){ //捕获异常,防止主方法回滚 log.error("createsubusererror:{}",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.JpaTransactionManag[23:17:21.079][http-nio-45678-exec-1][INFO][.g.t.c.transaction.demo3.UserSe[23:17:21.082][http-nio-45678-exec-1][DEBUG][o.s.orm.jpa.JpaTransactionManag[23:17:21.153][http-nio-45678-exec-1][DEBUG][o.s.orm.jpa.JpaTransactionManag[23:17:21.160][http-nio-45678-exec-1][DEBUG][o.s.orm.jpa.JpaTransactionManag[23:17:21.161][http-nio-45678-exec-1][ERROR][.g.t.c.transaction.demo3.UserSe[23:17:21.161][http-nio-45678-exec-1][DEBUG][o.s.orm.jpa.JpaTransactionManag[23:17:21.161][http-nio-45678-exec-1][DEBUG][o.s.orm.jpa.JpaTransactionManag
运行测试程序看到如下结果,getUserCount 得到的用户数量为 1,代表只有一个用户也就是主用户注册完成了,符合预期:
四、总结
本文针对业务代码中最常见的使用数据库事务的方式,即 Spring 声明式事务,与你总结了使用上可能遇到的三类坑,包括:
- 第一,因为配置不正确,导致方法上的事务没生效。我们务必确认调用 @Transactional 注解标记的方法是 public 的,并且是通过 Spring 注入的 Bean 进行调用的。
- 第二,因为异常处理不正确,导致事务虽然生效但出现异常时没回滚。Spring 默认只会对标记 @Transactional 注解的方法出现了 RuntimeException 和 Error 的时候回滚,如果我们的方法捕获了异常,那么需要通过手动编码处理事务回滚。如果希望 Spring 针对其他异常也可以回滚,那么可以相应配置 @Transactional 注解的 rollbackFor 和noRollbackFor 属性来覆盖其默认设置。
- 第三,如果方法涉及多次数据库操作,并希望将它们作为独立的事务进行提交或回滚,那么我们需要考虑进一步细化配置事务传播方式,也就是 @Transactional 注解的Propagation 属性。
可见,正确配置事务可以提高业务项目的健壮性。但,又因为健壮性问题往往体现在异常情况或一些细节处理上,很难在主流程的运行和测试中发现,导致业务代码的事务处理逻辑往往容易被忽略,因此我在代码审查环节一直很关注事务是否正确处理。
如果你无法确认事务是否真正生效,是否按照预期的逻辑进行,可以尝试打开 Spring 的部分 Debug 日志,通过事务的运作细节来验证。也建议你在单元测试时尽量覆盖多的异常场景,这样在重构时,也能及时发现因为方法的调用方式、异常处理逻辑的调整,导致的事务失效问题。
推荐阅读
盘点:2020年最新、最全、最实用的Java岗面试真题,已收录GitHub
绝对干货,掌握这27个知识点,轻松拿下80%的技术面试(Java岗)
一线大厂为什么面试必问分布式?
在一次又一次的失败中,我总结了这份万字的《MySQL性能调优笔记》
并发编程详解:十三个工具类,十大设计模式,从理论基础到案例实战
如何高效部署分布式消息队列?这份《RabbitMQ实战》绝对可以帮到你
为什么spring中的controller跳转出错_你的业务代码中Spring声明式事务处理正确了吗?相关推荐
- spring 事务原理_Spring声明式事务处理的实现原理,来自面试官的穷追拷问
公众号[JavaQ]原创,专注分享Java基础原理分析.实战技术.微服务架构.分布式系统构建,诚邀点赞关注! 面试官:有如下代码场景,A类的a1方法没有标注@Transactional注解,a2方法标 ...
- 大数据WEB阶段Spring框架(三)声明式事务处理
Spring整合JDBC-声明式的事务处理 一.Spring整合JDBC步骤 导入jar包 编写数据库配置文件 也可以将数据库配置信息单独配置后引入Spring容器中 代码中使用 二.Spring框架 ...
- qt中如何模拟按钮点击_如何快速在 Shopify 中加入按钮
假如你会 `CSS` , `HTML` , `JS` 三件套,那么修改 `Shopify` 代码将不会太难(毕竟一个模板中的代码量还是挺多的,除非深入研究了代码,不然改起来还是会比较麻烦的). 但挺多 ...
- JVM 性能调优实战之:使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码...
本文是<JVM 性能调优实战之:一次系统性能瓶颈的寻找过程> 的后续篇,该篇介绍了如何使用 JDK 自身提供的工具进行 JVM 调优将 TPS 由 2.5 提升到 20 (提升了 7 倍) ...
- xxljob在业务代码中添加任务(登录后token验证)
之前做过一次在业务代码中调用xxljob的接口添加任务启动任务,xxljob的接口添加免登录验证注解后直接调用,博文地址:xxl-job 在业务代码中添加任务,后面用到的groupId获取方法也在这里 ...
- 天天写业务代码?写业务代码中的成长机会!
写业务代码有成长机会吗?关于这个问题,答案非常肯定:必须有成长机会.对于大部分公司而言,能够写底层代码或者中间件代码的人总是有限的,写业务代码会面临更高的复杂度. 这里分三个层次来看其中的成长机会. ...
- controller调用另一个controller中的方法 获取返回值_必须掌握!你知道 Spring 中运用的 9 种设计模式吗 ?...
Spring中涉及的设计模式总结,在面试中也会经常问道 Spring 中设计模式的问题.本文以实现方式.实质.实现原理的结构简单介绍 Sping 中应用的 9 种设计模型,具体详细的刨析会在后面的文章 ...
- spring autowired idea都匹配上了_你清楚这几个Spring常用注解吗?
作者:平凡希http://cnblogs.com/xiaoxi/p/5935009.html 传统的Spring做法是使用.xml文件来对bean进行注入或者是配置aop.事物,这么做有两个缺点: 如 ...
- spring cloud是什么时候流行的_老司机给我们解读 Spring Boot 最流行的 16 条实践 - 码农突围
Spring Boot 是最流行的用于开发微服务的 Java 框架.在本文中,我将与你分享自 2016 年以来我在专业开发中使用 Spring Boot 所采用的最佳实践.这些内容是基于我的个人经验和 ...
最新文章
- 注册表----修改Win7登录界面
- Maria数据库怎么复制到mysql_maria(mysql)的主从复制
- python安装3.7.2_linux环境安装python3.7.2
- android中TextView显示中文发生乱码的问题
- 油井在哪_身边榜样 | 张景岗:“油井越‘生气,自己越开心”
- 各家版本控制系统(VCS)对比:VSS、SVN、Git。代码托管平台对比:GitLab、GitHub、码云(Gitee)、SourceForge、DevCloud(华为软件开发云)
- 01需求工程-软件建模与分析阅读笔记
- 教你开发jQuery插件(转)
- 拜托,面试别再问我计数和桶排序了!!!
- 手把手教你做一个Excel 2007数据透视表(有图有真相)
- GD32 NAND U盘
- 无线通信设备安装工程概预算编制_建筑安装工程,预算编制中易遗漏总结分享...
- 免费云真机测试 | 让您的应用完美适配 Android Oreo
- Python之统计英文字符的个数
- Bat 脚本学习 (基础篇)
- 赫克Hurco工控机维修WinMax数控机床控制器维修
- python怎么关闭浏览器_/python里webbrowser怎么关闭游览器
- Hadoop中的slaves文件
- 游戏充值数据分析报告
- 一文搞定python绘折线图(标题,自定义刻度范围,xy轴刻度值的大小,垂直xy轴的虚线,标签,图例)