Spring Boot 中的數據持久化方案前面給大夥介紹了兩種了，一個是 JdbcTemplate，還有一個 MyBatis，JdbcTemplate 配置簡單，使用也簡單，但是功能也非常有限，MyBatis 則比較靈活，功能也很強大，據我所知，公司採用 MyBatis 做數據持久化的相當多，但是 MyBatis 並不是唯一的解決方案，除了 MyBatis 之外，還有另外一個東西，那就是 Jpa，松哥也有一些朋友在公司里使用 Jpa 來做數據持久化，本文就和大夥來說說 Jpa 如何實現數據持久化。

Jpa 介紹

首先需要向大夥介紹一下 Jpa，Jpa（Java Persistence API）Java 持久化 API，它是一套 ORM 規範，而不是具體的實現，Jpa 的江湖地位類似於 JDBC，只提供規範，所有的數據庫廠商提供實現（即具體的數據庫驅動），Java 領域，小夥伴們熟知的 ORM 框架可能主要是 Hibernate，實際上，除了 Hibernate 之外，還有很多其他的 ORM 框架，例如：

• Batoo JPA
• DataNucleus (formerly JPOX)
• EclipseLink (formerly Oracle TopLink)
• IBM, for WebSphere Application Server
• JBoss with Hibernate
• Kundera
• ObjectDB
• OpenJPA
• OrientDB from Orient Technologies
• Versant Corporation JPA (not relational, object database)

Hibernate 只是 ORM 框架的一種，上面列出來的 ORM 框架都是支持 JPA2.0 規範的 ORM 框架。既然它是一個規範，不是具體的實現，那麼必然就不能直接使用（類似於 JDBC 不能直接使用，必須要加了驅動才能用），我們使用的是具體的實現，在這裏我們採用的實現實際上還是 Hibernate。

Spring Boot 中使用的 Jpa 實際上是 Spring Data Jpa，Spring Data 是 Spring 家族的一個子項目，用於簡化 SQL、NoSQL 的訪問，在 Spring Data 中，只要你的方法名稱符合規範，它就知道你想幹嘛，不需要自己再去寫 SQL。

關於 Spring Data Jpa 的具體情況，大家可以參考

工程創建

創建 Spring Boot 工程，添加 Web、Jpa 以及 MySQL 驅動依賴，如下：

工程創建好之後，添加 Druid 依賴，完整的依賴如下：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid-spring-boot-starter</artifactId>
    <version>1.1.10</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.28</version>
    <scope>runtime</scope>
</dependency>

如此，工程就算創建成功了。

基本配置

工程創建完成后，只需要在 application.properties 中進行數據庫基本信息配置以及 Jpa 基本配置，如下：

# 數據庫的基本配置
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.url=jdbc:mysql:///test01?useUnicode=true&characterEncoding=UTF-8
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource

# JPA配置
spring.jpa.database=mysql
# 在控制台打印SQL
spring.jpa.show-sql=true
# 數據庫平台
spring.jpa.database-platform=mysql
# 每次啟動項目時，數據庫初始化策略
spring.jpa.hibernate.ddl-auto=update
# 指定默認的存儲引擎為InnoDB
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL57Dialect

注意這裏和 JdbcTemplate 以及 MyBatis 比起來，多了 Jpa 配置，Jpa 配置含義我都註釋在代碼中了，這裏不再贅述，需要強調的是，最後一行配置，默認情況下，自動創建表的時候會使用 MyISAM 做表的引擎，如果配置了數據庫方言為 MySQL57Dialect，則使用 InnoDB 做表的引擎。

好了，配置完成后，我們的 Jpa 差不多就可以開始用了。

基本用法

ORM(Object Relational Mapping) 框架表示對象關係映射，使用 ORM 框架我們不必再去創建表，框架會自動根據當前項目中的實體類創建相應的數據表。因此，我這裏首先創建一個 User 對象，如下：

@Entity(name = "t_user")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;
    @Column(name = "name")
    private String username;
    private String address;
    //省略getter/setter
}

首先 @Entity 註解表示這是一個實體類，那麼在項目啟動時會自動針對該類生成一張表，默認的表名為類名，@Entity 註解的 name 屬性表示自定義生成的表名。@Id 註解表示這個字段是一個 id，@GeneratedValue 註解表示主鍵的自增長策略，對於類中的其他屬性，默認都會根據屬性名在表中生成相應的字段，字段名和屬性名相同，如果開發者想要對字段進行定製，可以使用 @Column 註解，去配置字段的名稱，長度，是否為空等等。

做完這一切之後，啟動 Spring Boot 項目，就會發現數據庫中多了一個名為 t_user 的表了。

針對該表的操作，則需要我們提供一個 Repository，如下：

public interface UserDao extends JpaRepository<User,Integer> {
    List<User> getUserByAddressEqualsAndIdLessThanEqual(String address, Integer id);
    @Query(value = "select * from t_user where id=(select max(id) from t_user)",nativeQuery = true)
    User maxIdUser();
}

這裏，自定義 UserDao 接口繼承自 JpaRepository，JpaRepository 提供了一些基本的數據操作方法，例如保存，更新，刪除，分頁查詢等，開發者也可以在接口中自己聲明相關的方法，只需要方法名稱符合規範即可，在 Spring Data 中，只要按照既定的規範命名方法，Spring Data Jpa 就知道你想幹嘛，這樣就不用寫 SQL 了，那麼規範是什麼呢？參考下圖：

當然，這種方法命名主要是針對查詢，但是一些特殊需求，可能並不能通過這種方式解決，例如想要查詢 id 最大的用戶，這時就需要開發者自定義查詢 SQL 了。

