Java多线程编程—锁优化

并发环境下进行编程时,需要使用锁机制来同步多线程间的操作,保证共享资源的互斥访问。加锁会带来性能上的损坏,似乎是众所周知的事情。然而,加锁本身不会带来多少的性能消耗,性能主要是在线程的获取锁的过程。如果只有一个线程竞争锁,此时并不存在多线程竞争的情况,那么JVM会进行优化,那么这时加锁带来的性能消耗基本可以忽略。因此,规范加锁的操作,优化锁的使用方法,避免不必要的线程竞争,不仅可以提高程序性能,也能避免不规范加锁可能造成线程死锁问题,提高程序健壮性。下面阐述几种锁优化的思路。

一、尽量不要锁住方法

在普通成员函数上加锁时,线程获得的是该方法所在对象的对象锁。此时整个对象都会被锁住。这也意味着,如果这个对象提供的多个同步方法是针对不同业务的,那么由于整个对象被锁住,一个业务业务在处理时,其他不相关的业务线程也必须wait。下面的例子展示了这种情况:

LockMethod类包含两个同步方法,分别在两种业务处理中被调用:

public class LockMethod   {
    public synchronized void busiA() {
        for (int i = 0; i < 10000; i++) {
            System.out.println(Thread.currentThread().getName() + "deal with bussiness A:"+i);
        }
    }
    public synchronized void busiB() {
        for (int i = 0; i < 10000; i++) {
            System.out.println(Thread.currentThread().getName() + "deal with bussiness B:"+i);
        }
    }
}

BUSSA是线程类,用来处理A业务,调用的是LockMethod的busiA()方法:

public class BUSSA extends Thread {
    LockMethod lockMethod;
    void deal(LockMethod lockMethod){
        this.lockMethod = lockMethod;
    }

    @Override
    public void run() {
        super.run();
        lockMethod.busiA();
    }
}

BUSSB是线程类,用来处理B业务,调用的是LockMethod的busiB()方法:

public class BUSSB extends Thread {
    LockMethod lockMethod;
    void deal(LockMethod lockMethod){
        this.lockMethod = lockMethod;
    }

    @Override
    public void run() {
        super.run();
        lockMethod.busiB();
    }
}

TestLockMethod类,使用线程BUSSA与BUSSB进行业务处理:

public class TestLockMethod extends Thread {

    public static void main(String[] args) {
        LockMethod lockMethod = new LockMethod();
        BUSSA bussa = new BUSSA();
        BUSSB bussb = new BUSSB();
        bussa.deal(lockMethod);
        bussb.deal(lockMethod);
        bussa.start();
        bussb.start();

    }
}

运行程序,可以看到在线程bussa 执行的过程中,bussb是不能够进入函数 busiB()的,因为此时lockMethod 的对象锁被线程bussa获取了。

二、缩小同步代码块,只锁数据

有时候为了编程方便,有些人会synchnoized很大的一块代码,如果这个代码块中的某些操作与共享资源并不相关,那么应当把它们放到同步块外部,避免长时间的持有锁,造成其他线程一直处于等待状态。尤其是一些循环操作、同步I/O操作。不止是在代码的行数范围上缩小同步块,在执行逻辑上,也应该缩小同步块,例如多加一些条件判断,符合条件的再进行同步,而不是同步之后再进行条件判断,尽量减少不必要的进入同步块的逻辑。

三、锁中尽量不要再包含锁

这种情况经常发生,线程在得到了A锁之后,在同步方法块中调用了另外对象的同步方法,获得了第二个锁,这样可能导致一个调用堆栈中有多把锁的请求,多线程情况下可能会出现很复杂、难以分析的异常情况,导致死锁的发生。下面的代码显示了这种情况:

synchronized(A){

   synchronized(B){
  
      }  
}

或是在同步块中调用了同步方法:

synchronized(A){

    B  b = objArrayList.get(0);
    b.method(); //这是一个同步方法
}

解决的办法是跳出来加锁,不要包含加锁:

{
     B b = null;
   
 synchronized(A){
    b = objArrayList.get(0);
  }
  b.method();
}

四、将锁私有化,在内部管理锁

把锁作为一个私有的对象,外部不能拿到这个对象,更安全一些。对象可能被其他线程直接进行加锁操作,此时线程便持有了该对象的对象锁,例如下面这种情况:

