问题标签 [java.util.concurrent]

我有两个并行运行的独立线程 F1 和 F2（准确地说，是 java.util.concurrent.FutureTask 的两个实例）。

F1 做一些处理，然后将结果复制到一个 XML 文件中。然后，它重复这些步骤，直到它无事可做（创建了许多 XML 文件）。F2 在 F1 输出目录中查找，并获取一个文件，对其进行解析，并对其执行一些处理。

这非常有效，只是有时 F2 从文件中获取截断的 XML 数据。我的意思是不完整的 XML，其中不存在某些 XML 节点。问题是它并不总是可复制的，被截断的文件并不总是相同的。因此，我认为当 F1 正在磁盘上写入一个文件时，F2 正在尝试读取同一个文件。这就是为什么有时我会遇到这种错误。

我的问题：我想知道是否有某种机制可以锁定（甚至读取）文件 F1 当前正在写入，直到它完全完成将其写入磁盘，所以 F2 在文件解锁之前将无法读取它. 或者任何其他方式来解决我的问题都将受到欢迎！

F1 以这种方式写入文件：

F2 以这种方式读取文件：

Boost Thread 库与 java.util.concurrent 库相比如何？

性能至关重要，因此我更愿意继续使用 C++（尽管如今 Java 快得多）。鉴于我必须用 C++ 编写代码，存在哪些库可以使线程处理变得简单且不易出错。

我最近听说，从 JDK 1.5 开始，Java 内存模型已更改以修复一些并发问题。C++ 怎么样？我上一次在 C++ 中进行多线程编程是在 3-4 年前，当时我使用了 pthreads。虽然，我不想再将它用于大型项目。我知道的唯一其他选择是 Boost Threads。但是，我不确定它是否好。我听说过关于 java.util.concurrent 的好消息，但还没有关于 Boost 线程的消息。

嘿 SO Guru 我正在用这段代码做一份工作

当我第一次运行我的程序时，它尝试运行代码时遇到了这个错误

仔细观察了一下，这似乎是线程通常会发生的错误，为什么它们会尝试同时访问相同的资源，但这就是让我在这个系统中根本不使用多线程的原因。

有人可以解释为什么会这样，或者想办法绕过它

非常感谢^_^

Collections.synchronizedMap()可以在不使用同时保持并发正确性的情况下重写以下代码吗？

即有没有来自 java.util.concurrent 的东西可以用来代替？请注意，仅替换为

显然行不通

我一直对线程感到困惑，我的班级现在大量使用它们。我们正在使用 java.util.concurrent 但我什至没有真正了解基础知识。UpDownLatch、期货、执行者；这些话就在我头上飞过。你们能建议任何资源来帮助我从头开始学习我需要什么吗？

提前非常感谢！

我需要long具有以下要求/事实的类型计数器：

• 递增计数器应该花费尽可能少的时间。
• 计数器只会被一个线程写入。
• 从计数器读取将在另一个线程中完成。
• 计数器会定期递增（每秒最多几千次），但每五秒只会读取一次。
• 精确的准确性不是必需的，只需粗略了解计数器的大小就足够了。
• 计数器永远不会被清零，递减。

基于这些要求，您将如何选择实施您的计数器？作为一个简单的long，作为一个volatile long或使用一个AtomicLong？为什么？

目前我有一个volatile long但想知道另一种方法是否会更好。我也通过做++counter而不是增加我的长期counter++。因为没有完成任务，这真的更有效吗（正如我在其他地方被引导相信的那样）？

我有一个多线程应用程序写入和读取 ConcurrentLinkedQueue，它在概念上用于支持列表/表中的条目。我最初为此使用了 ConcurrentHashMap，效果很好。一项新要求要求跟踪输入的订单条目，因此可以根据某些条件以最旧的第一顺序删除它们。ConcurrentLinkedQueue 似乎是一个不错的选择，而且它在功能上运行良好。

可配置数量的条目保存在内存中，当达到限制时提供新条目时，将按最早的优先顺序在队列中搜索可以删除的条目。某些条目不会被系统删除并等待客户端交互。

似乎正在发生的事情是我在发生的队列前面有一个条目，比如 100K 条目之前。队列似乎配置的条目数量有限（size() == 100），但在分析时，我发现内存中有 ~100K ConcurrentLinkedQueue$Node 对象。这似乎是设计使然，只需查看 ConcurrentLinkedQueue 的源代码，remove 只会删除对正在存储的对象的引用，但会将链表留在原处以进行迭代。

最后我的问题：有没有一种“更好”的懒惰方式来处理这种性质的集合？我喜欢 ConcurrentLinkedQueue 的速度，我无法承受在这种情况下似乎可能出现的无限泄漏。如果没有，似乎我必须创建第二个结构来跟踪订单并且可能有相同的问题，加上同步问题。

我想在 android 应用程序中使用 ConcurrentLinkedQueue，已经编写了代码，但是现在项目构建时出现错误：

我将 Eclipse 与最新版本的 ADT 插件一起使用。

有什么想法可以解决这个问题吗？

我正在使用 ScheduledThreadPoolExecutor 对象安排任务。我使用以下方法：

并将延迟设置为 30 秒（延迟 = 30,000 和单位=TimeUnit.MILLISECONDS）。有时我的任务会立即发生，有时需要 70 秒。

我相信 ScheduledThreadPoolExecutor 使用 CPU 特定的时钟。当我运行比较 System.currentTimeMillis()、System.nanoTime() [这是 CPU 特定的] 的测试时，我看到以下内容

时间表：1272637682651ms，7858346157228410ns

执行：1272637682667ms，7858386270968425ns

差异是 16 毫秒，但 4011374001ns（或 40,113 毫秒）

所以看起来两个40秒的CPU时钟之间存在差异

我如何在java代码中解决这个问题？不幸的是，这是一台客户端机器，我无法修改他们的系统。

我正在编写一个应用程序，它将向用户返回一个 HashMap。用户将获得此 MAP 的参考。在后端，我将运行一些线程来更新地图。

到目前为止我做了什么？

我已经使所有后端线程共享一个公共通道来更新 MAP。所以在后端，我确信并发写操作不会成为问题。

我遇到的问题

1. 如果用户尝试更新 MAP 并且同时在后端更新 MAP --> 并发写入操作问题。
2. 如果使用尝试从 MAP 读取某些内容，同时 MAP 正在后端更新 --> 并发 READ 和 WRITE 操作问题。

到目前为止，我还没有遇到任何此类问题，但我担心我将来可能会遇到。请给出建议。

我在用ConcurrentHashMap<String, String>.