如上代碼所示，自定義查詢 SQL，使用 @Query 註解，在註解中寫自己的 SQL，默認使用的查詢語言不是 SQL，而是 JPQL，這是一種數據庫平台無關的面向對象的查詢語言，有點定位類似於 Hibernate 中的 HQL，在 @Query 註解中設置 nativeQuery 屬性為 true 則表示使用原生查詢，即大夥所熟悉的 SQL。上面代碼中的只是一個很簡單的例子，還有其他一些點，例如如果這個方法中的 SQL 涉及到數據操作，則需要使用 @Modifying 註解。

好了，定義完 Dao 之後，接下來就可以將 UserDao 注入到 Controller 中進行測試了(這裏為了省事，就沒有提供 Service 了，直接將 UserDao 注入到 Controller 中)。

@RestController
public class UserController {
    @Autowired
    UserDao userDao;
    @PostMapping("/")
    public void addUser() {
        User user = new User();
        user.setId(1);
        user.setUsername("張三");
        user.setAddress("深圳");
        userDao.save(user);
    }
    @DeleteMapping("/")
    public void deleteById() {
        userDao.deleteById(1);
    }
    @PutMapping("/")
    public void updateUser() {
        User user = userDao.getOne(1);
        user.setUsername("李四");
        userDao.flush();
    }
    @GetMapping("/test1")
    public void test1() {
        List<User> all = userDao.findAll();
        System.out.println(all);
    }
    @GetMapping("/test2")
    public void test2() {
        List<User> list = userDao.getUserByAddressEqualsAndIdLessThanEqual("廣州", 2);
        System.out.println(list);
    }
    @GetMapping("/test3")
    public void test3() {
        User user = userDao.maxIdUser();
        System.out.println(user);
    }
}

如此之後，即可查詢到需要的數據。

好了，本文的重點是 Spring Boot 和 Jpa 的整合，這個話題就先說到這裏。

多說兩句

在和 Spring 框架整合時，如果用到 ORM 框架，大部分人可能都是首選 Hibernate，實際上，在和 Spring+SpringMVC 整合時，也可以選擇 Spring Data Jpa 做數據持久化方案，用法和本文所述基本是一樣的，Spring Boot 只是將 Spring Data Jpa 的配置簡化了，因此，很多初學者對 Spring Data Jpa 覺得很神奇，但是又覺得無從下手，其實，此時可以回到 Spring 框架，先去學習 Jpa，再去學習 Spring Data Jpa，這是給初學者的一點建議。

相關案例已經上傳到 GitHub，歡迎小夥伴們們下載：

掃碼關注松哥，公眾號後台回復 2TB，獲取松哥獨家 超2TB 學習資源

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

※小三通物流營運型態?

※快速運回,大陸空運推薦?

前言

開發多頁應用的時候，如果不對webpack打包進行優化，當某個模塊被多個入口模塊引用時，它就會被打包多次（在最終打包出來的某幾個文件里，它們都會有一份相同的代碼）。當項目業務越來越複雜，打包出來的代碼會非常冗餘，文件體積會非常龐大。大體積文件會增加編譯時間，影響開發效率；如果直接上線，還會拉長請求和加載時長，影響網站體驗。作為一個追求極致體驗的攻城獅，是不能忍的。所以在多頁應用中優化打包尤為必要。那麼如何優化webpack打包呢？

一、概念

在一切開始前，有必要先理清一下這三個概念：

• module: 模塊，在webpack眼裡，任何可以被導入導出的文件都是一個模塊。
• chunk: chunk是webpack拆分出來的：
  • 每個入口文件都是一個chunk
  • 通過 import、require 引入的代碼也是
  • 通過 splitChunks 拆分出來的代碼也是
• bundle: webpack打包出來的文件，也可以理解為就是對chunk編譯壓縮打包等處理后的產出。

二、問題分析

首先，簡單分析下，我們剛才提到的打包問題：

• 核心問題就是：多頁應用打包後代碼冗餘，文件體積大。
• 究其原因就是：相同模塊在不同入口之間沒有得到復用，bundle之間比較獨立。

弄明白了問題的原因，那麼大致的解決思路也就出來了：

• 我們在打包的時候，應該把不同入口之間，共同引用的模塊，抽離出來，放到一個公共模塊中。這樣不管這個模塊被多少個入口引用，都只會在最終打包結果中出現一次。——解決代碼冗餘。
• 另外，當我們把這些共同引用的模塊都堆在一個模塊中，這個文件可能異常巨大，也是不利於網絡請求和頁面加載的。所以我們需要把這個公共模塊再按照一定規則進一步拆分成幾個模塊文件。——減小文件體積。
• 至於如何拆分，方式因人而異，因項目而異。我個人的拆分原則是：
  • 業務代碼和第三方庫分離打包，實現代碼分割；
  • 業務代碼中的公共業務模塊提取打包到一個模塊；
  • 第三方庫最好也不要全部打包到一個文件中，因為第三方庫加起來通常會很大，我會把一些特別大的庫分別獨立打包，剩下的加起來如果還很大，就把它按照一定大小切割成若干模塊。

optimization.splitChunks

webpack提供了一個非常好的內置插件幫我們實現這一需求：CommonsChunkPlugin。不過在 webpack4 中CommonsChunkPlugin被刪除，取而代之的是optimization.splitChunks, 所幸的是optimization.splitChunks更強大！

三、 實現

通過一個多頁應用的小demo，我們一步一步來實現上述思路的配置。

demo目錄結構：