class A {
    public void method1() {
    }
}

class B {
    public void method1() {
        A a = new A();
        synchronized (a) { //直接进行加锁
      a.method1();

        }
    }
}

这种使用方式下,对象a的对象锁被外部所持有,让这把锁在外部多个地方被使用是比较危险的,对代码的逻辑流程阅读也造成困扰。一种更好的方式是在类的内部自己管理锁,外部需要同步方案时,也是通过接口方式来提供同步操作:

class A {
    private Object lock = new Object();
    public void method1() {
        synchronized (lock){
            
        }
    }
}

class B {
    public void method1() {
        A a = new A();
        a.method1();
    }
}

五、进行适当的锁分解

 考虑下面这段程序:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      synchronized (tables) {
        List<Player> tablePlayers = tables.get(table.getId());
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  public void leave(Player player, Table table) {/*省略*/} 
  public void createTable() {/*省略*/} 
  public void destroyTable(Table table) {/*省略*/}
}

在这个例子中,join方法只使用一个同步锁,来获取tables中的List<Player>对象,然后判断玩家数量是不是小于9,如果是,就调增加一个玩家。当有成千上万个List<Player>存在tables中时,对tables锁的竞争将非常激烈。在这里,我们可以考虑进行锁的分解:快速取出数据之后,对List<Player>对象进行加锁,让其他线程可快速竞争获得tables对象锁:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = null;
      synchronized (tables) {
          tablePlayers = tables.get(table.getId());
      }
      
      synchronized (tablePlayers) {
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }

 public void leave(Player player, Table table) {/*省略*/} 
 public void createTable() {/*省略*/} 
 public void destroyTable(Table table) {/*省略*/}
}

(完)

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Vamei实验室

Python标准库02 时间与日期 (time, datetime包)

Python具有良好的时间和日期管理功能。实际上,计算机只会维护一个挂钟时间(wall clock time),这个时间是从某个固定时间起点到现在的时间间隔。时...

2446
来自专栏人工智能

机器学习如何从 Python 2 迁移到 Python 3

关键时刻,第一时间送达! ? 本文经授权转自人工智能头条。 Python 已经成为机器学习及其他科学领域中的主流语言。它不但与多种深度学习框架兼容,而且还包含优...

3206
来自专栏葡萄城控件技术团队

C#开发人员应该知道的13件事情

本文讲述了C#开发人员应该了解到的13件事情,希望对C#开发人员有所帮助。 1. 开发过程 开发过程是错误和缺陷开始的地方。使用工具可以帮助你在发布之后,解决掉...

2299
来自专栏决胜机器学习

设计模式专题(八) ——模板方法模式

设计模式专题(八) ——模板方法模式 (原创内容,转载请注明来源,谢谢) 一、概念 1)含义 模板方法模式是为了让重复的内容都在父类实现,而避免重复。当完成某...

3556
来自专栏原创

教你如何用AST语法树对代码“动手脚”

作为程序猿,每天都在写代码,但是有没有想过通过代码对写好的代码”动点手脚”呢?今天就与大家分享——如何通过用AST语法树改写Java代码。 先抛一个问题:如何将...

6396
来自专栏决胜机器学习

设计模式专题(五)——工厂方法模式

设计模式专题(五)——工厂方法模式 (原创内容,转载请注明来源,谢谢) 一、概述 1、工厂方法与简单工厂模式区别 工厂方法模式与简单工厂模式不同 简单工厂模...

3899
来自专栏新智元

Go 2.0发布在即,程序员有太多话要说

Go语言的开发者正着手准备开发2.0版本,并从以下三个方面发布了初步的设计方案(非官方正式版),以供社区开展讨论:

7801
来自专栏魂祭心

原 Introduction to the

3609
来自专栏工科狗和生物喵

【计算机本科补全计划】指令:计算机的语言(MIPS) Part3

正文之前 今天学的很尴尬,因为有事情,而且新认识了两个计算机学院的保研大佬,不得不感叹我找的导师之强,第一个去上交的,是被金老师推荐去的,听说是跟了目前亚洲第一...

3288
来自专栏IT可乐

Java 多线程详解(三)------线程的同步

Java 多线程详解(一)------概念的引入:https://cloud.tencent.com/developer/article/1012542 Jav...

23910

扫码关注云+社区

领取腾讯云代金券