java队列解决并发（如何处理java高并发问题）

本文目录

• 如何处理java高并发问题
• java 项目开发中中如何解决高并发问题
• java 什么情况下使用 并发队列
• Java如何处理大量的并发请求
• JAVA如何用队列实现并发

如何处理java高并发问题

如何处理并发和同步
今天讲的如何处理并发和同同步问题主要是通过锁机制。
我们需要明白，锁机制有两个层面。
一种是代码层次上的，如java中的同步锁，典型的就是同步关键字synchronized，这里我不在做过多的讲解，
***隐藏网址***
另外一种是数据库层次上的，比较典型的就是悲观锁和乐观锁。这里我们重点讲解的就是悲观锁（传统的物理锁）和乐观锁。
悲观锁(Pessimistic Locking):
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自 外部系统的事务处理）修改持保守态度，因此，
在整个数据处理过程中，将数据处于锁定状态。
悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统
中实现了加锁机制，也无法保证外部系 统不会修改数据）。
一个典型的倚赖数据库的悲观锁调用：
select * from account where name=”Erica” for update
这条 sql 语句锁定了 account 表中所有符合检索条件（ name=”Erica” ）的记录。
本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。
Hibernate 的悲观锁，也是基于数据库的锁机制实现。
下面的代码实现了对查询记录的加锁：
String hqlStr ="from TUser as user where user.name=’Erica’";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); // 加锁
List userList = query.list();// 执行查询，获取数据
query.setLockMode 对查询语句中，特定别名所对应的记录进行加锁（我们为 TUser 类指定了一个别名 “user” ），这里也就是对
返回的所有 user 记录进行加锁。
观察运行期 Hibernate 生成的 SQL 语句：
select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id
as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
from t_user tuser0_ where (tuser0_.name=’Erica’ ) for update
这里 Hibernate 通过使用数据库的 for update 子句实现了悲观锁机制。
Hibernate 的加锁模式有：
Ø LockMode.NONE ： 无锁机制。
Ø LockMode.WRITE ： Hibernate 在 Insert 和 Update 记录的时候会自动获取
Ø LockMode.READ ： Hibernate 在读取记录的时候会自动获取。
以上这三种锁机制一般由 Hibernate 内部使用，如 Hibernate 为了保证 Update
过程中对象不会被外界修改，会在 save 方法实现中自动为目标对象加上 WRITE 锁。
Ø LockMode.UPGRADE ：利用数据库的 for update 子句加锁。
Ø LockMode. UPGRADE_NOWAIT ： Oracle 的特定实现，利用 Oracle 的 for
update nowait 子句实现加锁。
上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：
Criteria.setLockMode
Query.setLockMode
Session.lock

java 项目开发中中如何解决高并发问题

对于我们开发的网站，如果网站的访问量非常大的话，那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题，
但话又说回来了，既然逃避不掉，那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧。
为了更好的理解并发和同步，我们需要先明白两个重要的概念:同步和异步
1、同步和异步的区别和联系
　　所谓同步，可以理解为在执行完一个函数或方法之后，一直等待系统返回值或消息，这时程序是出于阻塞的，只有接收到
返回的值或消息后才往下执行其它的命令。
异步，执行完函数或方法后，不必阻塞性地等待返回值或消息，只需要向系统委托一个异步过程，那么当系统接收到返回
值或消息时，系统会自动触发委托的异步过程，从而完成一个完整的流程。
同步在一定程度上可以看做是单线程，这个线程请求一个方法后就待这个方法给他回复，否则他不往下执行(死心眼)。
异步在一定程度上可以看做是多线程的(废话，一个线程怎么叫异步)，请求一个方法后，就不管了，继续执行其他的方法。
　　 同步就是一件事，一件事情一件事的做。
异步就是，做一件事情，不引响做其他事情。
例如：吃饭和说话，只能一件事一件事的来，因为只有一张嘴。
但吃饭和听音乐是异步的，因为，听音乐并不引响我们吃饭。
对于Java程序员而言，我们会经常听到同步关键字synchronized，假如这个同步的监视对象是类的话，那么

java 什么情况下使用 并发队列

并发队列是一个基于链接节点的无界线程安全队列，它采用先进先出的规则对节点进行排序，当我们添加一个元素的时候，它会添加到队列的尾部，当我们获取一个元素时，它会返回队列头部的元素。它采用了“wait－free”算法来实现，该算法在Michael
& Scott算法上进行了一些修改。

入队列

入队列就是将入队节点添加到队列的尾部。为了方便理解入队时队列的变化，以及head节点和tair节点的变化，每添加一个节点我就做了一个队列的快照图。

第一步添加元素1。队列更新head节点的next节点为元素1节点。又因为tail节点默认情况下等于head节点，所以它们的next节点都指向元素1节点。