|--public/
|   |--a.html
|   |--index.html
|--src/
|   |--a.js
|   |--b.js
|   |--c.js
|   |--index.js
|--package.json
|--webpack.config.js

代碼邏輯很簡單，index模塊中引用了 a 和 b 2個模塊，a 模塊中引用了 c 模塊和 jquery庫，b 模塊中也引用了 c 模塊和 jquery 庫，c 是一個獨立的模塊沒有其他依賴。

index.js代碼如下：

//index.js
import a from './a.js';
import b from './b.js';
function fn() {
    console.log('index-------');
}
fn();

a.js代碼如下：

//a.js
require('./c.js');
const $ = require('jquery')
function fn() {
    console.log('a-------');
}
module.exports = fn();

b.js代碼如下：

//b.js
require('./c.js');
const $ = require('jquery')
function fn() {
    console.log('b-------');
}
module.exports = fn();

c.js代碼如下：

//c.js
function fn() {
    console.log('c-------');
}
module.exports = fn();

1. 基本配置

webpack先不做優化，只做基本配置，看看效果。項目配置了2個入口，搭配html-webpack-plugin實現多頁打包：

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
    entry: {
        index: './src/index.js',
        a: './src/a.js'
    },
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: '[name].js'
    },
    plugins: [
        new HtmlWebpackPlugin({
            template: './public/index.html',
            filename: 'index.html'
        }),
        new HtmlWebpackPlugin({
            template: './public/a.html',
            filename: 'a.html'
        })
    ]
}

在開發模式下運行webpack：

可以看到，打包出兩個html和兩個體積很大的（300多K）的文件a.js,index.js。

進入dist目錄檢查js文件：

• a.js里包含c模塊代碼和jquery代碼
• index.js里包含a模塊、b模塊、c模塊和jquery代碼

看，同樣的代碼c和jquery被打包了2遍。

2. 初步添加splitChunks優化配置

首先解決相同代碼打包2次的問題，我們需要讓webpack把c和jquery提取出來打包為公共模塊。

在webpack配置文件添加splitChunks：

//webpack.config.js

optimization: {
    splitChunks: {
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial'
            }
        }
    }
}

– cacheGroups

• cacheGroups是splitChunks配置的核心，對代碼的拆分規則全在cacheGroups緩存組裡配置。
• 緩存組的每一個屬性都是一個配置規則，我這裏給他的default屬性進行了配置，屬性名可以不叫default可以自己定。
• 屬性的值是一個對象，裏面放的我們對一個代碼拆分規則的描述。

– name

• name：提取出來的公共模塊將會以這個來命名，可以不配置，如果不配置，就會生成默認的文件名，大致格式是index～a.js這樣的。

– chunks

• chunks：指定哪些類型的chunk參与拆分，值可以是string可以是函數。如果是string，可以是這個三個值之一：all, async, initial，all 代表所有模塊，async代表只管異步加載的, initial代表初始化時就能獲取的模塊。如果是函數，則可以根據chunk參數的name等屬性進行更細緻的篩選。

再次打包：

可以看到a.js,index.js從300多K減少到6點幾K。同時增加了一個common.js文件，並且兩個打包入口都自動添加了common.js這個公共模塊：

進入dist目錄，依次查看這3個js文件：

• a.js里不包含任何模塊的代碼了，只有webpack生成的默認代碼。
• index.js里同樣不包含任何模塊的代碼了，只有webpack生成的默認代碼。
• common.js里有a,b,c,index,jquery代碼。

發現，提是提取了，但是似乎跟我們預料的不太一樣，所有的模塊都跑到common.js里去了。

這是因為我們沒有告訴webpack（splitChunks）什麼樣的代碼為公共代碼，splitChunks默認任何模塊都會被提取。

– minChunks

splitChunks是自帶默認配置的，而緩存組默認會繼承這些配置，其中有個minChunks屬性：

• 它控制的是每個模塊什麼時候被抽離出去：當模塊被不同entry引用的次數大於等於這個配置值時，才會被抽離出去。
• 它的默認值是1。也就是任何模塊都會被抽離出去（入口模塊其實也會被webpack引入一次）。

我們上面沒有配置minChunks，只配置了name和chunk兩個屬性，所以minChunks的默認值 1 生效。也難怪所有的模塊都被抽離到common.js中了。

優化一下，在緩存組裡配置minChunks覆蓋默認值：

//webpack.config.js

optimization: {
    splitChunks: {
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial',
                minChunks: 2  //模塊被引用2次以上的才抽離
            }
        }
    }
}

然後運行webpack

可以看到有2個文件的大小發生了變化：common.js由314K減小到311K，index.js由6.22K增大到7.56K。

進入dist目錄查看：

• a.js里依然不包含任何模塊的代碼（正常，因為a作為模塊被index引入了一次，又作為入口被webpack引入了一次，所以a是有2次引用的）。
• index.js里出現了b和index模塊的代碼了。
• common.js里只剩a,c,和jquery模塊的代碼。

現在我們把共同引用的模塊a, c, jquery，從a和index這兩個入口模塊里抽取到common.js里了。有點符合我們的預期了。

3. 配置多個拆分規則

3.1 實現代碼分離，拆分第三方庫

接下來，我希望公共模塊common.js中，業務代碼和第三方模塊jquery能夠剝離開來。

我們需要再添加一個拆分規則。

//webpack.config.js

optimization: {
    splitChunks: {
        minSize: 30,  //提取出的chunk的最小大小
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial',
                minChunks: 2,  //模塊被引用2次以上的才抽離
                priority: -20
            },
            vendors: {  //拆分第三方庫（通過npm|yarn安裝的庫）
                test: /[\\/]node_modules[\\/]/,
                name: 'vendor',
                chunks: 'initial',
                priority: -10
            }
        }
    }
}

