错误截图
原因:
用于扫描带有 @ServerEndpoint 的注解成为 websocket
,该方法是 服务器端点出口,当进行 SpringBoot 单元测试时,并没有启动服务器,所以当加载到这个bean时会报错。
解决方法:
加上这个注解内容
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@SpringBootTest
@SpringBootTest
是 Spring Boot 测试中的一个注解,用于启动 Spring 应用程序的上下文以进行集成测试。这个注解提供了一种方便的方式来加载应用程序的整个上下文,并提供了多种配置选项以适应不同的测试场景。
在你提供的示例中,@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
表示你想要在随机端口上启动应用程序的 Web 环境进行测试。这样做的好处是可以避免端口冲突,因为每次测试都会在不同的随机端口上启动应用程序。
让我解释一下其中的一些关键点:
-
@SpringBootTest
: 这个注解告诉 Spring Boot 测试框架启动整个 Spring 应用程序的上下文。它会尝试加载应用程序的所有配置,并创建应用程序的上下文,使得你可以在测试中访问 Spring Beans 和其他应用程序组件。 -
webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT
: 这是@SpringBootTest
注解的一个参数,用于指定要使用的 Web 环境。在这种情况下,RANDOM_PORT
表示你想要在随机端口上启动应用程序的 Web 环境进行测试。这样做可以避免端口冲突,因为每次测试都会使用不同的随机端口。
除了 RANDOM_PORT
,@SpringBootTest
还支持其他的 webEnvironment
参数,例如:
-
MOCK
: 这个选项会启动一个模拟的 Servlet 环境,而不是真正的 Web 服务器。这种情况下,测试将在一个虚拟的 Servlet 环境中执行,不会启动真正的 Web 服务器。 -
DEFINED_PORT
: 这个选项会使用应用程序配置中定义的端口启动 Web 环境。这对于在已知端口上运行测试很有用,但在并行测试中可能会导致端口冲突。
总的来说,@SpringBootTest
注解是 Spring Boot 测试中的一个核心注解,它提供了启动应用程序上下文的能力,并提供了多种配置选项以适应不同的测试场景。
分太低了,复制一份增加分数!!!.
同样的功能,两种写法,但是结果并不是相同的。
首先,第一种是一个非静态匿名内部类,这样的一个类它会在编译期额外定义一个类,这个类的每个实例都将会持有外部实例的强引用。
这样的结果就会导致,如果这个匿名类的实例没有被销毁,那么外部类的实例也不能够被销毁,于是就有可能发生内存泄漏,比如当某Handler持有Activity的强引用并且没有被GC回收时,结果导致Activity即使destroy之后也不能被GC回收,这就是一种典型的内存泄漏的场景。
而对于上面这个lambda来说,由于它并没有捕获this,因此它并不会持有this的引用,即使经过了Desuger,仍旧不会捕获this的强引用,所以不会因此而发生内存泄漏。
其次,对于上面这种情况来说,由于没有任何变量需要被捕获,因此每次调用实际上根本没有必要重复创建新的对象,而用lambda就可以做到这一点,上面这个lambda每次返回的都是同一个实例的引用。
最后,相比起以上两条来说,这一条显得无关紧要。由于匿名类也是类,所以它经过编译后也要有自己的class文件,而在每个class文件中的常量表都会占据相当一部分空间,而如果是用lambda代替匿名类,则不会在编译期生成这些class文件,于是二进制文件占据的空间会稍微减少,不过如果是在android开发中,这种区别将会变得更加微不足道,因为dex已经为了这种情况而节省了大量的空间出来,dex数量远远小于class数量因此常量表也会被更多地复用,所以lambda与匿名类在包大小上的区别实际并不明显。
————————————————
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/m0_62645012/article/details/133916344
同样的功能,两种写法,但是结果并不是相同的。
首先,第一种是一个非静态匿名内部类,这样的一个类它会在编译期额外定义一个类,这个类的每个实例都将会持有外部实例的强引用。
这样的结果就会导致,如果这个匿名类的实例没有被销毁,那么外部类的实例也不能够被销毁,于是就有可能发生内存泄漏,比如当某Handler持有Activity的强引用并且没有被GC回收时,结果导致Activity即使destroy之后也不能被GC回收,这就是一种典型的内存泄漏的场景。
而对于上面这个lambda来说,由于它并没有捕获this,因此它并不会持有this的引用,即使经过了Desuger,仍旧不会捕获this的强引用,所以不会因此而发生内存泄漏。
其次,对于上面这种情况来说,由于没有任何变量需要被捕获,因此每次调用实际上根本没有必要重复创建新的对象,而用lambda就可以做到这一点,上面这个lambda每次返回的都是同一个实例的引用。
最后,相比起以上两条来说,这一条显得无关紧要。由于匿名类也是类,所以它经过编译后也要有自己的class文件,而在每个class文件中的常量表都会占据相当一部分空间,而如果是用lambda代替匿名类,则不会在编译期生成这些class文件,于是二进制文件占据的空间会稍微减少,不过如果是在android开发中,这种区别将会变得更加微不足道,因为dex已经为了这种情况而节省了大量的空间出来,dex数量远远小于class数量因此常量表也会被更多地复用,所以lambda与匿名类在包大小上的区别实际并不明显。
————————————————
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/m0_62645012/article/details/133916344