I suppose that it is not inconceivable that ObjectOutputStream's handle table data structure could be reworked so that it did not grow in proportion to the number of handles allocated for objects written "unshared"-- but that would likely be at the performance expense, in space and time, of normal usage, and it's not obvious that the same could be done for ObjectInputStream's handle table.
Despite the use of writeUnshared, the usage described in this report is pretty much reminiscent of that described in 4363937, 4075901, and related closed reports. (And note that as soon as the written Data class has references to other objects-- not just primitive data-- in its serialized form, those objects will require non-empty handles unless they are also all written "unshared".)
As described in the previously cited reports, the proper way to write a continuing series of objects that are not intended to represent a single consistent object graph (with integrity of references, etc.) is to invoke ObjectOutputStream.reset() in between the writes.