1.Java 深拷貝與淺拷貝：全維度解析（含面試 / 筆試 + 實戰(zhàn)）

一、核心概念：淺拷貝 vs 深拷貝（通俗解釋 + 核心差異）

1. 基礎定義

• 淺拷貝（Shallow Copy）：僅拷貝對象的 “基本數(shù)據(jù)類型屬性”，對于 “引用類型屬性”，僅拷貝引用地址（新舊對象共享同一個引用對象）。

  → 類比：你復制了一份文件的快捷方式（引用），原文件和快捷方式指向同一個文件，修改文件內容，兩者都會變。

• 深拷貝（Deep Copy）：完全拷貝對象的所有屬性，包括引用類型屬性（遞歸拷貝引用對象的所有內容），新舊對象完全獨立，互不影響。

  → 類比：你復制了文件的全部內容到新文件，原文件和新文件是兩個獨立文件，修改其一，另一個不受影響。

2. 核心差異表

3. 直觀代碼示例（理解差異）

// 引用類型屬性類
class Address {
    private String city;
    public Address(String city) { this.city = city; }
    // getter/setter/toString 省略
}

// 被拷貝的主類
class Person implements Cloneable {
    private String name; // 基本類型（包裝類，值拷貝）
    private Address address; // 引用類型

    public Person(String name, Address address) {
        this.name = name;
        this.address = address;
    }

    // 淺拷貝：重寫clone()（默認淺拷貝）
    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone(); // Object的clone()是淺拷貝
    }

    // getter/setter/toString 省略
}

// 測試淺拷貝
public class CopyTest {
    public static void main(String[] args) throws CloneNotSupportedException {
        Address address = new Address("北京");
        Person p1 = new Person("張三", address);
        Person p2 = (Person) p1.clone(); // 淺拷貝

        // 1. 修改基本類型：互不影響
        p2.setName("李四");
        System.out.println(p1.getName()); // 張三（獨立）
        // 2. 修改引用類型：p1和p2都變（共享對象）
        p2.getAddress().setCity("上海");
        System.out.println(p1.getAddress().getCity()); // 上海（不獨立）
    }
}

如果是深拷貝，修改p2.getAddress().setCity("上海")后，p1的 city 仍為 “北京”。

二、實現(xiàn)方法（淺拷貝 + 深拷貝）

1. 淺拷貝的實現(xiàn)方式

方式 1：實現(xiàn)Cloneable接口 + 重寫clone()（最常用）

• 核心：Object類的clone()方法默認是淺拷貝，實現(xiàn)Cloneable接口（標記接口，無方法）后可調用。
• 代碼示例：見上文Person類的clone()方法。

方式 2：手動 new 對象，賦值基本類型屬性

// 手動淺拷貝
public Person shallowCopy(Person p) {
    Person newPerson = new Person();
    newPerson.setName(p.getName()); // 基本類型賦值
    newPerson.setAddress(p.getAddress()); // 引用類型賦值（共享）
    return newPerson;
}

2. 深拷貝的實現(xiàn)方式（4 種常用）

方式 1：重寫clone()（遞歸拷貝引用對象）

• 核心：不僅拷貝主對象，還遞歸調用引用類型屬性的clone()方法。

// 步驟1：Address實現(xiàn)Cloneable并重寫clone()
class Address implements Cloneable {
    private String city;
    // 構造器、getter/setter省略
    
    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

// 步驟2：Person的clone()遞歸拷貝Address
class Person implements Cloneable {
    private String name;
    private Address address;

    @Override
    protected Object clone() throws CloneNotSupportedException {
        Person person = (Person) super.clone(); // 先淺拷貝主對象
        person.address = (Address) address.clone(); // 再拷貝引用對象（深拷貝核心）
        return person;
    }
}

方式 2：序列化（推薦，通用）

• 核心：將對象序列化為字節(jié)流，再反序列化為新對象（天然深拷貝）。
• 要求：所有類實現(xiàn)Serializable接口（標記接口）。

import java.io.*;

class Person implements Serializable {
    private static final long serialVersionUID = 1L;
    private String name;
    private Address address; // Address也需實現(xiàn)Serializable

