爪哇.多线程环境中对象的序列化

2022-01-22 00:00:00 serialization synchronization java

我有一个对象，其内部可变状态由一个或多个线程不断更新.对象是同步的，目标是从另一个线程定期保存其状态(通过序列化):

I have an object whose internal mutable state is being constantly updated by one or more threads. The object is synchronized, and the goal is to periodically save its state (via serialization) from yet another thread:

public class Counter implements Serializable {
    private int dogCount;
    private int catCount;

    public synchronized void updateFromDogThread( int count ) { 
        dogCount = count; 
    }

    public synchronized void updateFromCatThread( int count ) { 
        catCount = count; 
    }
}

问题:

  • 在这种情况下，序列化安全吗?
  • 它在后台是如何工作的?也就是说，ObjectOutputStream会执行序列化块，直到没有线程在Counter上运行?
  • 如果 Counter 的同步不使用内部锁，而是使用其他锁怎么办?
  • Is serialization safe in this case?
  • How does it work under the hood? That is to say, will the ObjectOutputStream performing the serialization block until no threads are any longer operating on Counter?
  • What if Counter's synchronization doesn't use the intrinsic lock, but some other lock?

推荐答案

  • 在这种情况下，序列化安全吗?

没有.正如@Tom Hawtin 所说，您需要执行自己的锁定以确保在序列化对象时不会更改对象.

No. As @Tom Hawtin says, you will need to perform your own locking to ensure that the object(s) are not changed while you are serializing them.

  • 它在后台是如何工作的?也就是说，ObjectOutputStream 是否会执行序列化阻塞，直到没有线程在 Counter 上运行?

ObjectOutputStream 在底层没有锁定.如有必要，由应用程序执行此操作.

ObjectOutputStream does no locking under the hood. It is up to the application to do this, if it is necessary.

  • 如果 Counter 的同步不使用内部锁，而是使用其他锁怎么办?

那么您的应用程序还需要在序列化发生时使用其他锁来锁定更新.

Then your application will also need to use that other lock to lock out updates while serialization is happening.

如果您要序列化的状态仅由一个具有两个字段的对象的状态组成，那么锁争用和粒度应该不是问题.但是如果对象很复杂，那么锁争用很可能是有问题的，获取锁而不冒死锁风险的问题也是如此.这种情况需要仔细设计.

If the state that you are serializing simply consists of the state of one object with two fields, then lock contention and granularity should not be a problem. But if the object(s) are complicated, then lock contention could well be problematic, as could the problem of acquiring the locks without risking deadlock. That scenario would require careful design.

相关文章