第二步添加元素2。队列首先设置元素1节点的next节点为元素2节点，然后更新tail节点指向元素2节点。

第三步添加元素3，设置tail节点的next节点为元素3节点。

第四步添加元素4，设置元素3的next节点为元素4节点，然后将tail节点指向元素4节点。

通过debug入队过程并观察head节点和tail节点的变化，发现入队主要做两件事情，

第一是将入队节点设置成当前队列尾节点的下一个节点。

第二是更新tail节点，如果tail节点的next节点不为空，则将入队节点设置成tail节点，如果tail节点的next节点为空，则将入队节点设置成tail的next节点，所以tail节点不总是尾节点，理解这一点对于我们研究源码会非常有帮助。

上面的分析让我们从单线程入队的角度来理解入队过程，但是多个线程同时进行入队情况就变得更加复杂，因为可能会出现其他线程插队的情况。如果有一个线程正在入队，那么它必须先获取尾节点，然后设置尾节点的下一个节点为入队节点，但这时可能有另外一个线程插队了，那么队列的尾节点就会发生变化，这时当前线程要暂停入队操作，然后重新获取尾节点。让我们再通过源码来详细分析下它是如何使用CAS算法来入队的。

public boolean offer(E e) {    
          
   if (e == null) throw new NullPointerException();    
         
    //入队前，创建一个入队节点    
         
    Node《/e》《e》 n = new Node《/e》《e》(e);    
  
   retry:    
          
    //死循环，入队不成功反复入队。    
          
    for (;;) {    
           
        //创建一个指向tail节点的引用    
           
       Node《/e》《e》 t = tail;    
           
     //p用来表示队列的尾节点，默认情况下等于tail节点。    
           
      Node《/e》《e》 p = t;    
           
      for (int hops = 0; ; hops++) {    
           
     //获得p节点的下一个节点。    
           
        Node《/e》《e》 next = succ(p);    
           
     //next节点不为空，说明p不是尾节点，需要更新p后在将它指向next节点    
           
        if (next != null) {    
           
     //循环了两次及其以上，并且当前节点还是不等于尾节点    
           
        if (hops 》 HOPS && t != tail)    
           
            continue retry;    
           
            p = next;    
           
        }    
           
     //如果p是尾节点，则设置p节点的next节点为入队节点。    
           
         else if (p.casNext(null, n)) {    
           
        //如果tail节点有大于等于1个next节点，则将入队节点设置成tair节点，更新失败了也没关系，因为失败了表示有其他线程成功更新了tair节点。    
           
    if (hops 》= HOPS)    
           
           casTail(t, n); // 更新tail节点，允许失败    
           
        return true;    
           
         }    
           
        // p有next节点,表示p的next节点是尾节点，则重新设置p节点    
           
        else {    
           
          p = succ(p);    
           
        }    
           
     }    
         
  }    
          
}

从源代码角度来看整个入队过程主要做二件事情。

第一步定位尾节点。tail节点并不总是尾节点，所以每次入队都必须先通过tail节点来找到尾节点，尾节点可能就是tail节点，也可能是tail节点的next节点。代码中循环体中的第一个if就是判断tail是否有next节点，有则表示next节点可能是尾节点。获取tail节点的next节点需要注意的是p节点等于p的next节点的情况，只有一种可能就是p节点和p的next节点都等于空，表示这个队列刚初始化，正准备添加第一次节点，所以需要返回head节点。获取p节点的next节点代码如下

final Node《/e》《e》 succ(Node《/e》《e》 p) {    
        
     Node《/e》《e》 next = p.getNext();    
 
       return (p == next) ? head : next;    
        
      }

第二步设置入队节点为尾节点。p.casNext(null, n)方法用于将入队节点设置为当前队列尾节点的next节点，p如果是null表示p是当前队列的尾节点，如果不为null表示有其他线程更新了尾节点，则需要重新获取当前队列的尾节点。

hops的设计意图。上面分析过对于先进先出的队列入队所要做的事情就是将入队节点设置成尾节点，doug lea写的代码和逻辑还是稍微有点复杂。那么我用以下方式来实现行不行？

public boolean offer(E e) {    
      
    if (e == null)    
           
       throw new NullPointerException();    
          
      Node《/e》《e》 n = new Node《/e》《e》(e);    
          
          for (;;) {    
          
      Node《/e》《e》 t = tail;    
         
       if (t.casNext(null, n) && casTail(t, n)) {    
          
             return true;    
          
     }    
         
     }    
         
}