我給cacheGroups添加了一個vendors屬性（屬性名可以自己取，只要不跟緩存組下其他定義過的屬性同名就行，否則後面的拆分規則會把前面的配置覆蓋掉）。

– minSize

minSize設置的是生成文件的最小大小，單位是字節。如果一個模塊符合之前所說的拆分規則，但是如果提取出來最後生成文件大小比minSize要小，那它仍然不會被提取出來。這個屬性可以在每個緩存組屬性中設置，也可以在splitChunks屬性中設置，這樣在每個緩存組都會繼承這個配置。這裏由於我的demo中文件非常小，為了演示效果，我把minSize設置為30字節，好讓公共模塊可以被提取出來，正常項目中不用設這麼小。

– priority

priority屬性的值為数字，可以為負數。作用是當緩存組中設置有多個拆分規則，而某個模塊同時符合好幾個規則的時候，則需要通過優先級屬性priority來決定使用哪個拆分規則。優先級高者執行。我這裏給業務代碼組設置的優先級為-20，給第三方庫組設置的優先級為-10，這樣當一個第三方庫被引用超過2次的時候，就不會打包到業務模塊里了。

– test

test屬性用於進一步控制緩存組選擇的模塊，與chunks屬性的作用有一點像，但是維度不一樣。test的值可以是一個正則表達式，也可以是一個函數。它可以匹配模塊的絕對資源路徑或chunk名稱，匹配chunk名稱時，將選擇chunk中的所有模塊。我這裏用了一個正則/[\\/]node_modules[\\/]/來匹配第三方模塊的絕對路徑，因為通過npm或者yarn安裝的模塊，都會存放在node_modules目錄下。

運行一下webpack：

可以看到新產生了一個叫vendor.js的文件（name屬性的值），同時common.js文件體積由原來的311k減少到了861bytes！

進入dist目錄，檢查js文件：

• a.js里不包含任何模塊代碼。
• common.js只包含a和c模塊的代碼。
• index.js只包含b和index模塊的代碼。
• vendor.js只包含jquery模塊的代碼。

現在，我們在上一步的基礎上，成功從common.js里把第三方庫jquery抽離出來放到了vendor.js里。

3.2 拆分指定文件

如果我們還想把項目中的某一些文件單獨拎出來打包（比如工程本地開發的組件庫），可以繼續添加拆分規則。比如我的src下有個locallib.js文件要單獨打包，假設a.js中引入了它。

//a.js
require('./c.js');
require('./locallib.js');  //引入自己本地的庫
const $ = require('jquery')
function fn() {
    console.log('a-------');
}
module.exports = fn();

可以這麼配置：

//webpack.config.js

optimization: {
    splitChunks: {
        minSize: 30,  //提取出的chunk的最小大小
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial',
                minChunks: 2,  //模塊被引用2次以上的才抽離
                priority: -20
            },
            vendors: {  //拆分第三方庫（通過npm|yarn安裝的庫）
                test: /[\\/]node_modules[\\/]/,
                name: 'vendor',
                chunks: 'initial',
                priority: -10
            },
            locallib: {  //拆分指定文件
                test: /(src\/locallib\.js)$/,
                name: 'locallib',
                chunks: 'initial',
                priority: -9
            }
        }
    }
}

我在緩存組下又新增了一個拆分規則，通過test正則指定我就要單獨打包src/locallib.js文件，並且把優先級設置為-9，這樣當它被多次引用時，不會進入其他拆分規則組，因為另外兩個規則的優先級都比它要低。

運行webpack打包后：

可以看到新產生了一個locallib.js文件。進入dist目錄查看：

• a.js里不包含任何模塊代碼。
• common.js只包含a和c模塊的代碼。
• index.js只包含b和index模塊的代碼。
• vendor.js只包含jquery模塊的代碼。
• locallib.js里只包含locallib模塊的代碼。

現在我們又在上一步的基礎上獨立打包了一個指定的模塊locallib.js。

至此，我們就成功實現了抽離公共模塊、業務代碼和第三方代碼剝離、獨立打包指定模塊。

對比一下，優化前，打包出來js一共有633KB：

優化后，打包出來js一共不到330KB：

優化打包后的文件分類清晰，體積比優化前縮小了幾乎50%，有點小完美是不是！擊掌！這還只是我舉的一個簡單例子，在實際多頁應用中，優化力度說不定還不止這麼多。

小結

webpack很強大，以上只是冰山一角，但是只要掌握了上述optimization.splitChunks的核心配置，我們就可以幾乎隨心所欲地按照自己的想法來拆分優化代碼控制打包文件了，是不是很酷？玩轉代碼拆分，你也可以！

如果覺得這些依然不能滿足你的需求，還想更精(bian)細(tai)地定製打包規則，可以到查看optimization.splitChunks的更多配置。

歡迎交流～

本文的完整webpack配置和demo源碼可以在這裏獲取：

—

歡迎轉載，轉載請註明出處：

本文同步發表於：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※台灣寄大陸海運貨物規則及重量限制?

※大陸寄台灣海運費用試算一覽表

 一.安裝Prism

1.使用程序包管理控制台

Install-Package Prism.Unity -Version 7.2.0.1367

也可以去掉‘-Version 7.2.0.1367’獲取最新的版本

 2.使用管理解決方案的Nuget包

