Deep clone utility recommendation [closed]

问题:

Is there any utility for deep cloning for java collections:

• Arrays
• Lists
• Maps

NOTE: prefer some solution without usage of serialization, but with use of Object.clone() method. I can be sure that my custom object will implement clone() method and will use only java-standard classes that are cloneable...

回答1:

I think the previous green answer was bad , why you might ask?

• It adds a lot of code
• It requires you to list all fields to be copied and do this
• This will not work for Lists when using clone() (This is what clone() for HashMap says: Returns a shallow copy of this HashMap instance: the keys and valuesthemselves are not cloned.) so you end up doing it manually (this makes me cry)

Oh and by the way serialization is also bad, you might have to add Serializable all over the place (this also makes me cry).

So what is the solution:

Java Deep-Cloning library The cloning library is a small, open source (apache licence) java library which deep-clones objects. The objects don't have to implement the Cloneable interface. Effectivelly, this library can clone ANY java objects. It can be used i.e. in cache implementations if you don't want the cached object to be modified or whenever you want to create a deep copy of objects.

Cloner cloner=new Cloner();
XX clone = cloner.deepClone(someObjectOfTypeXX);

Check it out at https://github.com/kostaskougios/cloning

回答2:

All approaches to copy objects in Java have serious flaws:

Clone

1. The clone() method is protected, so you can't call it directly unless the class in question overrides it with a public method.
2. clone() doesn't call the constructor. Any constructor. It will allocate memory, assign the internal class field (which you can read via getClass()) and copy the fields of the original.

For more issues with clone(), see item 11 of Joshua Bloch's book "Effective Java, Second Edition"

Serialize

Serialize is even worse; it has many of the flaws of clone() and then some. Joshua has a whole chapter with four items for this topic alone.

My Solution

My solution is add a new interface to my projects:

public interface Copyable<T> {
    T copy ();
    T createForCopy ();
    void copyTo (T dest);
}

The code looks like this:

class Demo implements Copyable<Demo> {
    public Demo copy () {
        Demo copy = createForCopy ();
        copyTo (copy);
        return copy;
    }
    public Demo createForCopy () {
        return new Demo ();
    }
    public void copyTo (Demo dest)
        super.copyTo (dest);
        ...copy fields of Demo here...
    }
}

Unfortunately, I have to copy this code to all my objects but it's always the same code, so I can use an Eclipse editor template. Advantages:

1. I can decide which constructor to call and how to initialize which field.
2. Initialization happens in a deterministic order (root class to instance class)
3. I can reuse existing objects and overwrite them
4. Type safe
5. Singletons stay singletons

For standard Java types (like collections, etc), I use a utility class which can copy those. The methods have flags and callbacks, so I can control how deep a copy should be.

回答3:

Shallow cloning a collection is easy, but if you want to deep clone, a library will probably do you better than hand coding it (since you want to clone the elements inside the collection as well).

Just like this answer, I've used the Cloner library and specifically performance tested it against XStream (which can 'clone' by serializing then deserializing) and binary serialization. Though XStream is very fast at serializing to/from xml, Cloner is much faster at cloning:

0.0851 ms : xstream (clone by serializing/deserializing)
0.0223 ms : binary serialization (clone by serializing/deserializing)
0.0017 ms : cloner
* average time to clone a simple object (two fields) and no default, public constructor. Run 10,000 times.

In addition to being fast, here are more reasons to choose cloner:

1. performs a deep clone of any object (even those you don't write yourself)
2. you don't have to keep your clone() method up-to-date each time you add a field
3. you can clone objects that don't have a default public constructor
4. works with Spring
5. (optimization) doesn't clone known immutable objects (like Integer, String, etc.)

6. easy to use. Example:

   cloner.deepClone(anyObject);

回答4:

I am the creator of the cloner lib, the one that Brad presented. This is a solution for cloning objects without having to write any extra code (no need for serializable objects or impl clone() method)

It's quite fast as Brad said, and recently I uploaded a version which is even faster. Note that manually implementing a clone() method will be faster than clone lib, but then again you'll need to write a lot of code.

Cloner lib has worked quite well for me since I am using it in a cache implementation for a site with very heavy traffic (~1 million requests/day). The cache should clone approximately 10 objects per request. It is quite reliable and stable. But please be aware that cloning is not without risk. The lib can be configured to println every class instance that it clones during dev. This way you can check if it clones what you think it should clone - object graphs can be very deep and can contain references to a surprisingly large amount of objects. With clone lib, you can instruct it to not clone the objects that you don't want, i.e. singletons.

回答5:

One general way to deep-clone an arbitrary collection is to serialize it to a stream, then read it back into a new collection. You'll be rehydrating completely new objects that don't have any relationship to the old ones, other than being identical copies.

Check out Bruno's answer for a link to the Apache Commons serialization utility classes, which will be very helpful if this is the route you decide to take.

回答6:

One possibility is to use serialization:

Apache Commons provides SerializationUtils

回答7:

I've used this cloning library and found it quite useful. Since it had a few limitations (I needed finer grained control over the cloning process: which field, in what context and how deeply should be cloned etc.), I've created an extended version of it. You control the cloning of the fields by annotating them in the entity class.

Just to get a flavour of it, here is an example class:

public class CloneMePlease {
    @Clone(Skip.class)
    String id3 = UUID.randomUUID().toString();

    @Clone(Null.class)
    String id4 = UUID.randomUUID().toString();

    @Clone(value = RandomUUID.class, groups=CustomActivationGroup1.class)
    String id5 = UUID.randomUUID().toString();

    @Clone.List({
            @Clone(groups=CustomActivationGroup2.class, value=Skip.class),
            @Clone(groups=CustomActivationGroup3.class, value=Copy.class)})
    Object activationGroupOrderTest = new Object();

    @Clone(LongIncrement.class)
    long version = 1l;

    @PostClone
    private void postClone(CloneMePlease original, @CloneInject CloneInjectedService service){
         //do stuff with the original source object in the context of the cloned object
         //you can inject whatewer service you want, from spring/guice to perform custom logic here
    }
}

More details here: https://github.com/mnorbi/fluidity-cloning

There is also a hibernate specific extension in case one needs it.

回答8:

Use serialization and then deserialization, but be aware that this approach works only with Serializable classes without transient fields. Also, your singletons will not be singletons anymore.