让tail节点永远作为队列的尾节点，这样实现代码量非常少，而且逻辑非常清楚和易懂。但是这么做有个缺点就是每次都需要使用循环CAS更新tail节点。如果能减少CAS更新tail节点的次数，就能提高入队的效率，所以doug
lea使用hops变量来控制并减少tail节点的更新频率，并不是每次节点入队后都将 tail节点更新成尾节点，而是当
tail节点和尾节点的距离大于等于常量HOPS的值（默认等于1）时才更新tail节点，tail和尾节点的距离越长使用CAS更新tail节点的次数就会越少，但是距离越长带来的负面效果就是每次入队时定位尾节点的时间就越长，因为循环体需要多循环一次来定位出尾节点，但是这样仍然能提高入队的效率，因为从本质上来看它通过增加对volatile变量的读操作来减少了对volatile变量的写操作，而对volatile变量的写操作开销要远远大于读操作，所以入队效率会有所提升。

 private static final int HOPS = 1;

还有一点需要注意的是入队方法永远返回true，所以不要通过返回值判断入队是否成功。

4. 出队列

出队列的就是从队列里返回一个节点元素，并清空该节点对元素的引用。让我们通过每个节点出队的快照来观察下head节点的变化。

从上图可知，并不是每次出队时都更新head节点，当head节点里有元素时，直接弹出head节点里的元素，而不会更新head节点。只有当head节点里没有元素时，出队操作才会更新head节点。这种做法也是通过hops变量来减少使用CAS更新head节点的消耗，从而提高出队效率。让我们再通过源码来深入分析下出队过程。

 public E poll() {    
        
    Node《/e》《e》 h = head;    
       
    // p表示头节点，需要出队的节点    
        
      Node《/e》《e》 p = h;    
        
      for (int hops = 0;; hops++) {    
        
         // 获取p节点的元素    
        
         E item = p.getItem();    
        
         // 如果p节点的元素不为空，使用CAS设置p节点引用的元素为null,如果成功则返回p节点的元素。    
        
         if (item != null && p.casItem(item, null)) {    
         
         if (hops 》= HOPS) {    
        
              //将p节点下一个节点设置成head节点    
        
              Node《/e》《e》 q = p.getNext();    
        
              updateHead(h, (q != null) ? q : p);    
       
              }    
        
                  return item;    
 
              }    
        
        // 如果头节点的元素为空或头节点发生了变化，这说明头节点已经被另外一个线程修改了。那么获取p节点的下一个节点    
        
        Node《/e》《e》 next = succ(p);    
        
        // 如果p的下一个节点也为空，说明这个队列已经空了    
       
        if (next == null) {    
        
       // 更新头节点。    
         
             updateHead(h, p);    
        
             break;    
         
             }    
        
      // 如果下一个元素不为空，则将头节点的下一个节点设置成头节点    
         
       p = next;    
         
      }    
        
          return null;    
        
      }

首先获取头节点的元素，然后判断头节点元素是否为空，如果为空，表示另外一个线程已经进行了一次出队操作将该节点的元素取走，如果不为空，则使用CAS的方式将头节点的引用设置成null，如果CAS成功，则直接返回头节点的元素，如果不成功，表示另外一个线程已经进行了一次出队操作更新了head节点，导致元素发生了变化，需要重新获取头节点。

Java如何处理大量的并发请求

在web应用中,同一时间有大量的客户端请求同时发送到服务器,例如抢购、秒杀等。这个时候如何避免将大量的请求同时发送到业务系统。
第一种方法:在容器中配置最大请求数,如果大于改请求数,则客户端阻塞。该方法有效的阻止了大量的请求同时访问业务系统,但对用于不友好。
第二种方法:使用过滤器,保证一定数量的请求能够正常访问系统,多余的请求先跳转到排队页面,由排队页面定时发起请求。过滤器实现如下:
《pre name="code" class="java"》public class ServiceFilter implements Filter { private static final int MAX_COUNT = 20; private int filterCount = 0; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { System.out.println("before"+filterCount); if(filterCount 》 MAX_COUNT) { //请求个数太多,跳转到排队页面 request.getRequestDispatcher("index.jsp").forward(request, response); } else { //请求个数加1 filterCount ++; chain.doFilter(request, response); //访问结束,请求个数减1 filterCount --; } }
}

JAVA如何用队列实现并发

如果是抢资源，在不作弊的情况下
按照先来先得的规则
，那么比较简单的实现就是队列
，不管请求的并发多高，如果用线程来实现为用户服务，也就是说
来一个人请求资源那么就启动一个线程，那CPU执行线程总是有顺序的，比如
当前三个人（路人甲路人乙路人丙）请求A资源
，那服务端就起了三个线程为这三个人服务，假设
这三个人不太幸运在请求的时候没有及时的获得CPU时间片，那么他们三个相当于公平竞争CPU资源，而CPU选择运行线程是不确定顺序的
，又假设
选中了路人丙的线程运行那么将其放入队列就好了,路人乙，路人丙以此类推
，那可能会想为什么不及时的处理呢
，因为后续的操作可能是耗时操作对于线程的占用时间较长那请求资源的人多了服务端就可能挂了