    // 深拷貝方法
    public Person deepCopyBySerialize() throws IOException, ClassNotFoundException {
        // 序列化
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(bos);
        oos.writeObject(this);

        // 反序列化
        ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
        ObjectInputStream ois = new ObjectInputStream(bis);
        return (Person) ois.readObject();
    }
}

class Address implements Serializable {
    private static final long serialVersionUID = 1L;
    private String city;
    // 構造器、getter/setter省略
}

方式 3：手動 new 所有引用對象（適合簡單場景）

// 手動深拷貝
public Person deepCopyByManual(Person p) {
    Address newAddress = new Address(p.getAddress().getCity()); // 新建引用對象
    Person newPerson = new Person(p.getName(), newAddress);
    return newPerson;
}

方式 4：工具類（Apache Commons BeanUtils/ Spring BeanUtils）

• 注意：BeanUtils默認淺拷貝，需結合遞歸實現(xiàn)深拷貝；Gson/Jackson序列化工具也可實現(xiàn)深拷貝。

import org.apache.commons.beanutils.BeanUtils;
import org.apache.commons.beanutils.PropertyUtils;

// 淺拷貝
BeanUtils.copyProperties(newPerson, oldPerson);
// 深拷貝（需自定義遞歸）
public static <T> T deepCopy(T source) throws Exception {
    if (source == null) return null;
    Class<?> clazz = source.getClass();
    Object target = clazz.newInstance();
    for (java.lang.reflect.Field field : clazz.getDeclaredFields()) {
        field.setAccessible(true);
        Object value = field.get(source);
        if (value instanceof Serializable) { // 引用類型且可序列化
            field.set(target, deepCopy(value)); // 遞歸拷貝
        } else {
            field.set(target, value); // 基本類型直接賦值
        }
    }
    return (T) target;
}

三、面試高頻問題及逐字稿答案

問題 1：Java 中淺拷貝和深拷貝的核心區(qū)別是什么？

面試官您好，淺拷貝和深拷貝的核心區(qū)別在于對引用類型屬性的處理方式不同：

1. 淺拷貝：僅拷貝對象的基本數(shù)據(jù)類型屬性的值，對于引用類型屬性，只拷貝引用地址 —— 新舊對象共享同一個引用對象，修改其中一個的引用屬性，另一個會同步變化；

2. 深拷貝：不僅拷貝基本數(shù)據(jù)類型的值，還會遞歸拷貝所有引用類型屬性的對象本身 —— 新舊對象完全獨立，修改任何一個的屬性都不會影響另一個。

   舉個例子：如果 Person 類有 Address 引用屬性，淺拷貝后兩個 Person 的 Address 指向同一個對象，改 city 會互相影響；深拷貝后兩個 Person 有獨立的 Address 對象，改 city 互不影響。

問題 2：為什么重寫 clone () 方法需要實現(xiàn) Cloneable 接口？如果不實現(xiàn)會怎樣？

面試官您好，原因如下：

1. Cloneable是一個標記接口（沒有任何方法），它的作用是告訴 JVM：該類允許調用Object類的clone()方法；

2. 如果不實現(xiàn)Cloneable接口，直接調用super.clone()會拋出CloneNotSupportedException異常 —— 因為Object的clone()方法會先檢查當前類是否實現(xiàn)了Cloneable，未實現(xiàn)則拋異常。

   補充：Cloneable接口的設計被認為是 Java 的一個 “缺陷”（標記接口不符合接口的設計初衷），但這是 JDK 的歷史實現(xiàn)方式，實際開發(fā)中仍需遵循。

問題 3：深拷貝有哪些實現(xiàn)方式？各自的優(yōu)缺點是什么？

面試官您好，深拷貝主要有 4 種實現(xiàn)方式，優(yōu)缺點如下：

1. 重寫 clone () 遞歸拷貝：

   • 優(yōu)點：JDK 原生實現(xiàn)，無需依賴第三方庫，性能較好；
   • 缺點：代碼繁瑣（每個引用類型都要實現(xiàn) Cloneable + 重寫 clone ()），無法處理循環(huán)引用（如 A 引用 B，B 引用 A）。

2. 序列化 / 反序列化：

   • 優(yōu)點：通用、簡潔，自動處理遞歸拷貝，支持循環(huán)引用；
   • 缺點：所有類需實現(xiàn) Serializable 接口，性能略差（字節(jié)流操作），無法拷貝 transient 修飾的屬性。

3. 手動 new 引用對象：

