这里有并发问题吗？如何在开发过程中进行测试？

Question

场景:有n个团队每个人都在虚拟的“墙”上工作(就像facebook的墙一样)。每个队只看到自己的墙和柱子。文章可以由文章的作者或其他团队成员编辑(如果是这样配置的话)。假设情况确实如此，因为这是必须的)。

设计/技术决策: RESTful web应用程序使用Restlet+ Glassfish/Java + Mysql (编辑:使用Apache DBUtils进行数据库访问)。没有ORM --似乎是过火了)

问:多个团队登录T1、T2和T3 (比方说)，每个团队都有一定数量的成员。在团队级别的数据访问中存在并发性，但不存在跨团队的并发性，即不同的团队访问不相交的数据集。为了优化数据库的频繁读/写，我们正在考虑一个TeamGateway，它控制对DB的访问以处理并发性。web服务器将缓存团队检索到的数据，以加快读取速度(并帮助更新墙帖列表)。

• Q1:这是否是必需的(每个团队+缓存TableGateway)？如果不是，您建议如何处理？
• Q2:如果是，是否需要将TableGateway (针对每个团队)编码为线程安全(同步方法)？假设我们有一个类/注册表TableGatewayFinder，它具有一个静态方法，该方法返回要用于该特定团队的TableGateway (使用hashmap)。

如果每个T1 - T3登录的6个人只创建3个TableGateways，它会帮助捕获并发写入(提交前简单的时间戳比较或“冲突标记”附加)并有效地管理缓存(我们计划为实体提供身份映射)--需要跟踪的实体有4-5个不同的实体。一个组合层次结构的4个实体，另一个实体与4)中的每一个相关联？

一个单元将如何测试网关(基于TDD或事后)？

提前感谢！

Answer 1

如果您只是写到DB或数据库之上的缓存解决方案(例如，Spring+Hibernate+EhCache等)，则不需要担心损坏表等，即从低级别的角度看不存在并发问题。

如果您想自己编写缓存并自己处理并发问题，那么这需要付出一定的努力。如果您分割缓存，并在每个分区上有一个“全局锁”(即公共互斥锁上的synchronized )，并为任何访问获取该锁，那么这个锁就会工作，尽管这不是最具性能的方法。但是，做一些比全局锁更重要的事情需要做大量的工作。

虽然这很简单，但不确定为什么要使用身份哈希映射.我想不出您想要这样做的任何特定原因(如果您考虑的是性能，那么在这种情况下，最不需要担心的就是正常散列图的性能！)

如果您的实体是文章，那么您可能有另一种形式的并发问题。就像通过SVN、Mercurial等版本控制软件解决的问题一样。也就是说，如果你不把合并功能放到你的应用程序中，那么如果有人编辑某人的文章却发现别人在你之前“提交”了另一个编辑，那就会很烦人。你是否需要添加这样的功能将取决于用例。

至于测试你的应用程序。对于并发性，单元测试并不坏。通过编写并发单元测试，可以更容易地捕获并发错误。编写并发测试非常困难，因此我建议您在编写"Java并发性实践“之类的好书之前阅读它们。最好在集成测试之前捕获您的并发错误，当很难猜到到底发生了什么事情时！

更新：

@Nupul:这是一个很难回答的问题。然而，如果您只有18个人输入东西，我敢打赌，每次写到DB都会很好。

如果您不在其他地方存储任何状态(即只存储在DB中)，则应该消除任何不必要的互斥(并且您不应该在DB以外的任何位置存储任何状态，除非在您的情况下有非常好的理由这样做。

在做类似于网络操作的事情时，很容易犯错误并获得互斥，从而导致极端的可用性问题(例如，应用程序在很多秒内都不会响应)。而且，也很容易出现一些令人讨厌的并发错误，如线程、死锁等。

所以我的建议是保留你的应用程序。没有状态，每次只写到数据库。如果您发现任何由于DB访问导致的性能问题，那么转向像EhCache这样的缓存解决方案将是最好的选择。

除非你想从这个项目中学习，或者必须交付一个应用程序。对于极端的性能要求，我认为编写自己的缓存层是没有道理的。

Answer 2

单元测试可能不是解决并发问题的最佳方法。相反，您可以尝试一个基于web的性能工具，比如JMeter或来测试它是如何执行的，并且随着用户数量的增加，您已经获得了有效的墙壁内容。您可以使用这些工具为每个用户提供不同的发布行为。

Answer 3

专注于标题中的两个问题。

这里有并发问题吗？

是。很明显。避免并发问题的唯一方法是使产品是单线程的，这将带来严重的性能和可用性问题。

如何在开发过程中进行测试？

这是个很难的问题。

显然你需要单元测试。但是，经典的单元测试并不能真正减少并发问题，因为棘手的并发错误往往很少出现。

一个更好的方法是负载测试。正如@Gnat所描述的。

但是，为了获得最好的结果，您需要承认测试不是(整体)解决方案，并添加以下内容：

在设计、编码和测试并发应用程序方面有经验的

• 工作人员。
• 非常关注Goetz等人提出的"Java in Practice“的方法/建议。
• 大量的设计和代码
• 使用静态代码分析器来发现潜在的并发问题。