在上面或許我們有個疑問？為啥安裝prism會跟Prism.Unity有關係，我們知道Unity是個IOC容器,而Prism本身就支持IOC,且目前官方支持幾種IOC容器：

1.且unity由於是微軟官方的，且支持prism的組件化，由此我推薦使用prism.unity，在官方文檔中prism7不支持prism.Mef，Prism 7.1將不支持prism.Autofac 2.安裝完prism.unity就已經包含着所有prism的核心庫了，架構如下：

二.實現數據綁定

我們先創建Views文件夾和ViewModels文件夾，將MainWindow放在Views文件夾下，再在ViewModels文件夾下面創建MainWindowViewModel類，如下：

 

xmal代碼如下：

<Window x:Class="PrismSample.Views.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:prism="http://prismlibrary.com/"
        xmlns:local="clr-namespace:PrismSample"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800" prism:ViewModelLocator.AutoWireViewModel="True">
    <StackPanel>
        <TextBox Text="{Binding Text}" Margin="10" Height="100" FontSize="50" Foreground="Black" BorderBrush="Black"/>
        <Button  Height="100" Width="300" Content="Click Me" FontSize="50" Command="{Binding ClickCommnd}"/>
    </StackPanel>
</Window>

ViewModel代碼如下：

using Prism.Commands;
using Prism.Mvvm;

namespace PrismSample.ViewModels
{
   public class MainWindowViewModel:BindableBase
    {
        private string _text;
        public string Text
        {
            get { return _text; }
            set { SetProperty(ref _text, value); }
        }

        private DelegateCommand _clickCommnd;
        public DelegateCommand ClickCommnd =>
            _clickCommnd ?? (_clickCommnd = new DelegateCommand(ExecuteClickCommnd));

        void ExecuteClickCommnd()
        {
            this.Text = "Click Me！";
        }

        public MainWindowViewModel()
        {
            this.Text = "Hello Prism!";
        }
    }
}

啟動程序：

  點擊 click Me 按鈕:

可以看到，我們已經成功的用prism實現數據綁定了，且View和ViewModel完美的前後端分離

但是現在我們又引出了另外一個問題,當我們不想按照prism的規定硬要將View和ViewModel放在Views和ViewModels裏面，又或許自己的項目取名規則各不相同怎麼辦，這時候就要用到另外幾種方法：

1.更改命名規則

如果，公司命名規則很變態，導致項目結構變成這樣(這種公司辭職了算了)：

首先我們在App需要引入prism，修改‘Application’為‘prism:PrismApplication’且刪除StartupUri xmal代碼如下：  

<prism:PrismApplication x:Class="PrismSample.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:prism="http://prismlibrary.com/"
             xmlns:local="clr-namespace:PrismSample">
    <Application.Resources>
         
    </Application.Resources>
</prism:PrismApplication>

  cs後台代碼如下：

using Prism.Unity;
using Prism.Ioc;
using Prism.Mvvm;
using System.Windows;
using PrismSample.Viewsb;
using System;
using System.Reflection;

namespace PrismSample
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : PrismApplication
    {
        //設置啟動起始頁
        protected override Window CreateShell()
        {
            return Container.Resolve<MainWindow>();
        }

        protected override void RegisterTypes(IContainerRegistry containerRegistry)
        {

        }

        //配置規則
        protected override void ConfigureViewModelLocator()
        {
            base.ConfigureViewModelLocator();
            ViewModelLocationProvider.SetDefaultViewTypeToViewModelTypeResolver((viewType) =>
            {
                var viewName = viewType.FullName.Replace(".Viewsb.", ".ViewModelsa.OhMyGod.");
                var viewAssemblyName = viewType.GetTypeInfo().Assembly.FullName;
                var viewModelName = $"{viewName}Test, {viewAssemblyName}";
                return Type.GetType(viewModelName);
            });
        }
    }
}

上面這兩句是關鍵：

“.Viewsb.” 表示View所在文件夾namespace,”.ViewModelsa.OhMyGod.” 表示ViewModel所在namespace

var viewName = viewType.FullName.Replace(".Viewsb.", ".ViewModelsa.OhMyGod.");

Test表示ViewModel後綴

var viewModelName = $"{viewName}Test, {viewAssemblyName}";

2.自定義ViewModel註冊

我們新建一個Foo類作為自定義類，代碼如下：

using Prism.Commands;
using Prism.Mvvm;

namespace PrismSample
{
   public class Foo:BindableBase
    {

        private string _text;
        public string Text
        {
            get { return _text; }
            set { SetProperty(ref _text, value); }
        }

        public Foo()
        {
            this.Text = "Foo";
        }

        private DelegateCommand _clickCommnd;
        public DelegateCommand ClickCommnd =>
            _clickCommnd ?? (_clickCommnd = new DelegateCommand(ExecuteClickCommnd));

        void ExecuteClickCommnd()
        {
            this.Text = "Oh My God！";
        }
    }
}

修改App.cs代碼:

protected override void ConfigureViewModelLocator()
        {
            base.ConfigureViewModelLocator();
            ViewModelLocationProvider.Register<MainWindow, Foo>();
            //ViewModelLocationProvider.SetDefaultViewTypeToViewModelTypeResolver((viewType) =>
            //{
            //    var viewName = viewType.FullName.Replace(".Viewsb.", ".ViewModelsa.OhMyGod.");
            //    var viewAssemblyName = viewType.GetTypeInfo().Assembly.FullName;
            //    var viewModelName = $"{viewName}Test, {viewAssemblyName}";
            //    return Type.GetType(viewModelName);
            //});
        }

  運行：   點擊按鈕：  

