陈村网站开发广东智能网站建设配件公司

陈村网站开发,广东智能网站建设配件公司,网站建设汇报ppt,app开发定制外包22引言 彼时 SpringBoot 初兴#xff0c;万象更新#xff0c;号称“开箱即用”“约定优于配置”#xff0c;一时间风靡四方。 开发者趋之若鹜#xff0c;纷纷称快#xff0c;仿佛自此架构之重可卸、配置之繁可省#xff0c;一行 main() 即可气定神闲、纵横沙场。 然则时…引言彼时 SpringBoot 初兴万象更新号称“开箱即用”“约定优于配置”一时间风靡四方。开发者趋之若鹜纷纷称快仿佛自此架构之重可卸、配置之繁可省一行main()即可气定神闲、纵横沙场。然则时光久远方知此言非虚却也未尽其真。所谓默认不过是你未曾开口框架自作主张。表面无碍实则步步杀机线上事故十有八九皆因“未曾配置”的“默认”。回首往昔实堪自嘲。曾自诩熟稔底层、精通原理然于这些藏于阴影处的默认设定竟茫然不觉。故障一起仓皇失措耗时良久方才发现不过是框架做了一个并不适合的决定。是以今日提笔将过往种种记录于此只盼后来者少走弯路。正文Tomcat连接池SpringBoot默认使用Tomcat作为Web容器但默认的连接池配置在高并发场景下会成为瓶颈。默认配置下Tomcat的最大连接数只有200最大线程数也只有200。这意味着当并发请求超过200时后续请求就会排队等待。在生产环境中这个配置明显不够用。server: tomcat: max-connections:10000 # 最大连接数 threads: max:800 # 最大工作线程数 min-spare:100 # 最小空闲线程数 accept-count:100 # 等待队列长度 connection-timeout:20000更坑的是SpringBoot的默认超时时间是无限长。这会导致连接一直占用直到客户端主动断开。在网络不稳定的环境下大量连接会一直挂着不释放最终耗尽服务器资源。数据库连接池SpringBoot默认使用HikariCP作为数据库连接池但默认的连接池配置在生产环境下会成为瓶颈。默认最大连接数只有10个对于稍微复杂一点的应用来说根本不够用。spring: datasource: hikari: maximum-pool-size:50 minimum-idle:10 connection-timeout:30000 idle-timeout:600000 max-lifetime:1800000 leak-detection-threshold:60000特别要注意leak-detection-threshold这个配置。默认情况下这个检测是关闭的如果代码中存在连接泄漏问题根本发现不了。开启后HikariCP会监控连接的使用时间超过阈值就会打印警告日志。JPA懒加载SpringBoot集成JPA时默认开启了懒加载。这个设计初衷是好的但在实际使用中经常会导致N1查询问题。Entity publicclassUser { Id private Long id; OneToMany(fetch FetchType.LAZY) // 默认就是LAZY private ListOrder orders; }当查询用户列表时每访问一次orders属性就会触发一次数据库查询。如果有100个用户就会执行101次SQL。这种情况下要么使用EntityGraph指定加载策略要么在Repository中使用JOIN FETCH。Query(SELECT u FROM User u LEFT JOIN FETCH u.orders) ListUser findAllWithOrders();Jackson时区序列化SpringBoot默认使用Jackson处理JSON序列化但时区处理经常出问题。默认情况下Jackson会使用系统时区这在分布式部署时会导致不一致的问题。spring: jackson: time-zone:GMT8 date-format:yyyy-MM-ddHH:mm:ss serialization: write-dates-as-timestamps:false更要命的是如果你的应用部署在不同时区的服务器上同样的时间可能会被序列化成不同的值。这个问题在国际化应用中特别突出。日志配置SpringBoot默认使用Logback但默认配置下没有对日志文件进行滚动和清理。长时间运行的应用会产生巨大的日志文件最终占满磁盘空间。logging: file: name:app.log logback: rollingpolicy: max-file-size:100MB max-history:30 total-size-cap:3GB另外默认的日志级别是INFO在生产环境中会产生大量不必要的日志。合理设置日志级别可以显著提升性能。缓存配置SpringBoot的Cacheable注解默认使用ConcurrentHashMap作为缓存实现但这个实现没有过期机制也没有大小限制。在高并发场景下缓存会无限增长最终导致内存溢出。spring: cache: type:caffeine caffeine: spec:maximumSize10000,expireAfterWrite600s可以考虑使用Caffeine替代默认实现可以提供更好的性能和内存管理能力。监控端点SpringBoot Actuator默认暴露了很多监控端点包括健康检查、配置信息、环境变量等。这些信息在开发环境中很有用但在生产环境中可能泄漏敏感信息。management: endpoints: web: exposure: include:health,info,metrics endpoint: health: show-details:when-authorized只暴露必要的端点并且配置适当的安全策略避免信息泄漏。文件上传大小限制SpringBoot默认的文件上传限制非常小单个文件只能上传1MB整个请求大小限制10MB。在实际业务中这个限制经常不够用用户上传稍大一点的文件就会报错。这个属于是比较常见的问题因为开发环境测试时通常用小文件一切正常。等到用户上传几MB的PDF文档或者高清图片时系统就开始报MaxUploadSizeExceededException异常。这个异常往往还发生在文件传输完成之后用户等了半天上传完毕结果被告知文件过大体验极差。spring: servlet: multipart: max-file-size:100MB max-request-size:100MB file-size-threshold:2KB location:/tmp resolve-lazily:falsefile-size-threshold这个参数也很重要它决定了多大的文件会直接写入内存。如果设置过大大量并发上传会占用过多内存设置过小小文件也要写磁盘影响性能。一般设置为几KB比较合适。异步线程池配置使用Async注解时SpringBoot默认使用SimpleAsyncTaskExecutor这个执行器每次都会创建新线程没有线程池复用机制。高并发情况下会创建大量线程最终导致系统资源耗尽。这个问题在开发阶段很难发现因为异步任务通常不多。但在生产环境如果有大量异步任务执行比如发送短信、推送、记录日志等系统会不断创建新线程。每个线程默认占用1MB的栈空间创建几千个线程就是几GB内存。更严重的是线程切换的开销CPU大部分时间都在做上下文切换真正的业务逻辑反而执行很慢。spring: task: execution: pool: core-size:8 max-size:16 queue-capacity:100 keep-alive:60s thread-name-prefix:async-task- scheduling: pool: size:4 thread-name-prefix:scheduling-线程池大小的设置也有讲究。如果是CPU密集型任务线程数设置为CPU核心数就够了如果是IO密集型任务可以设置为CPU核心数的2-3倍。queue-capacity设置了任务队列长度当线程池满了之后新任务会放到队列里等待执行。静态资源缓存策略SpringBoot默认不为静态资源设置HTTP缓存头这意味着浏览器每次都会重新请求CSS、JS、图片等静态文件严重影响页面加载性能。用户每次访问页面浏览器都要重新下载所有静态资源即使这些文件根本没有变化。对于资源较多的单页应用来说这个问题特别明显。用户看到的就是页面加载慢特别是网络条件不好的时候体验很差。spring: web: resources: cache: cachecontrol: max-age:365d cache-public:true chain: strategy: content: enabled:true paths:/** cache:true static-locations:classpath:/static/开启内容版本化策略后SpringBoot会根据文件内容生成MD5哈希值作为版本号文件名变成style-abc123.css这样的格式。当文件内容发生变化时哈希值也会变化浏览器会认为这是新文件重新下载如果文件没变化浏览器就直接使用缓存有效提升页面加载速度。数据库事务超时Transactional注解默认没有设置超时时间长时间运行的事务会一直持有数据库锁影响其他操作的执行。特别是在批量数据处理时很容易出现锁表问题。这个问题在并发量不高的时候不明显但随着业务增长长事务的危害就暴露出来了。比如一个数据导入任务需要处理几万条记录如果放在一个事务里可能要运行几分钟甚至更长时间。在这期间相关的表都被锁住其他用户的操作只能等待系统响应变得很慢。Transactional(timeout 30, rollbackFor Exception.class) publicvoidbatchProcess(ListData dataList) { // 分批处理避免长事务 intbatchSize100; for (inti0; i dataList.size(); i batchSize) { ListData batch dataList.subList(i, Math.min(i batchSize, dataList.size())); processBatch(batch); } }对于大批量数据处理建议分成多个小事务每个事务处理少量数据。这样即使某个小事务失败也不会影响整体进度而且可以及时释放数据库锁提高系统并发性能。同时再加上rollbackFor Exception.class确保所有异常都会触发回滚避免数据不一致。写在最后Spring Boot 的“约定优于配置”确实省心但省的是开发者的心不是系统的责任。每一项默认配置背后其实都藏着设计者的假设和权衡而这些假设在我们的业务场景中也许未必成立。这些坑我几乎都踩过有些甚至反复踩了好几次。愿你读到这里能少走几步弯路可不能拿生产事故去交学费。提前优化配置是对系统负责也是对自己负责。