解决：javax.websocket.server.ServerContainer not available 报错问题

错误截图

原因：

用于扫描带有 @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