java springboot对战平台 java与springboot

Spring Boot 优缺点

    优点：

• SpringBoot继承了spring的优良基因，是为了更方便的搭建spring框架。
• 简化依赖：Spring使用时需要在pom中添加很多依赖，而在springboot中只需要在pom中添加一个starte-web依赖。
• 简化配置：Spring中很多xml和annotation，springboot中用的更多的是java config的方式进行配置。
• 简化部署：在使用 Spring 时，项目部署需要我们在服务器上部署 tomcat，然后把项目打成 war 包扔到 tomcat里，在使用 Spring Boot 后，我们不需要在服务器上去部署 tomcat，因为 Spring Boot 内嵌了 tomcat，我们只需要将项目打成 jar 包，使用 java -jar xxx.jar一键式启动项目。

    缺点：

• Spring Boot作为一个微框架，离微服务的实现还是有距离的。springboot 只是为了提高开发效率，是为了提升生产力的。 没有提供相应的服务发现和注册的配套功能，自身的acturator所提供的监控功能，也需要与现有的监控对接。没有配套的安全管控方案，对于REST的落地，还需要自行结合实际进行URI的规范化工作。
• 将现有或传统的Spring Framework项目转换为Spring Boot应用程序是一个非常困难和耗时的过程。它仅适用于全新Spring项目。

Bean 的生命周期

• Spring对bean进行实例化，默认bean是单例。
• Spring对bean进行依赖注入。
• 此时bean已经准备就绪，可以被应用程序使用了，他们将一直驻留在应用上下文中，直到该应用上下文被销毁。
• 若bean实现了DisposableBean接口，spring将调用它的distroy()接口方法。同样的，如果bean使用了destroy-method属性声明了销毁方法，则该方法被调用。

事务：哪些配置方式，什么情况下会失效？

    配置方式：

• 编程式事务：就是直接在代码里手动开启事务，手动提交，手动回滚。优点就是可以灵活控制，缺点就是太麻烦了，太多重复的代码了。
• 声明式事务：就是使用SpringAop配置事务，这种方式大大的简化了编码。需要注意的是切入点表达式一定要写正确。
• 注解事务：直接在Service层的方法上面加上 @Transactional 注解，个人比较喜欢用这种方式。

    失效情况：

• 声明式事务配置切入点表达式写错了，没切中Service中的方法
• Service方法中，把异常给try catch了，但catch里面只是打印了异常信息，没有手动抛出 RuntimeException异常
• Service方法中，抛出的异常不属于运行时异常（如IO异常），因为Spring默认情况下是 捕获到运行时异常就回滚

解决办法：

• 如果采用声明式事务，一定要确保切入点表达式书写正确
• 如果Service层会抛出不属于运行时异常也要能回滚，那么可以将Spring默认的回滚时的异常修改为Exception，这样就可以保证碰到什么异常都可以回滚。
• 只有非只读事务才能回滚的，只读事务是不会回滚的( 一次执行多次查询来统计某些信息，这时为了保证数据整体的一致性，要用只读事务 )
• 如果在Service层用了try catch，在catch里面再抛出一个 RuntimeException异常，这样出了异常才会回滚，或者 在catch后面写一句回滚代码（TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();）来实现回滚，这样的话，就可以在抛异常后也能return 返回值，比较适合需要拿到Service层的返回值的场景。

mybatis和hibernate的区别

• Mybatis和hibernate不同，它不完全是一个ORM框架，因为MyBatis需要程序员自己编写Sql语句，不过mybatis可以通过XML或注解方式灵活配置要运行的sql语句，并将java对象和sql语句映射生成最终执行的sql，最后将sql执行的结果再映射生成java对象。
• Mybatis学习门槛低，简单易学，程序员直接编写原生态sql，可严格控制sql执行性能，灵活度高，非常适合对关系数据模型要求不高的软件开发，例如互联网软件、企业运营类软件等，因为这类软件需求变化频繁，一但需求变化要求成果输出迅速。但是灵活的前提是mybatis无法做到数据库无关性，如果需要实现支持多种数据库的软件则需要自定义多套sql映射文件，工作量大。
• Hibernate对象/关系映射能力强，数据库无关性好，对于关系模型要求高的软件（例如需求固定的定制化软件）如果用hibernate开发可以节省很多代码，提高效率。但是Hibernate的缺点是学习门槛高，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡，以及怎样用好Hibernate需要具有很强的经验和能力才行。

MySQL 

    1.索引类型

• 默认的BTREE类型的索引。
• 索引列的值必须唯一，但允许有空值（注意和主键不同）。如果是组合索引，则列值的组合必须唯一，创建方法和普通索引类似。
• 主键索引，只能有一个，不能为空。
• 全文索引，查找关键字。
• 单列索引、多列索引。
• 组合索引（最左前缀）：指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合。

    2.事务

   事务的基本要素（ACID）

• 原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
• 一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。
• 隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
• 持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。

    事务的并发问题

• 脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据。
• 不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。
• 幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。
• 小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。

    事务的隔离级别

事务隔离级别	脏读	不可重复读	幻读
读未提交（read-uncommitted）	是	是	是
不可重复读（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

• mysql默认的事务隔离级别为可重复读（repeatable-read）
• 读未提交：写数据只会锁住相应的行
• 可重复读：如果检索条件有索引（包括主键索引）的时候，默认加锁方式是next-key 锁；如果检索条件没有索引，更新数据时会锁住整张表。一个间隙被事务加了锁，其他事务是不能在这个间隙插入记录的，这样可以防止幻读。
• 串行化：读写数据都会锁住整张表
• 隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。

    3.怎么防止SQL注入，排序变量使用#还是$，为什么

• 查询参数全部使用#,排序变量只能使用$。
• #相当于对数据加上双引号，$相当于直接显示数据，接受从用户输出的内容并提供给语句中不变的字符串，这样做是不安全的。这会导致潜在的SQL注入攻击，因此你不应该允许用户输入这些字段，或者通常自行转义并检查。
• #{}是经过预编译的，是安全的；${}是未经过预编译的，仅仅是取变量的值，是非安全的，存在SQL注入.如果我们order by语句后用了${}，那么不做任何处理的时候是存在SQL注入危险的。你说怎么防止，那我只能悲惨的告诉你，你得手动处理过滤一下输入的内容。如判断一下输入的参数的长度是否正常（注入语句一般很长）。