SpringBoot进阶之事务管理及并发问题
大家好，一直以来我都本着用最通俗的话理解核心的知识点, 我认为所有的难点都离不开 「基础知识」 的铺垫。目前正在出一个 SpringBoot 长期系列教程，从入门到进阶, 篇幅会较多~
「大佬可以绕过 ~」
如果你是一路看过来的，很高兴你能够耐心看完。之前带大家学了 Springboot 基础部分，对基本的使用有了初步的认识, 接下来的几期内容将会带大家进阶使用，会先讲解基础 中间件 的使用和一些场景的应用，或许这些技术你听说过，没看过也没关系，我会带大家一步一步的入门，耐心看完你一定会有 收获 ~
上期带大家学习了 SpringBoot 中如何去拦截请求, 本期将带大家学习 MyBatis 中如何进行 事务管理 ，同样的，我们集成到 Springboot 中。最近github可能会被墙，所以我把源码放到了国内gitee上,本节我们依然使用上期的代码
我们先了解一下它的基本概念。其实 事务 它不仅是在这里我们提到的 mybatis ,其实它在数据库中也是存在的。 事务 我们从字面意思理解，它好比烤面包，经过一些列的步骤之后，最终提供给客户完整的面包，也就是说中间出现差错，就得回退。可能举这个例子不大合适，再举一个我们业务中的场景吧。用户购买一个商品，首先下单，下完单之后进行支付，支付成功后订单为支付成功状态，跳转成功页，这一系列操作就是一个事务，要么成功要么失败。
在通过上面的例子有了大概了解之后，我们再看看它的基本概念。
下面带大家看看 sql 如何执行事务操作。下面举个例子比较一下
没有事务操作的时候:
以之前的场景给大家举例, 用户支付减少余额 并改订单状态为成功。 当我们的程序执行了上边的两条 sql ，大家觉得有问题吗？这肯定得出事，这不得被人薅死。虽然语句没报错，但是逻辑错了，为啥 因为余额变成负数了，这不是没钱白嫖,还指望用户给你冲上吗。然后订单还给成功了，如果遇到并发大的时候，这得多少钱，发还是不发货呢？告诉用户系统问题？老板看了得哭死。
所以不管是程序上的错误(sql执行错误),还是逻辑上的错误都不能进行下一步操作,所以事务显的尤为重要。那么 sql 怎么提交事务呢?
上边只是给大家举个例子，生成中我们还得用 mybatis 去操作。
在 SpringBoot 中执行事务非常简单,首先要开启事务 @EnableTransactionManagement ,在启动类上加上:
添加控制器方法:
我们访问 , 发现数据库并没有产生新纪录和更新记录， @Transactional(rollbackFor = Exception.class) 表示开启一个事务，当捕获到 Exception 异常就进行回滚。把 name 换掉会发现，执行成功了。
执行失败的时候:
那有没有 手动 去执行回滚操作的呢？有时候，我们总不能靠异常来判断，需要通过逻辑判断:
上边的方法 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); 就是干这个的。
其实本节到这里差不多就结束了，给大家多讲一点, 其实这一块内容理论知识点还是比较多多的，这也是面试比较喜欢问的，因为这里真就靠大家自己去理解和学习了，写代码谁都会，但是讲出来，不一定每个人都讲的好和清楚，因为每个人的理解和认知不一样。
有时候，客户反馈有 bug ,反馈到你这边，你可能会说，我这都是好的。因为我们是本地的，不是跑在线上的，本地就你自己完，所以觉得没啥问题。但线上是很多用户在使用，当多用户使用的时候就会产生并发问题,所以也就是在接口测试的时候为什么要进行一下测试环境的压测，合格后上线。
那么在并发大的时候，我们数据库可能会产生什么问题呢？
好，我们一个一个讲，首先说说什么是丢失更新？
一个事务覆盖另一个事务已提交的更新数据叫丢失更新。这里提到过它存在两种丢失情况,为了让大家能够更加直观的感受，我以存钱和取钱为例讲一下。
首先说说第一种丢失情况
先分配一下角色，事务A,事务B,账户C。 首先A对C进行账户查询，余额为5000，B对A查询，余额为5000，此时余额一样没啥问题。紧接着B对C进行存钱操作，存了1000， 存完B提交事务。而此时A呢，正对着C进行取钱，取了1000， 它也提交了事务。那么问一下大家， C还有多少钱?
最后A查了一下账户，发现只有4000， 发现少了1000。
下边我们把压力给到A这边,第二种其实跟上边是反过来，情况是怎么样的呢？首先A,B跟之前一样，查了下C，余额为5000。此时，A对C进行取钱操作，取了1000，然后提交事务,B呢对A进行存钱操作,存了1000，提交事务。最后B一查，发现账户有6000, C开心极了， 多了1000
上边这两种情况都属于丢失更新的情况
一个事务读取到另一个事务还没提交的数据叫脏读。我们还以上边的为例:
这个稍微好理解一点,事务A和B, 事务A对C进行取钱操作，取了1000, 余额还剩 4000, 此时B呢对C进行查询操作，读到余额为4000。这时产生问题了，因为A现在还是一个未提交的事务，A对账户C取钱操作进行了 回滚 , 紧接着存了1000, 然后进行了 事务提交 , 此时余额为6000。而我们的B读到的数据是4000,所以这就是 脏读
一个事务先后读到另一个事务提交之前的数据和已提交的更新数据。同样的以上边为例，这个大家可能不好理解，下面好好分析一下:
首先事务A和B， A先查询C余额还有 5000， B 查询C,余额还有5000, 紧接着A对C执行取钱操作，取了1000, 提交事务, 此时B执行查询操作，发现C只有4000了。你可能想，这没问题啊，取了1000还有4000，没毛病啊。没问题吗？重复读了两次，结果不一致，这肯定是有问题的。
事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据。这有点抽象,同样的，还以上边为例
事务A和B，B查询C，余额5000， A注销了C,提交了事务，此时B又去查询C, 发现C没了，B事务查询两次，结果确不一致，跟产生了幻觉一样，刚刚还在的，这会没了。
通过上边的几个例子，带大家认识了，并发中可能产生的事务问题，下边给大家总结一下事务的特点, 事务有4个特性，被称为 ACID
下边就给大家讲讲这几个特性:
事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
在事务开始之前和事务结束以后，数据库的完整性没有被破坏
一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成
隔离级别就不给大家讲了，这不是本节的重点内容。本节的重点是大家要学会在 SpringBoot 中如何去执行 事务操作 ,如果你对上边提到的一些概念性的东西还不能理解，也没关系，等以后回过头来看看也许就明白了，做个简单的了解。
有时候我们的系统需要对用户进行区分，也就是不同的用户角色访问不同的资源，比如管理员可以访问后台，而普通用户只能访问前台的页面，再或者只有登录的用户才能访问特定功能，高级管理员可以掌管大局，普通的管理员只能查看某一个菜单。这就是涉及到权限问题了，几乎所有的系统都需要权限管理，这样能保证系统资源的安全性。下期将会带大家学习 Shiro权限 框架, 它是一个轻量级框架，但它的功能确不小, 我会从入门到进阶讲起, 会分为多期去讲。
下期见，关注我，不迷路~
SpringBoot进阶之整合Shiro鉴权框架(四)
大家好，一直以来我都本着用最通俗的话理解核心的知识点, 我认为所有的难点都离不开 「基础知识」 的铺垫。目前正在出一个 SpringBoot 长期系列教程，从入门到进阶, 篇幅会较多~
「大佬可以绕过 ~」
如果你是一路看过来的，很高兴你能够耐心看完。之前带大家学了 Springboot 基础部分，对基本的使用有了初步的认识, 接下来的几期内容将会带大家进阶使用，会先讲解基础 中间件 的使用和一些场景的应用，或许这些技术你听说过，没看过也没关系，我会带大家一步一步的入门，耐心看完你一定会有 收获 ~
上期带大家学习了 Shiro 中如何记录用户状态，本期将带大家学习 Shiro 中如何进行 权限认证 。同样的，我们集成到 Springboot 中。
还记得之前带大家实现的 doGetAuthenticationInfo() 方法实现的用户认证吗，其实还有一个，我们可以用它实现 权限控制 ，这里我们基于 RBAC 基于用户角色来控制权限, 之前有一个方法没实现，我们现在实现一下:
在 Shiro 中，为我们提供了一列好用的注解，我们一起看一下:
使用它之前，我们需要开启它的注解，怎么做呢？在 ShiroConfig 中加入:
下面直接使用就可以了:
这样就可以了， 很简单，大家可以自己运行一下。还有一个疑问 用户没有权限，我想自定义返回错误信息怎么办呢？很简单,我们一起看一下
还记得之前教大家的全局已经捕获吗？没错我们只要在那里加上要捕获的异常类就好了,实际上它是抛出了 AuthorizationException 的异常
这样就可以了~
本期内容就到这里结束了，总结一下，本节主要讲了 Shiro 如何进行权限认证以及常用的权限注解，大家可以自己多试试
下期给大家讲讲 Shiro 中如何进行缓存，缓存对于业务来讲还是比较重要的，尤其对于量大的情况下。欢迎加群一起学习交流 ~
从零开始学SpringBoot之SpringBoot WebSocket原理篇
前言：
这节我们介绍下WebSocket的原理。
一、websocket与http
WebSocket是HTML5出的协议，也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）
首先HTTP有 1.1 和 1.0 之说，也就是所谓的 keep-alive ，把多个HTTP请求合并为一个，但是 Websocket 其实是一个新协议，跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充，可以通过这样一张图理解：
有交集，但是并不是全部。
另外Html5指的是一系列新的API，或者说新规范，新技术。Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。通俗来说，你可以用HTTP协议传输非Html数据。
二、Websocket是什么样的协议，具体有什么优点
首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来说。
HTTP的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次HTTP请求就结束了。
在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。
跟Websocket有什么关系呢？
首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。
首先我们来看个典型的 Websocket 握手（借用Wikipedia的。。）
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin:
熟悉HTTP的童鞋可能发现了，这段类似HTTP协议的握手请求中，多了几个东西。我会顺便讲解下作用。
2.1 Upgrade 和Connection
Upgrade: websocket
Connection: Upgrade
这个就是Websocket的核心了，告诉 Apache 、Tomcat、 Nginx 等服务器：注意啦，我发起的是Websocket协议，快点帮我找到对应的助理处理~不是那个老土的HTTP。
2.2 Sec-WebSocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
首先， Sec-WebSocket-Key是一个 Base64 encode 的值，这个是浏览器随机生成的，告诉服务器：你妹，不要忽悠窝，我要验证尼是不是真的是Websocket助理。
然后， Sec_WebSocket-Protocol是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。简单理解：今晚我要服务A，别搞错啦~
最后， Sec-WebSocket-Version是告诉服务器所使用的 WebSocket Draft （协议版本），在最初的时候，Websocket协议还在 Draft 阶段，各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。。不过现在还好，已经定下来啦~大家都使用的一个东西~ 脱水：服务员，我要的是13岁的噢→_→
然后服务器会返回下列东西，表示已经接受到请求，成功建立Websocket啦！
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功切换协议啦~
Upgrade: websocket
Connection: Upgrade
依然是固定的，告诉客户端即将升级的是 Websocket 协议，而不是mozillasocket，lurnarsocket或者shitsocket。
然后， Sec-WebSocket-Accept这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key 。服务器：好啦好啦，知道啦，给你看我的ID CARD来证明行了吧。后面的， Sec-WebSocket-Protocol 则是表示最终使用的协议。
至此，HTTP已经完成它所有工作了，接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。
—————— 技术解析部分完毕 ——————
你说了这么久，那到底Websocket有什么鬼用， http long poll ，或者ajax轮询 不都可以实现实时信息传递么。
好好好，年轻人，那我们来讲一讲Websocket有什么用。来给你吃点胡（苏）萝（丹）卜（红）
三、Websocket的作用
在讲Websocket之前，我就顺带着讲下 long poll 和 ajax轮询 的原理。
3.1 ajax 轮询
ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
场景再现：
客户端：啦啦啦，有没有新信息(Request)
服务端：没有（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：没有。。（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：你好烦啊，没有啊。。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：好啦好啦，有啦给你。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：。。。。。没。。。。没。。。没有（Response） —- loop
3.1 长轮询（long poll）
long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
场景再现：
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）
服务端：额。。等待到有消息的时候。。来给你（Response）
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request） -loop
从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。
何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。
简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。
说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）
从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。
ajax轮询需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
所以 ajax轮询 和 long poll 都有可能发生这种情况。
客户端：啦啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 ServerUnavailable）
客户端：。。。。好吧，啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 ServerUnavailable）
客户端：然后服务端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我错了。。这又是梗。。）
3.2 WebSocket
通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。
一种需要更快的速度，一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高。
哦对了，忘记说了HTTP还是一个状态协议。
通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。
所以在这种情况下出现了，Websocket出现了。他解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP-Websocket），服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。
客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）
服务端：ok，确认，已升级为Websocket协议（HTTPProtocols Switched）
客户端：麻烦你有信息的时候推送给我噢。。
服务端：ok，有的时候会告诉你的。
服务端：balabalabalabala
服务端：balabalabalabala
服务端：哈哈哈哈哈啊哈哈哈哈
服务端：笑死我了哈哈哈哈哈哈哈
就变成了这样，只需要经过一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我傻乎乎的每次跑来问你）
这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢？
其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（PHP等）来处理。简单地说，我们有一个非常快速的 接线员（Nginx） ，他负责把问题转交给相应的 客服（Handler） 。
本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。，导致客服不够。Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。这样就可以解决客服处理速度过慢的问题了。
同时，在传统的方式上，要不断的建立，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。
虽然接线员很快速，但是每次都要听这么一堆，效率也会有所下降的，同时还得不断把这些信息转交给客服，不但浪费客服的处理时间，而且还会在网路传输中消耗过多的流量/时间。
但是Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。
同时由客户主动询问，转换为服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息过来的。。），没有信息的时候就交给接线员（Nginx），不需要占用本身速度就慢的客服（Handler）了
至于怎么在不支持Websocket的客户端上使用Websocket。。答案是：不能。但是可以通过上面说的 long poll 和 ajax 轮询 来 模拟出类似的效果
看完让你彻底搞懂Websocket原理
内容转自知乎：
如果觉得文字不过瘾，可以通过视频学习SpringBoot，这里给大家推荐
《从零开始学SpringBoot》视频教程链接：
【 Java全栈技术分享 】，Jacky。
04《Spring Boot 入门教程》使用模板引擎开发 Web 项目
模板引擎这个词，咋听起来，有点高大上的意味。
实际上，模板引擎是非常平易近人的技术。譬如大家可能都比较熟悉的 JSP ，就是一种比较典型的模板引擎。
当浏览器将请求抛给控制器，控制器处理好数据后，就跳转 JSP 等模板引擎页面。注意在跳转的同时，还会将数据组装好，也交给模板引擎处理。
模板引擎会根据数据，和模板引擎的规则，动态生成 HTML 页面，最后返回给浏览器显示。
我们使用 Spring Boot 开发 Web 项目，大体上有两种方式。
第一种方式，是后端服务化的方式，也是当前的主流方式。前端是静态的 HTML 页面，通过 Ajax 请求 Spring Boot 的后端接口。 Spring Boot 返回数据一般采用 JSON 格式，前端接收后将数据显示。
第二种方式，是采取模板引擎的方式。前端的请求，到达 Spring Boot 的控制器后，控制器处理请求，然后将返回数据交给模板引擎。模板引擎负责根据数据生成 HTML 页面，最后将 HTML 返回给浏览器。
我个人比较推荐第一种方式，说一下该方式的几个优点：
本篇是讲模板引擎，也得说说模板引擎的优点，王婆卖瓜不能光夸草莓啊。模板引擎开发的页面，对搜索引擎 SEO 比较友好；还有就是简单的页面，如果用模板引擎开发速度比较快，毕竟模板化的方法，目的就是减少重复提高效率。
Spring Boot 支持的模板引擎种类很多，常见的有 FreeMarker 、 Thymeleaf 、 JSP 。
因为这些模板引擎使用的用户都不少，所以我们逐一介绍下其实现过程。
至于孰优孰劣，请各位看官自行评价。正所谓：尺有所短，寸有所长，各取所爱，万物生长！
本篇我们开发一个商品浏览项目实例。
此处说一个我个人的经验：在做一个项目或一个模块的时候，不要一开始就动手写代码，最好是谋定而后动。
我们作为程序员，实际上是整个程序世界的总指挥。应该先整体规划，再实现局部。这种总分型的开发方法便于我们理顺思路，提高编码效率！
好的，我们来思考下，实现商品浏览项目实例的整体流程：
整体流程
可以看到，我们是先建立了控制器方法和页面，再去实现其中的具体细节。这样可以让我们的思维保持连贯性和整体性，在做一些页面和方法较多的项目时，会感觉更加顺畅。
我们按整体流程，使用 FreeMarker 模板引擎，来实现商品浏览功能。
使用 Spring Initializr 创建项目，Spring Boot 版本选择 2.2.5 ， Group 为 com.imooc ， Artifact 为 spring-boot-freemarker ，生成项目后导入 Eclipse 开发环境。
引入 Web 项目及 FreeMarker 模板相关的依赖项，代码如下：
实例：
创建控制器类，由于是商品相关的控制器，所以命名为 GoodsController ，代码如下：
实例：
我们具体解释下该类的作用。
我们 resource/templates 目录下新建商品页面 goods.ftl ，先不必实现具体功能，代码如下：
实例：
此时我们启动项目，然后访问 ，即可显示对应页面内容。
定义商品类 GoodsDo 用来描述商品信息，注意 Do 表示数据模型对象（Data Object），代码如下：
实例：
然后我们编写服务类 GoodsService ，提供获取商品列表的方法。注意此处仅仅是演示模板引擎，并不需要访问数据库，直接返回一个指定内容的商品列表。
实例：
此时，我们的控制器就可以注入 GoodsService 类型的组件，然后调用其方法了。
实例：
注意 model.addAttribute("goodsList", goodsService.getGoodsList()); ，我们将商品列表相关的数据交给模板引擎去处理。
此时我们可以根据 FreeMarker 模板引擎，按模板规则显示商品信息了。
实例：
注意我们通过 FreeMarker 的模板语法，输出了商品列表信息。关于 FreeMarker 模板引擎更多的语法规则，感兴趣的同学可以后续查阅更多资料。
启动项目，打开浏览器访问 ，即可查看输出结果。
Thymeleaf 和 FreeMarker ，都是模板引擎，使用方法基本类似。此处我们仅仅是给出一个范例，不再做过多的解释。
使用 Spring Initializr 创建项目， Spring Boot 版本选择 2.2.5 ， Group 为 com.imooc ， Artifact 为 spring-boot-thymeleaf ，生成项目后导入 Eclipse 开发环境。
引入 Web 项目及 Thymeleaf 模板相关的依赖项。
实例：
创建控制器类， GoodsController ， Thymeleaf 直接使用 HTML 作为模板页面，故代码如下：
实例：
我们在 resource/templates 目录下新建商品页面 goods.html ，先不必实现具体功能，代码如下：
实例：
此时我们启动项目，然后访问 ，即可显示对应页面内容。
商品类 GoodsDo ，服务类 GoodsService ，这两个类与上面没有区别直接放出代码。
实例：
实例：
好的，此时我们的控制器就可以注入 GoodsService 类型的组件，然后调用其方法了。
实例：
此时我们可以根据 Thymeleaf 模板引擎，按模板规则显示商品信息了。
实例：
注意我们通过 Thymeleaf 的模板语法，输出了商品列表信息。关于 Thymeleaf 模板引擎更多的语法规则，感兴趣的同学可以后续查阅更多资料。
启动项目，打开浏览器访问 ，即可查看输出结果。
到此，大家基本上也能发现，这两种方式除了模板页面文件内容不同，其他地方基本都是一模一样的。
也就是说，模板引擎主要负责通过一些模板标签，将控制器返回的数据解析为网页。
注意 Spring Boot 官方已经不推荐使用 JSP 了，确实操作起来也比较麻烦。但是由于 JSP 用户体量还是比较大的，所以此处还是简单演示下，开发步骤与 FreeMarker / Thymeleaf 基本一致。
使用 Spring Initializr 创建项目， Spring Boot 版本选择 2.2.5 ， Group 为 com.imooc ， Artifact 为 spring-boot-jsp ，生成项目后导入 Eclipse 开发环境。
引入 Web 项目及 JSP 模板相关的依赖项。
实例：
创建控制器类， GoodsController ，代码如下：
实例：
手工添加 src/main/webapp 及子目录如下，同时目录下放一个 goods.jsp 用于测试。注意该目录是一个 Source Folder 源代码目录，不是普通文件夹目录。
spring-boot-jsp 项目结构
实例：
注意，我们还需要添加一个视图解析器，实现 JSP 页面往指定目录跳转。
实例：
此时我们启动项目，然后访问 ，即可显示对应页面内容。
商品类 GoodsDo ，服务类 GoodsService ，这两个类与上面没有区别直接放出代码。
实例：
实例：
好的，此时我们的控制器就可以注入 GoodsService 类型的组件，然后调用其方法了。
实例：
此时我们可以根据 JSP 模板引擎，按模板规则显示商品信息了。
实例：
注意我们通过 JSP 的模板语法，输出了商品列表信息。关于 JSP 模板引擎更多的语法规则，感兴趣的同学可以后续查阅更多资料。
启动项目，打开浏览器访问 ，即可查看输出结果。
最后大家应该也发现了， FreeMarker 和 Thymeleaf 的用法几乎是一模一样的，而 JSP 还需要手工添加一些目录和配置。
三种方式各有优劣， FreeMarker 模板语法比较简洁， Thymeleaf 可以直接使用 HTML 作为模板文件， JSP 用户群体广泛。
但是三种方式，都是一种模板引擎而已，将控制器返回数据转化为 HTML 页面显示，本质上没啥区别，大家对模板引擎有一个了解即可。
学妹想学SpringBoot，连夜整理一篇SpringBoot入门最详细教程笔记
凭借开箱即用，远离繁琐的配置等特性，Spring Boot 已经成为 Java 开发者人人必学必会的开源项目。那么开发者该如何快速上手Spring Boot 呢？
那请问Spring Boot 到底是啥？Spring Boot是Spring框架的扩展和自动化，它消除了在Spring中需要进行的XML（EXtensible Markup Language）文件配置（若习惯XML配置，则依然可以使用），使得开发变得更快、更高效、更自动化。
微服务：每一个功能元素最终都是一个可独立替换和独立升级的软件单元。
在maven 的settings.xml配置文件的profiles标签添加以下配置：
把maven整合到idea。
项目目录：
HelloWorldMainApplication：
HelloController：
运行结果：
打开浏览器访问：
1、我们在pom.xml文件中假如以下代码：
2、然后，我们将应用打包
3、然后再target文件夹下就可以看到 spring-boot-01-helloworld-1.0-SNAPSHOT.jar
4、复制到桌面（随便哪，个人选择），打开cmd窗口，切换到jar包所在位置，我的是桌面，然后输入： java -jar spring-boot-01-helloworld-1.0-SNAPSHOT.jar ，运行效果如下。
5、打开浏览器访问：，同样可以看到HelloWord
这样的部署就变得十分简单了。
小伙伴们，帮忙一键三连呀
题外话，我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在Java学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多程序员朋友无法获得正确的资料得到学习提升
故此将并 将重要的Java进阶资料包括并发编程、JVM调优、SSM、设计模式、spring等知识技术、阿里面试题精编汇总、常见源码分析等录播视频免费分享出来，需要领取的麻烦 评论区领取
【springboot 入门篇】第3篇 从controller开始学起
在写web项目的时候，controller里的返回值一般分为两种，一种是返回页面，也就是ModeAndView，另一种是直接返回数据，比如json格式的数据。
返回一个页面，我们需要用到一些模板引擎，比如熟知的jsp，模板引擎后面会详细讲解。
返回数据一般会选择返回json数据，我们之前的demo项目中使用的@RestController就是一个返回数据的注解。
spring-boot 支持多种模版引擎包括：
我们在讲前后端分离之前，都会使用Thymeleaf模板引擎，先简单的介绍一下它。
Thymeleaf是一个java类库，它是一个xml/xhtml/html5的模板引擎，可以作为mvc的web应用的view层。
Thymeleaf还提供了额外的木块与spring mvc集成，所以使用ssm框架的也可以使用这个模板引擎。
接下来，我们通过一个项目，来实践一下两种不同的返回结果。
先看一下最终的目录结构：
这里我们使用了Thymeleaf模板引擎来获得后台传来的数据并解析，使用bootstrap框架显示数据。可以看到，Thymeleaf的用法和jsp还是有点像的。可以直接通过${}的形式来获得attribute中的数据。
可以看到，我们成功的在前端获取到了数据。方式就是将数据保存在attribute中，然后再前端页面获取。
我们修改了注解，发现结果变了，直接显示了“index”,是因为@RestController会直接返回数据，而不是渲染页面，所以直接返回了index(这个index，是return语句中的)
访问
获得了json格式的数据
访问
列表也可以直接渲染为json。
访问
访问
会发现这两个都报错了，因为@Controller注解是渲染视图的，而我们返回的是对象或者集合，不能完成正常的渲染。
本文主要讲解了spring boot 如何渲染视图和数据，讲解了@Controller和@RestController的区别与用法。如果有什么疑问，请及时联系我。
我之前写过一个重新认识java系类（还没写完，会写完的。。），篇幅很长，每一篇文章多的有7、8千字，和多人抱怨说看到一半就不想看了，因为太长了，所以 spring boot 这个系类会尽量的短小精悍，每篇文章只讲一个知识点，这样看着不累~