就算是不註釋修改命名規則的代碼，我們發現運行結果還是一樣，因此我們可以得出結論，

這種直接的，不通過反射註冊的自定義註冊方式優先級會高點，在官方文檔也說明這種方式效率會高點

且官方提供4種方式，其餘三種的註冊方式如下：

ViewModelLocationProvider.Register(typeof(MainWindow).ToString(), typeof(MainWindowTest)); 

ViewModelLocationProvider.Register(typeof(MainWindow).ToString(), () => Container.Resolve<Foo>());

ViewModelLocationProvider.Register<MainWindow>(() => Container.Resolve<Foo>());

 本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

※小三通物流營運型態?

※快速運回,大陸空運推薦?

1. synchronized使用

1.1 synchronized介紹

在多線程併發編程中synchronized一直是元老級角色，很多人都會稱呼它為重量級鎖。但是，隨着Java SE 1.6對synchronized進行了各種優化之後，有些情況下它就並不那麼重了。

synchronized可以修飾普通方法，靜態方法和代碼塊。當synchronized修飾一個方法或者一個代碼塊的時候，它能夠保證在同一時刻最多只有一個線程執行該段代碼。

• 對於普通同步方法，鎖是當前實例對象（不同實例對象之間的鎖互不影響）。

• 對於靜態同步方法，鎖是當前類的Class對象。

• 對於同步方法塊，鎖是Synchonized括號里配置的對象。

當一個線程試圖訪問同步代碼塊時，它首先必須得到鎖，退出或拋出異常時必須釋放鎖。

1.2 使用場景

synchronized最常用的使用場景就是多線程併發編程時線程的同步。這邊還是舉一個最常用的列子：多線程情況下銀行賬戶存錢和取錢的列子。

public class SynchronizedDemo {


    public static void main(String[] args) {
        BankAccount myAccount = new BankAccount("accountOfMG",10000.00);
        for(int i=0;i<100;i++){
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        int var = new Random().nextInt(100);
                        Thread.sleep(var);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    double deposit = myAccount.deposit(1000.00);
                    System.out.println(Thread.currentThread().getName()+" balance:"+deposit);
                }
            }).start();
        }
        for(int i=0;i<100;i++){
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        int var = new Random().nextInt(100);
                        Thread.sleep(var);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    double deposit = myAccount.withdraw(1000.00);
                    System.out.println(Thread.currentThread().getName()+" balance:"+deposit);

                }
            }).start();
        }
    }

    private static class BankAccount{
        String accountName;
        double balance;

        public BankAccount(String accountName,double balance){
            this.accountName = accountName;
            this.balance = balance;
        }

        public double deposit(double amount){
            balance = balance + amount;
            return balance;
        }

        public double  withdraw(double amount){
            balance = balance - amount;
            return balance;
        }

    }
}

上面的列子中，首先初始化了一個銀行賬戶，賬戶的餘額是10000.00，然後開始了200個線程，其中100個每次向賬戶中存1000.00，另外100個每次從賬戶中取1000.00。如果正常執行的話，賬戶中應該還是10000.00。但是我們執行多次這段代碼，會發現執行結果基本上都不是10000.00，而且每次結果 都是不一樣的。

出現上面這種結果的原因就是：在多線程情況下，銀行賬戶accountOfMG是一個共享變量，對共享變量進行修改如果不做線程同步的話是會存在線程安全問題的。比如說現在有兩個線程同時要對賬戶accountOfMG存款1000，一個線程先拿到賬戶的當前餘額，並且將餘額加上1000。但是還沒將餘額的值刷新回賬戶，另一個線程也來做相同的操作。此時賬戶餘額還是沒加1000之前的值，所以當兩個線程執行完畢之後，賬戶加的總金額還是只有1000。

synchronized就是Java提供的一種線程同步機制。使用synchronized我們可以非常方便地解決上面的銀行賬戶多線程存錢取錢問題，只需要使用synchronized修飾存錢和取錢方法即可：

private static class BankAccount{
        String accountName;
        double balance;

        public BankAccount(String accountName,double balance){
            this.accountName = accountName;
            this.balance = balance;
        }
        //這邊給出一個編程建議：當我們對共享變量進行同步時，同步代碼塊最好在共享變量中加
        public synchronized double deposit(double amount){
            balance = balance + amount;
            return balance;
        }
        
        public synchronized double  withdraw(double amount){
            balance = balance - amount;
            return balance;
        }

    }

2. Java對象頭

上面提到，當線程進入synchronized方法或者代碼塊時需要先獲取鎖，退出時需要釋放鎖。那麼這個鎖信息到底存在哪裡呢？

Java對象保存在內存中時，由以下三部分組成：

• 對象頭
• 實例數據
• 對齊填充字節

而對象頭又由下面幾部分組成：

• Mark Word
• 指向類的指針
• 數組長度（只有數組對象才有）

1. Mark Word
Mark Word記錄了對象和鎖有關的信息，當這個對象被synchronized關鍵字當成同步鎖時，圍繞這個鎖的一系列操作都和Mark Word有關。Mark Word在32位JVM中的長度是32bit，在64位JVM中長度是64bit。

Mark Word在不同的鎖狀態下存儲的內容不同，在32位JVM中是這麼存的：

其中無鎖和偏向鎖的鎖標誌位都是01，只是在前面的1bit區分了這是無鎖狀態還是偏向鎖狀態。Epoch是指偏向鎖的時間戳。

JDK1.6以後的版本在處理同步鎖時存在鎖升級的概念，JVM對於同步鎖的處理是從偏向鎖開始的，隨着競爭越來越激烈，處理方式從偏向鎖升級到輕量級鎖，最終升級到重量級鎖。