   • 優(yōu)點：簡單直觀，性能最好；
   • 缺點：代碼冗余（屬性多時代碼量大），擴展性差（新增屬性需修改拷貝方法）。

4. 工具類（如 Apache BeanUtils/ Gson）：

   • 優(yōu)點：無需手寫拷貝邏輯，適配復雜對象；

   • 缺點：依賴第三方庫，BeanUtils 默認淺拷貝（需自定義遞歸），性能一般。

     實際開發(fā)中，序列化方式是最常用的（平衡簡潔性和通用性），簡單對象可手動 new，高性能場景用重寫 clone ()。

問題 4：transient 修飾的屬性在深拷貝（序列化方式）中會被拷貝嗎？為什么？

面試官您好，不會被拷貝。原因是：transient關鍵字的作用是阻止屬性被序列化—— 當對象序列化為字節(jié)流時，transient 修飾的屬性會被忽略，反序列化時該屬性會被賦值為默認值（如 String 為 null，int 為 0）。如果需要拷貝 transient 屬性，序列化方式不可用，需改用重寫 clone () 或手動 new 的方式。

問題 5：淺拷貝在實際開發(fā)中可能會引發(fā)什么問題？如何避免？

面試官您好，淺拷貝的核心問題是引用屬性共享導致的 “副作用”：比如多線程場景下，一個線程修改淺拷貝對象的引用屬性，會導致原對象的屬性被意外修改，引發(fā)數(shù)據(jù)不一致；或者業(yè)務邏輯中誤改拷貝對象的引用屬性，導致原對象數(shù)據(jù)錯誤。避免方式：

1. 明確需要獨立對象時，直接用深拷貝；
2. 必須用淺拷貝時，禁止修改拷貝對象的引用屬性（僅讀?。?；
3. 對引用屬性加不可變約束（如用 final 修飾，或返回屬性的拷貝而非原對象）。

四、筆試題目及答案（典型考點）

題目 1：代碼分析題（判斷拷貝結果）

class Phone {
    String brand;
    public Phone(String brand) { this.brand = brand; }
}

class User implements Cloneable {
    String name;
    Phone phone;

    public User(String name, Phone phone) {
        this.name = name;
        this.phone = phone;
    }

    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone();
    }

    public static void main(String[] args) throws CloneNotSupportedException {
        Phone phone = new Phone("華為");
        User u1 = new User("小明", phone);
        User u2 = (User) u1.clone();

        u2.name = "小紅";
        u2.phone.brand = "蘋果";

        System.out.println(u1.name); // 問題1：輸出什么？
        System.out.println(u1.phone.brand); // 問題2：輸出什么？
    }
}

答案及解析：

• 問題 1：輸出 “小明”——name 是 String（不可變的基本類型包裝類），淺拷貝拷貝值，u2 修改 name 不影響 u1；
• 問題 2：輸出 “蘋果”——phone 是引用類型，淺拷貝僅拷貝引用，u2 修改 phone.brand 會同步影響 u1。

題目 2：代碼補全題（實現(xiàn)深拷貝）

要求：補全User類的clone()方法，實現(xiàn)深拷貝，使得修改 u2 的 phone.brand 后，u1 的 phone.brand 不變。

class Phone implements Cloneable {
    String brand;
    public Phone(String brand) { this.brand = brand; }
    
    // 步驟1：補全Phone的clone()
    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

class User implements Cloneable {
    String name;
    Phone phone;

    public User(String name, Phone phone) {
        this.name = name;
        this.phone = phone;
    }

    // 步驟2：補全User的clone()（深拷貝）
    @Override
    protected Object clone() throws CloneNotSupportedException {
        User user = (User) super.clone(); // 先淺拷貝主對象
        user.phone = (Phone) phone.clone(); // 遞歸拷貝引用對象
        return user;
    }

