1.减少锁持有的时间

对于使用锁进行并发控制的应用程序而言，在锁的竞争过程中，单个线程对锁的持有时间与系统性能有着直接的关系。如果线程持有锁的时间越长，那么相对的，锁的竞争也就越激烈。比如，要求100个人填写自己的个人信息，但是只有1支笔，每个人拿着笔的时间都很长，那么总体花费的时间也就很长。如果真的只有一支笔，那么最好让每个人花尽可能少的时间持笔，务必做到想好了再拿笔写，而不能拿着笔思考该怎么想。程序开发也是类似的，应尽可能地减少对某个锁的持有时间，以减少线程间互斥的可能。比如在以下代码中

public synchronized void syncMethod(){
        othercode1();
        mutextMethod();
        othercode2();
    }

在上述方法中，othercode1和othercode2都是重量级方法，需要花费较长的CPU时间，但是只有mutextMethod方法是有同步需要的。在并发量较大的时候，使用这种对整个方法做同步的方法，则会导致等待线程大量增加。因为一个线程，在进入该方法时，需要获得内部锁，只有在整个任务执行完以后，才会释放锁。
一个较为优化的方法是，只在必要的时候进行同步，这样能够明显减少锁的持有时间，提高系统的吞吐量。

public void syncMethod(){
        othercode1();
        synchronized (this){
            mutextMethod();
        }
        othercode2();
    }

在上述代码中，只针对需要同步的方法使用内部锁加锁，锁占用的时间相对较短，因此有更高的并行度。

2.减少锁的粒度

将单个独占锁变为多个锁，从而将加速请求均分到多个锁上，有效降低对锁的竞争。但是，增加锁的前提是多线程访问的变量间相互独立，如果多线程需要同时访问多个变量，则很难进行锁分解，因为要维持原子性。

3.用读写分离锁来代替独占锁

使用读写分离锁ReadWriteLock可以提高系统的性能。使用读写分离锁来替代独占锁是减小锁粒度的一种特殊情况。如果说减小锁粒度是通过分割数据结构实现的，那么读写分离锁则是针对系统功能点的分割。
在读多写少的场合，使用读写分离锁可以有效提升系统的并发能力。

4.锁分离

如果将读写锁的思想进一步延申，就是锁分离。读写锁根据读写操作功能上的不同，进行了有效的锁分离。依据应用程序的特点，使用类似的分离思想，也可以对独占锁进行分离。典型的案例就是LinkedBlockingQueue的实现。
在LinkedBlockingQueue的实现中，take函数和put函数分别实现了从队列中取数据和往队列中增加数据的功能。虽然两个函数都是对当前队列进行了修改操作，但是LinkedBlockingQueue是基于链表的，因此两个操作分别用于队列的前端和尾端，从理论上讲，并不冲突。
如果使用独占锁，则要求在两个操作进行时分别获取当前队列的独占锁，那么take和put方法就不能真正的并发，在运行时，它们会彼此等待对方释放锁资源。这种情况下，锁的竞争会比较激烈，从而影响并发时的性能。
因此，在JDK实现中，并没有采用这种方式，取而代之的时用两把不同的锁分离了take和put方法。

 private final ReentrantLock takeLock = new ReentrantLock();

    /** Wait queue for waiting takes */
    private final Condition notEmpty = takeLock.newCondition();

    /** Lock held by put, offer, etc */
    private final ReentrantLock putLock = new ReentrantLock();

    /** Wait queue for waiting puts */
    private final Condition notFull = putLock.newCondition();

以上代码片段定义了takeLock和putLock，分别在take和put方法中使用。
put方法实现

 public void put(E e) throws InterruptedException {
        if (e == null) throw new NullPointerException();
        // Note: convention in all put/take/etc is to preset local var
        // holding count negative to indicate failure unless set.
        int c = -1;
        Node<E> node = new Node<E>(e);
        final ReentrantLock putLock = this.putLock;
        final AtomicInteger count = this.count;
        putLock.lockInterruptibly();  //不能有两个线程同时进行put方法
        try {
            /* 如果队列已经满了，则等待*/
            while (count.get() == capacity) {
                notFull.await();
            }
            enqueue(node);  //在队尾插入该节点
            c = count.getAndIncrement(); //更新总数，c时count+1前的值
            if (c + 1 < capacity) 
                notFull.signal();//有足够的空间，通知其他线程
        } finally {
            putLock.unlock();//释放锁
        }
        if (c == 0)
            signalNotEmpty();//插入成功后，通知take方法可以取数据了
    }

take方法实现

  public E take() throws InterruptedException {
        E x;
        int c = -1;
        final AtomicInteger count = this.count;
        final ReentrantLock takeLock = this.takeLock;
        takeLock.lockInterruptibly(); //不能有两个线程同时取数据
        try {
            while (count.get() == 0) {  //如果队列时空的，则等待
                notEmpty.await();
            }
            x = dequeue(); //取数据
            c = count.getAndDecrement(); //数量减1，原子操作，因为会和put函数同时访问count，变量c时cout减1前的值
            if (c > 1)
                notEmpty.signal(); //通知其他take方法
        } finally {
            takeLock.unlock(); //释放锁
        }
        if (c == capacity)
            signalNotFull();  //通知put已有空余空间
        return x;
    }

5.锁粗化

通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，即在使用完公共资源后，应该立即释放锁。只有这样，等待在这个锁上的其他线程才能尽早地获得资源执行任务。但是，凡事都有一个度，如果对同一个锁不停地进行请求，同步和释放，其本身也会消耗宝贵地资源，反而不利于优化。
为此，虚拟机在遇到一连串连续对同一个锁不断进行请求和释放操作时，便会把所有地锁操作整合成对锁地一次请求，从而减少对锁的请求同步次数，这个操作叫锁粗化。

 public void syncMethod(){
        synchronized (lock){
            //do sth
        }
//做其他不需要同步的工作，但不会消耗很长的cpu执行时间
        synchronized (lock){
            //do sth
        }
    }

上述代码会被整合成如下形式:

public void syncMethod(){
//整合成一次锁请求
        synchronized (lock){
            //do sth
            //做其他不需要同步的工作，但不会消耗很长的cpu执行时间
        }
    }

在开发过程中，应有意识地在合理场合进行锁地粗化，尤其是在循环内请求锁的时候。