<返回更多

说说我为什么开始放弃 Spring Framework

2023-06-28  今日头条  台近秋
加入收藏

作为一个 JAVA 开发 ,Spring 是我用的最多的框架。Spring 这个名字起的很好,一语双关,在英文里 spring 是春天的意思,寓意程序员的春天,同时 spring 还有弹簧的意思,它确实是一个有弹性的框架,扩展性很强。

类型约束

提到 spring ,首先想到的就是 ioc 和 aop 了,这些动态技术都是魔法,能自动管理,能增强代码。但是动态技术也带来了新的问题,Java 本来是个静态语言,有很强的类型约束,却被动态技术打破了。

@Cacheable(value = "userCache", key = "#corpId + #id") 
public User findUserByCorpIdAndId(String corpId,String id){}

比如上面的代码,我们可以使用 SpEL(Spring Expression Language)写一些简单的逻辑来构建 key,但是 SpEL 是没有类型约束的,编译没有检查,一般的 IDE 也没有提示(Idea旗舰版有做支持)。Spring 框架在很多地方都是支持 SpEL 的,但是总是手写这些字符串,很危险。我就犯过错误,写错了变量名但是程序仍然可以运行,只是参数拼上去总是 null,导致不同的参数拿到的缓存数据总是相同的。使用 api 的形式可以避免这样的问题,但是便利性就下降了。

复杂度太高

Spring 可以说是很好的践行了面向接口和面向对象编程,以致于继承和依赖关系复杂到让人叹为观止。对于 Spring 的源代码我是不建议去读的,因为复杂看很久没有头绪,方法跳了很久也没有到真正的实现,由于大量应用了动态字节码技术,有很多生成代码的代码,极为繁琐。原理了解下即可,花太多时间去读源码,收益不大。不过对于一个框架来说,要解决复杂问题,自身也必然复杂。但是如果一旦遇到报错要排查,或者调试代码就很头大了。

随着生态的发展,Spring 已经是一个非常庞大的框架,学习曲线比较陡峭,需要一定的学习成本才能熟练使用,要掌握它是非常困难的。也因此发展出了 Spring 八股文,大量的相关面试题攻略出现在互联网上。

资源占用高性能差

Spring 是一个 Bean 容器,可以让我们避免过多的创建对象,由 Spring 来管理,还可以自动注入我们需要的对象实例。但是,Bean 的管理也是需要成本的,在启动阶段就要扫描所有的包或配置文件来读取配置的 Bean,完成 Bean 的实例化再进行依赖注入和初始化,这就导致了规模一大启动时间就会很长,而且一开始就占用大量的内存空间来存储实例。而框架内部大量使用反射,也会降低运行时的性能。

根据我个人的经验,一个中等规模的 Spring Boot 项目至少需要 1G 的内存。部署一个 Spring Boot 实例耗费的内存至少可以部署五六个 vert.x 实例。我负责的部分项目启动时间最长的已经来到了1分半。

不可靠性

Spring 使用了大量的动态技术,动态技术来带来了很多坑,这些坑甚至还成为了经典面试题,比如“spring事务失效的12种场景”。有坑是常见的,大部分时候解决问题的方案也会带来新的问题。但是 spring 的坑有点多,不光是事务,凡是申明式注解,都会有不生效的问题,有时候不生效很难察觉,测试也不容易测出来,比如缓存和校验,没有生效结果也很可能是对的。也因此,有些公司的规范里是禁止使用申明式事务的。你可能会说经验多了就好了,多注意点,老虎也有打盹的时候,何况开发人员工作强度那么大,心中难免会不踏实。

不可否认的是动态技术带来了便利,假如我们想加代码,可以不用修改原来的逻辑,单独写 aop 拦截逻辑就可以了。但是,这样也带来了很多不确定性,一段方法执行了哪些逻辑,我们可能并不知道。aop 技术还是尽量要少用的,写的多了自己也忘记加过什么东西,将来接手项目的人可能要叫苦了。Spring Boot 的自动配置还有可能带来安全问题,依赖的 jar 包如果有恶意代码,是可以通过自动配置直接在启动阶段执行的。

反思

Spring 并不完美,动态字节码技术也许不是好的解决方案,ioc 和容器技术不是必须的,这套方案只是在 Java 中比较流行而已。动态技术提升了静态语言的灵活性,同时又失去了静态语言的严谨,编译期很多错误都检查不出来,只有跑起来了才能知道。

虽然 ioc 降低了耦合性,但是我觉得并不是必须的,现实是我们的代码常常没有多实现,不需要无缝替换,也没有必要热插拨。大项目为了保险起见能跑就行,也不敢切换实现,更高一层的抽象还会导致失去部分原生特性,过渡设计也会增加程序的复杂度,不要总是面向对象和面对接口。

总结

我不反对使用 Spring ,毕竟对于这么有影响力的框架,如果团队达不成一致,用它可以减少争议,大家都服气。但是,我已经不想再用了,探索别的方案对于我来说更有吸引力。

没有必要始终如一的使用一个框架,更没有必要死磕一种语言,Java 确实有很多不便之处,这个我们要承认,但是动态字节码和代理技术不是良药。多了解下其它的语言,开阔下视野很有必要,有时候格局就这样打开了。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>