    public static void main(String[] args) throws CloneNotSupportedException {
        Phone phone = new Phone("華為");
        User u1 = new User("小明", phone);
        User u2 = (User) u1.clone();

        u2.phone.brand = "蘋果";
        System.out.println(u1.phone.brand); // 輸出“華為”（深拷貝生效）
    }
}

題目 3：選擇題（深拷貝的特性）

以下關于 Java 深拷貝的描述，正確的是（）A. 深拷貝會拷貝基本類型的值和引用類型的引用地址B. 序列化實現(xiàn)深拷貝時，所有類必須實現(xiàn) Cloneable 接口C. 深拷貝后的對象與原對象完全獨立，修改其一不影響另一D. 重寫 clone () 實現(xiàn)深拷貝時，無需處理引用類型的拷貝

答案：C

解析：

• A 錯誤：深拷貝拷貝引用類型的對象本身，而非引用地址；
• B 錯誤：序列化需要實現(xiàn) Serializable 接口，Cloneable 是 clone () 的標記接口；
• C 正確：深拷貝的核心特性是對象獨立；
• D 錯誤：重寫 clone () 實現(xiàn)深拷貝必須遞歸拷貝引用類型。

五、核心總結

1. 拷貝選擇原則

2. 避坑要點

1. 不要混淆 “淺拷貝” 和 “值拷貝”：僅基本類型是值拷貝，引用類型是引用拷貝；
2. 序列化深拷貝需注意 transient 屬性（不會被拷貝）和循環(huán)引用（可處理）；
3. Cloneable 接口是標記接口，未實現(xiàn)會拋 CloneNotSupportedException；
4. String 是不可變類型，淺拷貝后修改 String 屬性不會影響原對象（本質是新建 String 對象）。

3. 面試 / 筆試核心記憶點

• 淺拷貝：基本類型值拷貝，引用類型引用拷貝 → 共享引用對象；
• 深拷貝：遞歸拷貝所有屬性 → 完全獨立；
• 實現(xiàn)方式：淺拷貝（Cloneable+clone ()），深拷貝（遞歸 clone ()、序列化、手動 new）；
• 關鍵接口：Cloneable（clone () 標記）、Serializable（序列化標記）。

深拷貝和淺拷貝在實際應用中的注意事項有哪些？

2.深拷貝與淺拷貝在實際應用中的核心注意事項（附避坑案例）

深拷貝和淺拷貝的誤用是實際開發(fā)中高頻引發(fā)數(shù)據(jù)不一致、業(yè)務 bug 的原因之一，核心注意事項需圍繞場景適配、實現(xiàn)完整性、數(shù)據(jù)安全、性能開銷四大維度展開，以下是分場景的詳細注意事項及避坑方案：

一、淺拷貝的核心注意事項（重點：規(guī)避 “共享引用” 的副作用）

淺拷貝的核心風險是 “引用類型屬性共享”，實際應用中需重點約束引用屬性的使用方式：

1. 明確引用屬性的 “只讀” 約束，禁止修改

淺拷貝后，新舊對象的引用屬性指向同一個對象，修改拷貝對象的引用屬性會同步污染原對象，這是最常見的業(yè)務 bug 來源。

• ? 正確做法：若使用淺拷貝，需約定 “拷貝對象僅讀取引用屬性，不修改”；若必須修改，改用深拷貝。
• ? 反面案例：電商系統(tǒng)中，運營人員拷貝訂單草稿（淺拷貝）后修改收貨地址，導致原訂單的地址也被篡改，最終發(fā)貨錯誤。

// 淺拷貝后修改引用屬性的風險
Order originalOrder = new Order("001", new Address("北京"));
Order copyOrder = (Order) originalOrder.clone(); // 淺拷貝
copyOrder.getAddress().setCity("上海"); // 原訂單地址也變成上海！

2. 不可變類型的 “特殊豁免”：String / 包裝類無需深拷貝

String、Integer、Long 等不可變類型（屬性無 setter，修改時會新建對象），即使是淺拷貝，修改拷貝對象的該屬性也不會影響原對象 —— 因為修改本質是 “新建對象并重新賦值引用”，而非修改原有對象內容。

• 注意：不要誤以為 “所有引用類型淺拷貝都有風險”，不可變類型的淺拷貝完全安全，無需額外處理。

User u1 = new User("張三");
User u2 = (User) u1.clone(); // 淺拷貝
u2.setName("李四"); // String不可變，u1的name仍為“張三”（安全）

3. 多線程場景：淺拷貝對象禁止跨線程修改引用屬性

多線程環(huán)境下，若多個線程持有淺拷貝后的對象并修改引用屬性，會引發(fā)競態(tài)條件（比如線程 A 修改地址，線程 B 讀取到臟數(shù)據(jù)），甚至并發(fā)修改異常（ConcurrentModificationException）。

• ? 解決方案：
  • 若必須跨線程使用，改用深拷貝；
  • 若堅持淺拷貝，對引用屬性加鎖（如 synchronized）或使用線程安全的容器（如 CopyOnWriteArrayList）。

4. 避免 “假獨立” 認知：淺拷貝僅保證 “基本類型獨立”

很多開發(fā)者誤以為 “淺拷貝后對象完全獨立”，實則僅基本類型（int、long、boolean）和不可變類型獨立，引用類型仍共享。

• ? 避坑：在注釋中明確標注 “該方法為淺拷貝，引用屬性共享，請勿修改”，或在接口文檔中說明。

二、深拷貝的核心注意事項（重點：保證 “完全獨立”+ 控制性能開銷）

深拷貝的核心目標是 “對象完全獨立”，但實現(xiàn)過程中易因細節(jié)遺漏導致 “偽深拷貝”，或因性能問題影響系統(tǒng)效率：

1. 循環(huán)引用：遞歸拷貝易棧溢出，序列化是更優(yōu)解

若對象存在循環(huán)引用（如 A 引用 B，B 又引用 A），使用 “重寫 clone () 遞歸拷貝” 會導致棧溢出（StackOverflowError）；而序列化方式（JDK 序列化、Gson/Jackson）天然支持循環(huán)引用，無需額外處理。

• ? 反面案例：

class A implements Cloneable {
    private B b;
    @Override protected Object clone() { A a=(A)super.clone(); a.b=(B)b.clone(); return a; }
}
class B implements Cloneable {
    private A a;
    @Override protected Object clone() { B b=(B)super.clone(); b.a=(A)a.clone(); return b; }
}
// 循環(huán)引用導致遞歸clone()棧溢出
A a = new A(); B b = new B(); a.setB(b); b.setA(a);
A copyA = (A) a.clone(); // StackOverflowError

• ? 解決方案：改用序列化實現(xiàn)深拷貝（自動處理循環(huán)引用）。

2. transient 關鍵字：序列化深拷貝會丟失該屬性

transient修飾的屬性會被序列化忽略，反序列化后該屬性為默認值（String=null、int=0），若該屬性是業(yè)務必需的（如用戶密碼、訂單狀態(tài)），會導致數(shù)據(jù)丟失。

• ? 解決方案：
  • 若必須保留 transient 屬性：改用 “遞歸 clone ()” 或 “手動 new 對象” 實現(xiàn)深拷貝；
  • 若無需保留：確認業(yè)務邏輯允許該屬性為默認值，或在拷貝后手動賦值。

3. 實現(xiàn)完整性：確保所有引用類型都被遞歸拷貝

“偽深拷貝” 是深拷貝最常見的坑 —— 僅拷貝了第一層引用對象，嵌套的引用對象仍共享（比如 Person→Address→Province，只拷貝 Address，沒拷貝 Province）。

• ? 檢查原則：從頂層對象開始，逐層確認所有引用類型都實現(xiàn)了拷貝邏輯（Cloneable/Serializable）。

// 偽深拷貝（漏拷貝Province）
class Address implements Cloneable {
    private Province province; // 嵌套引用類型
    @Override protected Object clone() { return super.clone(); } // 僅淺拷貝Province
}
class Person implements Cloneable {
    private Address address;
    @Override protected Object clone() {
        Person p = (Person) super.clone();
        p.address = (Address) address.clone(); // Address的Province仍共享
        return p;
    }
}

• ? 修正：Address 的 clone () 需遞歸拷貝 Province。

4. 第三方類的拷貝限制：適配非可控的引用類型

若引用屬性是第三方 SDK 的類（如com.alipay.api.domain.AlipayTradeOrder），該類可能未實現(xiàn)Cloneable或Serializable，無法用常規(guī)方式深拷貝。

• ? 解決方案：
  • 手動 new 第三方類，逐字段賦值（最可靠）；
  • 用反射遞歸拷貝所有字段（需處理訪問權限）；
  • 用 Gson/Jackson 將對象轉為 JSON 字符串，再轉回對象（通用方案，無需接口支持）。

5. 性能與內存：高頻場景慎用深拷貝

深拷貝需要遞歸拷貝所有對象，內存占用是淺拷貝的 N 倍，性能也顯著更低（尤其是批量處理數(shù)據(jù)時）。

• ? 優(yōu)化策略：
  • 高頻調用場景（如接口每秒千次調用）：評估是否真的需要深拷貝，若僅讀取，改用淺拷貝；
  • 大數(shù)據(jù)對象（如包含 10 萬條數(shù)據(jù)的 List）：分段拷貝或使用 “懶拷貝”（按需拷貝，僅修改時才深拷貝）；
  • 緩存場景：拷貝緩存對象時，若僅展示，淺拷貝；若修改，深拷貝且不寫回緩存。

三、通用注意事項（淺拷貝 / 深拷貝均需遵守）

1. 不可變對象：無需深拷貝，淺拷貝即可

若對象是 “不可變對象”（所有屬性 final，無 setter 方法，創(chuàng)建后無法修改），淺拷貝和深拷貝效果完全一致 —— 因為無法修改任何屬性，自然不存在 “共享污染” 問題。

• ? 建議：不可變對象優(yōu)先用淺拷貝（更高效），比如枚舉、常量對象、自定義的不可變 DTO。

2. 工具類陷阱：BeanUtils 默認是淺拷貝

Apache Commons BeanUtils、Spring BeanUtils 是開發(fā)中常用的拷貝工具，但它們默認僅實現(xiàn)淺拷貝，很多開發(fā)者誤以為是深拷貝，導致引用屬性共享。

• ? 錯誤用法：

// 淺拷貝，user2的address與user1共享
User user2 = new User();
BeanUtils.copyProperties(user2, user1);

• ? 解決方案：
  • 若需深拷貝，不要依賴 BeanUtils，改用序列化；
  • 若用 BeanUtils，需自定義遞歸拷貝邏輯，逐層拷貝引用屬性。

3. 序列化深拷貝：顯式聲明 serialVersionUID

實現(xiàn)Serializable接口時，若未顯式聲明serialVersionUID，類結構變化（如新增 / 刪除字段）會導致反序列化失?。↖nvalidClassException）。

• ? 建議：所有序列化類都顯式聲明版本號：

class User implements Serializable {
    private static final long serialVersionUID = 1L; // 顯式版本號
    // ...
}

4. 空值處理：避免拷貝時的空指針異常

拷貝過程中，若引用屬性為 null，遞歸 clone () 或反射拷貝會拋出空指針，需提前判空。

• ? 通用判空邏輯：

public Object deepClone(Object obj) {
    if (obj == null) return null;
    // 后續(xù)拷貝邏輯
}

5. 拷貝后的對象一致性：保證 equals/hashCode 有效

拷貝后的對象需保證equals()和hashCode()邏輯與原對象一致，否則存入 Set/Map 時會出現(xiàn) “重復對象” 或 “查找失敗” 問題。

• ? 建議：拷貝方法（clone ()/deepCopy ()）需保證所有參與 equals/hashCode 的屬性都被正確拷貝。

四、實際應用的決策總結（快速選對拷貝方式）

五、避坑清單（開發(fā)前快速核對）

1. 淺拷貝：是否約定引用屬性 “只讀”？是否區(qū)分了不可變類型？
2. 深拷貝：是否處理了循環(huán)引用？是否拷貝了所有嵌套引用類型？
3. 序列化：是否聲明了 serialVersionUID？是否忽略了 transient 屬性？
4. 工具類：是否混淆了 BeanUtils 的淺拷貝特性？
5. 性能：高頻場景是否過度使用深拷貝？大數(shù)據(jù)對象是否做了優(yōu)化？
6. 多線程：拷貝對象是否存在跨線程修改引用屬性的風險？

通過以上注意事項的約束，可大幅降低拷貝操作引發(fā)的業(yè)務 bug，同時平衡性能與數(shù)據(jù)安全性。核心原則是：能用淺拷貝（高效）就不用深拷貝，用深拷貝時必須保證 “完全獨立”，且適配業(yè)務的性能要求。

總結

到此這篇關于Java深拷貝與淺拷貝全維度解析的文章就介紹到這了,更多相關Java深拷貝與淺拷貝內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！