面试官：今天要不来聊聊SpringMVC吧？ 候选者：我先简单说下我对SpringMVC的理解哈 候选者：SpringMVC我觉得它是对Servlet的封装，屏蔽掉Servlet很多的细节 候选者：举几个例子 候选者：可能我们刚学Servlet的时候，要获取参数需要不断的getParameter 候选者：现在只要在SpringMVC方法定义对应的JavaBean，只要属性名与参数名一致，SpringMVC就可以帮我们实现「将参数封装到JavaBean」上了 候选者：又比如，以前使用Servlet「上传文件」，需要处理各种细节，写一大堆处理的逻辑（还得导入对应的jar） 候选者：现在一个在SpringMVC的方法上定义出MultipartFile接口，又可以屏蔽掉上传文件的细节了。 候选者：例子还有很多，我就不一一赘述了。 面试官：既然你说SpringMVC是对Servlet的封装，你了解SpringMVC请求处理的流程吗？ 候选者：嗯，当然了，我看过源码。总体流程大概是这样的 候选者：1):首先有个统一处理请求的入口 候选者：2):随后根据请求路径找到对应的映射器 候选者：3):找到处理请求的适配器 候选者：4):拦截器前置处理 候选者：5):真实处理请求（也就是调用真正的代码) 候选者：6): 视图解析器处理 候选者：7):拦截器后置处理 面试官：嗯，了解，可以再稍微深入点吗？ 面试官：毕竟这随便在网上找张SpringMVC流程图，就可以答出来了，看不出来你看过源码啊 候选者：哦？那我就简单补充下细节吧。 候选者：统一的处理入口，对应SpringMVC下的源码是在DispatcherServlet下实现的 候选者：该对象在初始化就会把映射器、适配器、视图解析器、异常处理器、文件处理器等等给初始化掉 候选者：至于会初始化哪些具体实例，看下 候选者：所有的请求其实都会被doService方法处理，里边最主要就是调用doDispatch方法 候选者：通过doDispatch方法我们就可以看到整个SpringMVC处理的流程 候选者：查找映射器的时候实际就是找到「最佳匹配」的路径，具体方法实现我记得好像是在lookupHandlerMethod方法上 候选者：从源码可以看到「查找映射器」实际返回的是HandlerExecutionChain，里边有映射器Handler+拦截器List 候选者：前面提到的拦截器前置处理和后置处理就是用的HandlerExecutionChain中的拦截器List 候选者：获取得到HandlerExecutionChain后，就会去获取适配器，一般我们获取得到的就是RequestMappingHandlerAdapter 候选者：在代码里边可以看到的是，经常用到的@ResponseBody和@Requestbody的解析器 候选者：就会在初始化的时候加到参数解析器List中 候选者：得到适配器之后，就会执行拦截器前置处理 面试官：嗯 候选者：拦截器前置处理执行完后，就会调用适配器对象实例的hanlde方法执行真正的代码逻辑处理 候选者：核心的处理逻辑在invokeAndHandle方法中，会获取得到请求的参数并调用，处理返回值 候选者：参数的封装以及处理会被适配器的参数解析器进行处理，具体的处理逻辑取决于HttpMessageConverter的实例对象 面试官：嗯，了解了。要不你再压缩下关键的信息 候选者：DispatcherServlet（入口）->DispatcherServlet.properties（会初始化的对象）->HandlerMapping（映射器）->HandlerExecutionChain(映射器+拦截器List) ->HttpRequestHandlerAdapter(适配器)->HttpMessageConverter(数据转换) 面试官：最后来画张流程图吧？ 候选者：没问题（上网找的比我画的还要好） 面试官：我看到你的简历写着熟悉Spring 面试官：要不你来讲讲Spring 的IOC和AOP你是怎么理解的呗？ 候选者：嗯嗯，IOC和AOP是Spring非常核心的知识点 候选者：我就先来讲讲Spring IOC？ 面试官：嗯 候选者：我个人理解下：Spring IOC 解决的是对象管理和对象依赖的问题。 候选者：本来是我们自己手动new出来的对象，现在则把对象交给Spring的IOC容器管理 候选者：IOC容器可以理解为一个对象工厂，我们都把该对象交给工厂，工厂管理这些对象的创建以及依赖关系 候选者：等我们需要用对象的时候，从工厂里边获取就好了 面试官：嗯，说起IOC，就可以在网上或书籍经常看到的两个概念 候选者：哦，你说的就是「控制反转」和「注入依赖」吧？ 面试官：你怎么还抢答的咯…那你顺便说说你对这两个概念的理解呗？ 候选者：我认为「控制反转」指的就是：把原有自己掌控的事交给别人去处理 候选者：它更多的是一种思想或者可以理解为设计模式 候选者：比如：本来由我们自己new出来的对象，现在交由IOC容器，把对象的控制权交给它方了 候选者：而「依赖注入」在我的理解下，它其实是「控制反转」的实现方式 候选者：对象无需自行创建或者管理它的依赖关系，依赖关系将被「自动注入」到需要它们的对象当中去 面试官：嗯，那我想问问，用Spring IOC有什么好处吗？ 面试官：或者换个问法：本来我可以new出来的对象，为什么我要交由Spring IOC容器 管理呢？ 候选者：主要的好处在于「将对象集中统一管理」并且「降低耦合度」 候选者：如果面试官理解了「工厂模式」，那就知道为什么我们不直接new对象 面试官：好家伙，不行，这答案我观众不满意！ 候选者：要说理由的话，可以举很多例子，比如说： 候选者：我用Spring IOC 可以方便单元测试、对象创建复杂、对象依赖复杂、单例等等的，什么都可以交给Spring IOC 候选者：理论上自己new出来的都可以解决上面的问题，Spring在各种场景组合下有可能不是最优解 候选者：但new出来的你要自己管理，可能你得自己写工厂，得实现一大套的东西才能满足需求 候选者：写着写着有可能还是Spring的那一套 候选者：但现在Spring现在已经帮你实现了啊！ 候选者：如果项目里的对象都是就new下就完事了，没有多个实现类，那没事，不用Spring也没啥问题 候选者：并且Spring核心不仅仅IOC啊，除了把对象创建出来，还有一整套的Bean生命周期管理 候选者：比如说你要实现对象增强，AOP不就有了吗？不然你还得自己创建代理.. 面试官：好好好 面试官：但我看这届观众好像还是不太满意？ 候选者：不，他们已经满意了。 面试官：那你继续来聊下Spring AOP呗？ 候选者：Spring AOP 解决的是 非业务代码抽取的问题 候选者：AOP 底层的技术是动态代理，在Spring内实现依赖的是BeanPostProcessor 候选者：比如我们需要在方法上注入些「重复性」的非业务代码，就可以利用Spring AOP 候选者：所谓的「面向切面编程」在我理解下其实就是在方法前后增加非业务代码 面试官：那你在工作中实际用到过AOP去优化你的代码吗？ 候选者：有的。当时我用AOP来对我们公司现有的监控客户端进行封装 候选者：一个系统离不开监控，监控基本的指标有QPS、RT、ERROR等等 候选者：对外暴露的监控客户端只能在代码里写对应的上报信息（灵活，但会与业务代码掺杂在一起） 候选者：于是我利用注解+AOP的方式封装了一把，只要方法/类上带有我自定义的注解 候选者：方法被调用时，就会上报AQS、RT等信息 候选者：实现了非业务代码与业务代码分离的效果（： 面试官：你们项目一般是怎么把对象交给IOC容器管理的？ 面试官：换个问法：一般是怎么定义Bean的？ 候选者：Spring提供了4种方式，分别是： 候选者：1):注解 2):XML 3):JavaConfig 4):基于Groovy DSL配置 候选者：一般项目我们用注解或XML比较多，少部分用JavaConfig 候选者：日常写业务代码一般用注解来定义各种对象，责任链这种一般配置在XML，「注解」解决不了的就用JavaConfig 候选者：总体而言，还是得看项目的代码风格吧（： 候选者：反正就是定义元数据，能给到Spring解析就好了 面试官：嗯，了解。 面试官：要不来聊聊你使用Spring的感受？ 候选者：嗯嗯.. 候选者：当我还是初学Spring的时候，我觉得Spring很麻烦，需要有一大堆的配置信息才能跑起来 候选者：光是搭建环境就需要耗费我好长的时间 候选者：毕竟版本冲突，依赖冲突什么的就可能一个下午就过去了 候选者：但毕竟一个系统环境只搭一次嘛，所以还好 候选者：（后来用上了SpringBoot这又更方便了） 面试官：嗯… 候选者：话说回来，IOC和AOP在工作用的时候还是很爽的 候选者：毕竟搞个注解什么的，配置下就可以把对象交给Spring管理了 候选者：配合Spring的生态，@Transactional注解什么的，都好用得飞起 候选者：不过，Spring给我们封装得太好了 候选者：经常就会有奇奇怪怪的bug出现，也踩过很多的坑了 候选者：Bean经常没办法创建成功，导致项目启动失败 候选者：对象的循环依赖问题… 候选者：同一个接口，多个实现，识别不出我要创建哪个对象… 候选者：为什么catch了异常，Spring事务为什么还会自动回滚 候选者：等等等….. 候选者：总的来说，Spring给我们封装了一个很好的环境，实现对我们屏蔽了 候选者：但是如果理解不深的话，很有可能就会触发各种bug 面试官：了解 austin项目立志成为每个Java初学者能够写在简历上的项目 austin项目核心功能：统一的接口发送各种类型消息，对消息生命周期全链路追踪 项目出现意义：只要公司内有发送消息的需求，都应该要有类似austin的项目，对各类消息进行统一发送处理。这有利于对功能的收拢，以及提高业务需求开发的效率 《对线面试官》是我连载了近一年一个讲人话面试系列，我曾经通过这些资料去斩获了不少的公司的offer，基本涵盖了Java常问的知识点。 八股文不再是背诵！已有不少的同学通过对线面试官的分享得到BATTMD等一线大厂的的offer！《对线面试官》已有电子书 在自学之路上，我已经把【基础重要的知识点】、【简历模板】、【思维导图】【对线面试官】等等全部整理成电子书，共有1263页！已经有8756个初学者都下载了！ 我把这些上传到网盘，你们有需要直接下载就好了。做到这份上了，不会还想白嫖吧？点赞和转发又不用钱。 链接:pan.baidu.com/s/1pQTuKBYs…密码:3wom
DispatcherServlet.properties就知道了，都配置在那了
austin项目
项目Gitee链接：gitee/austin
项目GitHub链接：https://github.com/austin
对线面试官
戳Gitee链接：Java3y/athena
我的原创电子书
不会有人刷到这还想白嫖吧？不会吧？点赞对真的我很重要！要不加个关注？
我是3y，一年CRUD经验用十年的markdown程序员 常年被誉为优质八股文选手。
声明：本文部分素材转载自互联网，如有侵权立即删除 。
2. 分享目的仅供大家学习和交流，您必须在下载后24小时内删除！
3. 不得使用于非法商业用途，不得违反国家法律。否则后果自负！
4. 本站提供的源码、模板、插件等等其他资源，都不包含技术服务请大家谅解！
5. 如有链接无法下载、失效或广告，请联系管理员处理！
6. 本站资源售价只是赞助，收取费用仅维持本站的日常运营所需！
7. 如遇到加密压缩包，请使用WINRAR解压,如遇到无法解压的请联系管理员！
8. 精力有限，不少源码未能详细测试（解密），不能分辨部分源码是病毒还是误报，所以没有进行任何修改，大家使用前请进行甄别
丞旭猿论坛
暂无评论内容