项目问题汇总(持续更新中)
项目问题汇总(持续更新中)
DreamCollector项目遇到的问题:
持续记录日常踩坑,希望
大家自己踩一遍能帮大家少走弯路
Java篇
1. target中无自定义路径的xml文件
项目目录参考
解决方法
1、在pom.xml中放行mapper.xml,在Maven的build中加入以下配置
1 | <build> |
2、配置application.properties文件
1 | #配置mybatis-plus的xml路径 |
3、maven选择clean和campile重新编译即可
4、成功生成xml
2. 多模块找不到配置属性
报错参考
1 | *************************** |
原因
1、SpringBoot启动的时候默认会在以下5个路径下找配置文件
- 项目路径例子:
1 | springboot |
- 优先级由上往下递减
1 | file:./config/ [项目根目录下的config目录] |
2、多模块项目启动时会去匹配当前模块的根目录路径
解决方法
1、启动模块下添加application.properties文件
2、若多模块下公用一个配置文件,可以用spring.profiles.active指定公共配置文件
多模块项目路径例子:
1
2
3
4
5
6
7
8
9
10
11
12
13springboot
┠.idea
┠dream-admin(后台启动模块)
┠main
┠java
┠resources
#application.properties
┠dream-core(核心模块)
┠main
┠java
┠resources
#application-common.properties
┠pom.xmapplication.properties:
1
spring.profiles.active=common
application-common.properties:
1
2
3
4
5
6
7
8
9spring.datasource.url=jdbc:mysql://127.0.0.1:3306/dream?characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
spring.datasource.username=root
spring.datasource.password=123456
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
#spring.datasource.driver-class-name=com.mysql.jdbc.Driver
server.port=80
mybatis-plus.mapper-locations=classpath*:dc/common/mapper/**Mapper.xml
3、配置完后用maven的插件compile一下
3. 多模块找不到主类
报错参考
原因
一旦spring-boot-maven-plugin被包含到pomm .xml中,通过使用spring-boot:repackage目标,它会自动尝试重写归档文件,使它们可执行,当启动类找不到时会去找第一个启动方法
解决方法
1、将父类pom.xml删除spring-boot-maven-plugin相关
1 | <!--一旦spring-boot-maven-plugin被包含到pomm .xml中,通过使用spring-boot:repackage目标,它会自动尝试重写归档文件,使它们可执行--> |
2、在启动的模块下的pom.xml添加spring-boot-maven-plugin相关
1 | <plugins> |
4. jar包配置SSL失败
配置参考
我的SpringBoot依赖配置
1 | springboot <version>2.1.9</version> |
yaml配置(SSL证书是阿里云免费申请的.jks文件默认放Resources目录下即可)
1 | server: |
若本地调试提示端口占用问题
1 | netstat -ano|find "443" #查找进程状态为LISTENING的进程 |
解决方法
1、cmd 中查找占用端口的进程并结束进程
1 | netstat -ano|find "443" #查找进程状态为LISTENING的进程# |
2、若本地调试运行正常但打包jar包后报错,可尝试将springboot版本降低到 2.1.8
5. 获取webp后缀图片尺寸失败
代码参考
如果在线图片是webp后缀的图片都获取不到图片尺寸
1 | public static void main(String[] args) throws IOException { |
原因
标准的
javax.imageio.ImageIO
不支持读取 WebP 格式的图片,ImageIO
支持读写的文件后缀:jpg
、bmp
、gif
、png
、wbmp
、jpeg
,通过以下代码可以查看:
1 | System.out.println("ImageIO支读取的文件后缀:" + String.join(",", ImageIO.getReaderFileSuffixes())); |
解决方法
新增
webp-imageio
三方扩展库依赖来支持webp后缀图片
1 | <!-- https://mvnrepository.com/artifact/org.sejda.imageio/webp-imageio --> |
6. Scheduled
定时任务没有按时执行
前提是排除没有开启定时任务
@EnableScheduling
,能正常的执行定时任务的哈
代码参考
1 | public class TestTask { |
原因
默认情况下,Spring的
@Scheduled
注解是串行执行的,即任务是在单线程中执行的。如果上一次的任务还未完成,下一次任务将等待上一次任务完成后执行。在这个等待的过程中,如果首次任务的执行时间超过了1分钟,就会导致主线程第二次的任务重复执行;如果有多个定时任务时,时间挨得比较近,其中一个耗时比较长就会影响其他的定时任务,导致主线程第二次的任务迟迟不会执行
解决方法
方案1:将默认的Scheduled改为多线程的模式
1 |
|
方案2:开启异步调用
@EnableAsync
,并使用@Async
注解开启异步操作,但是@Async
有安全隐患
1 | public class TestTask { |
方案3:比较建议
方案1
加上再加上方案3
一起,多线程+锁防止不同线程重复操作同一批数据,这里用Redisson
的锁做示范
1 | public class TestTask { |
Mysql篇
1. 修改全文索引命中最小长度无效
SQL参考
查询漫画来源为
manga
,并且comic_name
、comic_intro
、author_name
字段中包含Sta
的数据,若查询包含Stag
的数据则可以正常查询出来(前提:已经把索引的最小长度修改成功并重启服务,只是查询不命中)
1 | SELECT |
原因
由于Mysql的全文搜索默认是在自然MySQL的全文搜索默认在自然语言模式下工作,它可能会忽略某些单词,尤其是那些被认为是“常见”的或“不重要”的单词。即使你已经将innodb_ft_min_token_size’设置为1,Sta’这样的短词可能仍然被忽略。这是因为MySQL可能认为它是一个常见的词前缀
解决方法
使用布尔搜索模式,
+
和*
不可忽略
1 | SELECT |
完整流程
1、修改mysql根目录下的
my.ini
配置文件,添加以下配置
1 | [mysqld] |
2、重启mysql服务
3、SQL查询修改是否生效,
%
内换成对应存储引擎下的配置
1 | SHOW GLOBAL VARIABLES LIKE '%min_token_size%' |
4、新建
Fulltext
全文索引,若已存在则需删除重建索引
需确保覆盖到要全文索引的字段
5、用布尔搜索模式
1 | MATCH (comic_name, comic_intro, author_name) AGAINST ('+Sta*' IN BOOLEAN MODE) |
2. order by
+limit
数据重复出现
SQL参考
前提:
publish_at
没有任何索引,为了更直观的比较第一页跟第二页重复的数据可以用INTERSECT
关键字将两条sql所查询出来的数据做并集(只有当数据总量足够多的时候分页才可能会出现重复出现数据,而且INTERSECT
关键字得看具体Mysql版本)
1 | #1.根据发布时间降序的第一页,每页30条数据 |
原因
order by
+limit
时Mysql会进行优化,使用的是内存中的filesort
文件排序,in memory filesort 使用的是优先级队列(priority queue),优先级队列使用的二叉堆。使用priority queue
的目的,就是在不能使用索引有序性的时候,如果要排序,并且使用了limit n,那么只需要在排序的过程中,保留n条记录即可这样虽然不能解决所有记录都需要排序的开销,但是只需要 sort buffer 少量的内存就可以完成排序。因此,在limit n时,只会堆排序前n个,且是不稳定排序,因此并不能保证字段值相同时的相对顺序,因此分页时可能造成重复;MySQL 5.5 没有这个优化,所以也就不会出现这个问题,5.6版本之后才出现了这种情况
官方描述:如果多行在列中具有相同的值
ORDER BY
,则服务器可以自由地以任何顺序返回这些行,并且可以根据整体执行计划以不同的方式返回这些行。换句话说,这些行的排序顺序相对于无序列来说是不确定的。影响执行计划的因素之一是LIMIT
,因此ORDER BY
带有和不带有 的查询LIMIT
可能会以不同的顺序返回行。
解决方法
在
ORDER BY
子句中包含其他列以使顺序具有确定性,例如id
为主键具有唯一性,又或者ORDER BY
的字段拥有索引
1 | #1.加入`id`字段确保顺序唯一 |