Spring 常犯的十大错误，这坑你踩过吗？( 二 ) _Spring

考虑一个包含各种配置文件、服务和控制器的 Spring 项目。在命名时保持语义上的一致性，可以创建一个易于搜索的结构，任何新的开发人员都可以按照自己的方式管理代码；例如，将 Config 后缀添加到配置类，服务层以 Service 结尾，以及控制器用 Controller 结尾。
与一致性主题密切相关，服务器端的错误处理值得特别强调。如果你曾经不得不处理编写很差的 API 的异常响应，那你可能知道原因 —— 正确解析异常会是一件痛苦的事情，而确定这些异常最初发生的原因则更为痛苦。
作为一名 API 开发者，理想情况下你希望覆盖所有面向用户的端点，并将他们转换为常见的错误格式。这通常意味着有一个通用的错误代码和描述，而不是逃避解决问题：a) 返回一个 “500 Internal Server Error”信息。b) 直接返回异常的堆栈信息给用户。（实际上，这些都应该不惜一切代价地去避免，因为除了客户端难以处理以外，它还暴露了你的内部信息）。
【Spring 常犯的十大错误，这坑你踩过吗？】例如，常见错误响应格式可能长这样：

文章插图

与此类似的事情在大多数流行的 API 中也经常遇到，由于可以容易且系统地记录，效果往往很不错。将异常转换为这种格式可以通过向方法提供 @ExceptionHandler 注解来完成（注解案例可见于第六章）。
5. 错误五：多线程处理不当
不管是桌面应用还是 Web 应用，无论是 Spring 还是 No Spring，多线程都是很难破解的。由并行执行程序所引起的问题是令人毛骨悚然且难以捉摸的，而且常常难以调试 —— 实际上，由于问题的本质，一旦你意识到你正在处理一个并行执行问题，你可能就不得不完全放弃调试器了，并 “手动” 检查代码，直到找到根本上的错误原因。
不幸的是，这类问题并没有千篇一律的解决方案；根据具体场景来评估情况，然后从你认为最好的角度来解决问题。
当然，理想情况下，你也希望完全避免多线程错误。同样，不存在那种一刀切的方法，但这有一些调试和防止多线程错误的实际考虑因素：
5.1. 避免全局状态
首先，牢记 “全局状态” 问题。如果你正创建一个多线程应用，那么应该密切关注任何可能全局修改的内容，如果可能的话，将他们全部删掉。如果某个全局变量有必须保持可修改的原因，请仔细使用 synchronization，并对程序性能进行跟踪，以确定没有因为新引入的等待时间而导致系统性能降低。
5.2. 避免可变性
这点直接来自于函数式编程，并且适用于 OOP，声明应该避免类和状态的改变。简而言之，这意味着放弃 setter 方法，并在所有模型类上拥有私有的 final 字段。它们的值唯一发生变化的时间是在构造期间。这样，你可以确定不会出现争用问题，且访问对象属性将始终提供正确的值。
5.3. 记录关键数据
评估你的程序可能会在何处发生异常，并预先记录所有关键数据。如果发生错误，你将很高兴可以得到信息说明收到了哪些请求，并可更好地了解你的应用程序为什么会出现错误。需要再次注意的是，日志记录引入了额外的文件 I/O，可能会严重影响应用的性能，因此请不要滥用日志。
5.4. 复用现存实现
每当你需要创建自己的线程时（例如：向不同的服务发出异步请求），复用现有的安全实现来代替创建自己的解决方案。这在很大程度上意味着要使用 ExecutorServices 和 Java 8 简洁的函数式 CompletableFutures 来创建线程。Spring 还允许通过 DeferredResult 类来进行异步请求处理。
6. 错误六：不使用基于注解的验证
假设我们之前的 TopTalent 服务需要一个端点来添加新的 TopTalent 。此外，假设基于某些原因，每个新名词都需要为 10 个字符长度。执行此操作的一种方法可能如下：

文章插图

然而，上面的方法（除了构造很差以外）并不是一个真正 “干净” 的解决办法。我们正检查不止一种类型的有效性（即 TopTalentData 不得为空，TopTalentData.name 不得为空，且 TopTalentData.name 为 10 个字符长度），以及在数据无效时抛出异常。
通过在 Spring 中集成 Hibernate validator，数据校验可以更干净地进行。让我们首先重构 addTopTalent 方法来支持验证：