JVM一般是這樣使用鎖和Mark Word的：

• step1:當沒有被當成鎖時，這就是一個普通的對象，Mark Word記錄對象的HashCode，鎖標誌位是01，是否偏向鎖那一位是0。

• step2:當對象被當做同步鎖並有一個線程A搶到了鎖時，鎖標誌位還是01，但是否偏向鎖那一位改成1，前23bit記錄搶到鎖的線程id，表示進入偏向鎖狀態。

• step3:當線程A再次試圖來獲得鎖時，JVM發現同步鎖對象的標誌位是01，是否偏向鎖是1，也就是偏向狀態，Mark Word中記錄的線程id就是線程A自己的id，表示線程A已經獲得了這個偏向鎖，可以執行同步鎖的代碼。

• step4:當線程B試圖獲得這個鎖時，JVM發現同步鎖處於偏向狀態，但是Mark Word中的線程id記錄的不是B，那麼線程B會先用CAS操作試圖獲得鎖，這裏的獲得鎖操作是有可能成功的，因為線程A一般不會自動釋放偏向鎖。如果搶鎖成功，就把Mark Word里的線程id改為線程B的id，代表線程B獲得了這個偏向鎖，可以執行同步鎖代碼。如果搶鎖失敗，則繼續執行步驟5。

• step5:偏向鎖狀態搶鎖失敗，代表當前鎖有一定的競爭，偏向鎖將升級為輕量級鎖。JVM會在當前線程的線程棧中開闢一塊單獨的空間，裏面保存指向對象鎖Mark Word的指針，同時在對象鎖Mark Word中保存指向這片空間的指針。上述兩個保存操作都是CAS操作，如果保存成功，代表線程搶到了同步鎖，就把Mark Word中的鎖標誌位改成00，可以執行同步鎖代碼。如果保存失敗，表示搶鎖失敗，競爭太激烈，繼續執行步驟6。

• step6:輕量級鎖搶鎖失敗，JVM會使用自旋鎖，自旋鎖不是一個鎖狀態，只是代表不斷的重試，嘗試搶鎖。從JDK1.7開始，自旋鎖默認啟用，自旋次數由JVM決定。如果搶鎖成功則執行同步鎖代碼，如果失敗則繼續執行步驟7。

• step7:自旋鎖重試之後如果搶鎖依然失敗，同步鎖會升級至重量級鎖，鎖標誌位改為10。在這個狀態下，未搶到鎖的線程都會被阻塞。

2. 指向類的指針
該指針在32位JVM中的長度是32bit，在64位JVM中長度是64bit。Java對象的類數據保存在方法區。

3. 數組長度
只有數組對象保存了這部分數據。該數據在32位和64位JVM中長度都是32bit。

synchronized對鎖的優化

Java 6中為了減少獲得鎖和釋放鎖帶來的性能消耗，引入了“偏向鎖”和“輕量級鎖”的概念。在Java 6中，鎖一共有4種狀態，級別從低到高依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態和重量級鎖狀態，這幾個狀態會隨着競爭情況逐漸升級。鎖可以升級但不能降級，意味着偏向鎖升級成輕量級鎖后不能降級成偏向鎖。

在聊偏向鎖、輕量級鎖和重量級鎖之前我們先來聊下鎖的宏觀分類。鎖從宏觀上來分類，可以分為悲觀鎖與樂觀鎖。注意，這裏說的的鎖可以是數據庫中的鎖，也可以是Java等開發語言中的鎖技術。悲觀鎖和樂觀鎖其實只是一類概念（對某類具體鎖的總稱），不是某種語言或是某個技術獨有的鎖技術。

樂觀鎖是一種樂觀思想，即認為讀多寫少，遇到併發寫的可能性低，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，採取在寫時先讀出當前版本號，然後加鎖操作（比較跟上一次的版本號，如果一樣則更新），如果失敗則要重複讀-比較-寫的操作。java中的樂觀鎖基本都是通過CAS操作實現的，CAS是一種更新的原子操作，比較當前值跟傳入值是否一樣，一樣則更新，否則失敗。數據庫中的共享鎖也是一種樂觀鎖。

悲觀鎖是就是悲觀思想，即認為寫多，遇到併發寫的可能性高，每次去拿數據的時候都認為別人會修改，所以每次在讀寫數據的時候都會上鎖，這樣別人想讀寫這個數據就會block直到拿到鎖。java中典型的悲觀鎖就是Synchronized,AQS框架下的鎖則是先嘗試cas樂觀鎖去獲取鎖，獲取不到，才會轉換為悲觀鎖，如ReentrantLock。數據庫中的排他鎖也是一種悲觀鎖。

偏向鎖

Java 6之前的synchronized會導致爭用不到鎖的線程進入阻塞狀態，線程在阻塞狀態和runnbale狀態之間切換是很耗費系統資源的，所以說它是java語言中一個重量級的同步操縱，被稱為重量級鎖。為了緩解上述性能問題，Java 6開始，引入了輕量鎖與偏向鎖，默認啟用了自旋，他們都屬於樂觀鎖。

偏向鎖更準確的說是鎖的一種狀態。在這種鎖狀態下，系統中只有一個線程來爭奪這個鎖。線程只要簡單地通過Mark Word中存放的線程ID和自己的ID是否一致就能拿到鎖。下面簡單介紹下偏向鎖獲取和升級的過程。

還是就着這張圖講吧，會清楚點。

