我有一个 android 客户端，它将与服务器建立 Http 连接。
服务器要求所有 Http 请求在 Http 头中提供一个单调递增的计数器。例如
POST /foo/server
X-count: 43
会发起 Http 连接的地方：
Context#startService 启动）为了提供计数器值，我计划在我的 Application 子类中托管一个 AtomicInteger。然后所有代码将从中心位置检索计数。
如果 Http 连接失败（例如服务器宕机），我需要减少计数器。
您认为 AtomicInteger 是否适合我的场景？
【问题讨论】：
标签： java android multithreading concurrency
AtomicInteger 正是您想要用于该目的的。
【讨论】：
如果 Http 连接失败（例如服务器关闭），我需要减少计数器。
我本来想说“是的”，但在这句话之后我有点不太确定。我认为你想做这样的事情：
定义发送请求（网址） request = 对 url 的新请求 request.header["X-count"] = 下一个序列 如果 request.send() != 成功 倒带序列在这种情况下，我猜不应该允许两个线程同时发送请求，然后你想要序列化请求的东西而不是AtomicInteger，它实际上只是让你原子地执行一些操作。如果两个线程同时调用sendRequest，而第一个线程失败，就会发生这种情况：
现在，您已经发送了两个 X-count = 1 的请求。如果您想避免这种情况，您应该使用类似的东西（假设 Request 和 Response 是用于处理对 URL 的请求的类）：
class SerialRequester {
private volatile int currentSerial = 0;
public synchronized Response sendRequest(URL url) throws SomeException {
Request request = new Request(url);
request.setHeader("X-count", currentSerial);
Response response = request.send();
if (response.isSuccess()) ++currentSerial;
return response;
}
}
该类保证没有两个成功的请求（通过相同的SerialRequester 发出）具有相同的 X-count 值。
编辑 许多人似乎担心上述解决方案不能同时运行。它没有。这是正确的。但它需要以这种方式解决 OP 的问题。现在，如果请求失败时计数器不需要递减，AtomicInteger 将是完美的，但在这种情况下是不正确的。
编辑 2 我得到它来编写一个不太容易冻结的串行请求程序（如上面的那个），这样如果请求等待时间过长（即排队），它就会中止请求在工作线程中但未启动）。因此，如果管道阻塞并且一个请求挂起很长时间，其他请求将最多等待固定的时间，因此队列不会无限增长，直到阻塞消失。
class SerialRequester {
private enum State { PENDING, STARTED, ABORTED }
private final ExecutorService executor =
Executors.newSingleThreadExecutor();
private int currentSerial = 0; // not volatile, used from executor thread only
public Response sendRequest(final URL url)
throws SomeException, InterruptedException {
final AtomicReference<State> state =
new AtomicReference<State>(State.PENDING);
Future<Response> result = executor.submit(new Callable<Response>(){
@Override
public Result call() throws SomeException {
if (!state.compareAndSet(State.PENDING, State.STARTED))
return null; // Aborted by calling thread
Request request = new Request(url);
request.setHeader("X-count", currentSerial);
Response response = request.send();
if (response.isSuccess()) ++currentSerial;
return response;
}
});
try {
try {
// Wait at most 30 secs for request to start
return result.get(30, TimeUnit.SECONDS);
} catch (TimeoutException e){
// 30 secs passed; abort task if not started
if (state.compareAndSet(State.PENDING, State.ABORTED))
throw new SomeException("Request queued too long", e);
return result.get(); // Task started; wait for completion
}
} catch (ExecutionException e) { // Network timeout, misc I/O errors etc
throw new SomeException("Request error", e);
}
}
}
【讨论】：
n 的请求成功，那么以后的请求不应该有 X-count = n - 或者至少，这就是我阅读 OP 的方式。
gustafc 是对的！要求
如果 Http 连接失败（例如服务器宕机），我需要减少计数器。
消除任何并发的可能性！
如果你想要一个唯一的 HTTP 头计数器 AtomicInteger 很好，但是你不能从多个服务器或 JVM 发送请求，你需要允许漏洞。
因此，由于计数是徒劳的（就像在高度可扩展的环境中一样），所以使用 UUID 是一种更“可扩展”和健壮的解决方案。人类需要计数，机器不在乎！
而且，如果您希望在成功发送后增加一个计数器的成功总数（您甚至可以跟踪失败/成功的UUID 请求）。
我的 2 cts 平行计数 :)
【讨论】：