Java: назначение идентификаторов ссылок на объекты для пользовательской сериализации

Вам действительно нужно это делать? Внутри ObjectOutputStream отслеживает, какие объекты уже были сериализованы. Последующие записи того же объекта сохраняют только внутреннюю ссылку (аналогично записи только идентификатора), а не запись всего объекта снова.

Дополнительные сведения см. в разделе кэш сериализации.

Если идентификаторы соответствуют некоторому внешнему идентификатору, такому как идентификатор объекта, то это имеет смысл. Но в вопросе говорится, что идентификаторы генерируются исключительно для отслеживания того, какие объекты сериализуются.

Вы можете обрабатывать синглтоны с помощью метода readResolve. Простой подход состоит в том, чтобы сравнить только что десериализованный экземпляр с вашими одноэлементными экземплярами и, если есть совпадение, вернуть одноэлементный экземпляр, а не десериализованный экземпляр. Например.

   private Object readResolve() {
      return (this.equals(SINGLETON)) ? SINGLETON : this;
      // or simply
      // return SINGLETON;
   }

РЕДАКТИРОВАТЬ: В ответ на комментарии поток в основном представляет собой двоичные данные (хранящиеся в оптимизированном формате) со сложными объектами, рассредоточенными в этих данных. С этим можно справиться, используя формат потока, который поддерживает подпотоки, например. zip или простое разбиение на блоки. Например. поток может быть последовательностью блоков:

offset 0  - block type
offset 4  - block length N
offset 8  - N bytes of data
...
offset N+8  start of next block

Затем у вас могут быть блоки для двоичных данных, блоки для сериализованных данных, блоки для сериализованных данных XStream и т. д. Поскольку каждый блок знает свой размер, вы можете создать подпоток для чтения до этой длины из места в файле. Это позволяет свободно смешивать данные, не беспокоясь об их синтаксическом анализе.

Чтобы реализовать поток, ваш основной поток должен анализировать блоки, например.

   DataInputStream main = new DataInputStream(input);
   int blockType = main.readInt();
   int blockLength = main.readInt();
   // next N bytes are the data
   LimitInputStream data = new LimitInputStream(main, blockLength);

   if (blockType==BINARY) {
      handleBinaryBlock(new DataInputStream(data));
   }
   else if (blockType==OBJECTSTREAM) {
      deserialize(new ObjectInputStream(data));
   }
   else
      ...

Эскиз LimitInputStream выглядит так:

public class LimitInputStream extends FilterInputStream
{
   private int bytesRead;
   private int limit;
   /** Reads up to limit bytes from in */
   public LimitInputStream(InputStream in, int limit) {
      super(in);
      this.limit = limit;
   }

   public int read(byte[] data, int offs, int len) throws IOException {
      if (len==0) return 0; // read() contract mandates this
      if (bytesRead==limit)
         return -1;
      int toRead = Math.min(limit-bytesRead, len);
      int actuallyRead = super.read(data, offs, toRead);
      if (actuallyRead==-1)
          throw new UnexpectedEOFException();
      bytesRead += actuallyRead;
      return actuallyRead;
   }

   // similarly for the other read() methods

   // don't propagate to underlying stream
   public void close() { }
}

Зарегистрированы ли foo в FooRegistry? Вы можете попробовать этот подход (предположим, что у Bar и Baz также есть реестры для получения ссылок через идентификатор).

Это, вероятно, имеет много синтаксических ошибок, ошибок использования и т. д. Но я считаю, что подход хороший.

открытый класс Foo {

public Foo(...) {
    //construct
    this.id = FooRegistry.register(this);
}

public Foo(long id, ...) {
    //construct
    this.id = id;
    FooRegistry.register(this,id);
}

}

открытый класс FooRegistry() { Map foos = new HashMap...

long register(Foo foo) {
    while(foos.get(currentFooCount) == null) currentFooCount++;
    foos.add(currentFooCount,foo);
    return currentFooCount;
}

void register(Foo foo, long id) {
    if(foo.get(id) == null) throw new Exc ... // invalid
    foos.add(foo,id);
}

}

открытый класс Bar () {

void writeToStream(OutputStream out) {
    out.print("<BAR><id>" + id + "</id><foo>" + foo.getId() + "</foo></BAR>");
}

}

открытый класс Baz () {

void.writeToStream(OutputStream out) {
    out.print("<BAZ><id>" + id + "</id>");
    for(Bar bar : barList) out.println("<bar>" + bar.getId() + </bar>");
    out.print("</BAZ>");
}

}

Мне кажется, что я заново изобретаю велосипед, и должна быть хорошо зарекомендовавшая себя техника для обработки всех случаев.

Да, похоже, что подойдет сериализация объектов по умолчанию, или, в конечном счете, вы выполняете предварительную оптимизацию.

Вы можете изменить формат сериализованных данных (например, XMLEncoder делает ) для более удобного.

Но если вы настаиваете, я думаю, что синглтон с динамическим счетчиком должен подойти, но не помещайте идентификатор в общедоступный интерфейс для конструктора:

class Foo {
    private final int id;
    public Foo( int id, /*other*/ ) { // drop the int id
    }
 }

Таким образом, класс может быть «последовательностью», и, вероятно, более подходящим будет длинный, чтобы избежать проблем с Integer.MAX_VALUE.

Использование AtomicLong, как описано в java.util.concurrent.atomic (чтобы избежать присвоения двумя потоками одного и того же идентификатора или избежать чрезмерной синхронизации) также может помочь.

class Sequencer {
    private static AtomicLong sequenceNumber = new AtomicLong(0);
    public static long next() { 
         return sequenceNumber.getAndIncrement();
    }
}

Теперь в каждом классе у вас есть

 class Foo {
      private final long id;
      public Foo( String name, String data, etc ) {
          this.id = Sequencer.next();
      }
 }

Вот и все.

(обратите внимание, я не помню, вызывает ли десериализация объекта конструктор, но вы поняли идею)