當系統中還沒有訪問過synchronized代碼時，此時鎖的狀態肯定是“無鎖狀態”，也就是說“是否是偏向鎖”的值是0，“鎖標誌位”的值是01。此時有一個線程1來訪問同步代碼，發現鎖對象的狀態是”無鎖狀態”，那麼操作起來非常簡單了，只需要將“是否偏向鎖”標誌位改成1，再將線程1的線程ID寫入Mark Word即可。

如果後續系統中一直只有線程1來拿鎖，那麼只要簡單的判斷下線程1的ID和Mark Word中的線程ID，線程1就能非常輕鬆地拿到鎖。但是現實往往不是那麼簡單的，現在假設線程2也要來競爭同步鎖，我們看下情況是怎麼樣的。

• step1：線程2首先根據“是否是偏向鎖”和“鎖標誌位”的值判斷出當前鎖的狀態是“偏向鎖”狀態，但是Mark Word中的線程ID又不是指向自己（此時線程ID還是指向線程1），所以此時回去判斷線程1還是否存在；
• step2：假如此時線程1已經不存在了，線程2會將Mark Word中的線程ID指向自己的線程ID，鎖不升級，仍為偏向鎖；
• step3：假如此時線程1還存在（線程1還沒執行完同步代碼，【不知道這樣理解對不對，姑且先這麼理解吧】），首先暫停線程1，設置鎖標誌位為00，鎖升級為“輕量級鎖”，繼續執行線程1的代碼；線程2通過自旋操作來繼續獲得鎖。

在JDK6中，偏向鎖是默認啟用的。它提高了單線程訪問同步資源的性能。但試想一下，如果你的同步資源或代碼一直都是多線程訪問的，那麼消除偏向鎖這一步驟對你來說就是多餘的。事實上，消除偏向鎖的開銷還是蠻大的。
所以在你非常熟悉自己的代碼前提下，大可禁用偏向鎖:

 -XX:-UseBiasedLocking=false

輕量級鎖

“輕量級鎖”鎖也是一種鎖的狀態，這種鎖狀態的特點是：當一個線程來競爭鎖失敗時，不會立即進入阻塞狀態，而是會進行一段時間的鎖自旋操作，如果自旋操作拿鎖成功就執行同步代碼，如果經過一段時間的自旋操作還是沒拿到鎖，線程就進入阻塞狀態。

1. 輕量級鎖加鎖流程
線程在執行同步塊之前，JVM會先在當前線程的棧楨中創建用於存儲鎖記錄的空間，並將對象頭中的Mark Word複製到鎖記錄中，官方稱為Displaced Mark Word。然後線程嘗試使用CAS將對象頭中的Mark Word替換為指向鎖記錄的指針。如果成功，當前線程獲得鎖，如果失敗，表示其他線程競爭鎖，當前線程便嘗試使用自旋來獲取鎖。

2. 輕量級鎖解鎖流程
輕量級解鎖時，會使用原子的CAS操作將Displaced Mark Word替換回到對象頭，如果成功，則表示沒有競爭發生。如果失敗，表示當前鎖存在競爭，鎖就會膨脹成重量級鎖。

重量級鎖

因為自旋會消耗CPU，為了避免無用的自旋（比如獲得鎖的線程被阻塞住了），一旦鎖升級成重量級鎖，就不會再恢復到輕量級鎖狀態。當鎖處於這個狀態下，其他線程試圖獲取鎖時，都會被阻塞住，當持有鎖的線程釋放鎖之後會喚醒這些線程，被喚醒的線程就會進行新一輪的奪鎖之爭。

鎖自旋

自旋鎖原理非常簡單，如果持有鎖的線程能在很短時間內釋放鎖資源，那麼那些等待競爭鎖的線程就不需要做內核態和用戶態之間的切換進入阻塞掛起狀態，它們只需要等一等（自旋），等持有鎖的線程釋放鎖后即可立即獲取鎖，這樣就避免用戶線程和內核的切換的消耗。

但是線程自旋是需要消耗CPU的，說白了就是讓CPU在做無用功，線程不能一直佔用CPU自旋做無用功，所以需要設定一個自旋等待的最大時間。如果持有鎖的線程執行的時間超過自旋等待的最大時間扔沒有釋放鎖，就會導致其它爭用鎖的線程在最大等待時間內還是獲取不到鎖，這時爭用線程會停止自旋進入阻塞狀態。

自旋鎖盡可能的減少線程的阻塞，這對於鎖的競爭不激烈，且佔用鎖時間非常短的代碼塊來說性能能大幅度的提升，因為自旋的消耗會小於線程阻塞掛起操作的消耗！但是如果鎖的競爭激烈，或者持有鎖的線程需要長時間佔用鎖執行同步塊，這時候就不適合使用自旋鎖了，因為自旋鎖在獲取鎖前一直都是佔用cpu做無用功，線程自旋的消耗大於線程阻塞掛起操作的消耗，其它需要cup的線程又不能獲取到cpu，造成cpu的浪費。

JDK7之後，鎖的自旋特性都是由JVM自身控制的，不需要我們手動配置。

鎖對比

鎖的優化

• 減少鎖的時間：不需要同步的代碼不加鎖；
• 使用讀寫鎖：讀操作加讀鎖，可以併發讀，寫操作使用寫鎖，只能單線程寫；
• 鎖粗化：假如有一個循環，循環內的操作需要加鎖，我們應該把鎖放到循環外面，否則每次進出循環，都進出一次臨界區，效率是非常差的；

參考

• https://blog.csdn.net/lkforce/article/details/81128115
• 《併發編程藝術》

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※台灣寄大陸海運貨物規則及重量限制?

※大陸寄台灣海運費用試算一覽表