這篇文章帶給大家的內容是關於Java高並發怎麼解決？ Java高併發的解決方法，有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。
對於我們開發的網站，如果網站的訪問量非常大的話，那麼我們就需要考慮相關的並發訪問問題了。而並發問題是絕大部分的程式設計師頭痛的問題，
但話又說回來了，既然逃避不掉，那我們就坦然面對吧~今天就讓我們一起來研究一下常見的並發和同步吧。
為了更好的理解並發和同步，我們需要先明白兩個重要的概念:同步和非同步
1、同步和非同步的區別和聯繫
所謂同步，可以理解為在執行完一個函數或方法之後，一直等待系統回傳值或訊息，這時程式是出於阻塞的，只有接收到
#傳回的值或訊息後才往下執行其它的命令。
非同步，執行完函數或方法後，不必阻塞性地等待回傳值或訊息，只需要向系統委託一個非同步過程，那麼當系統接收到傳回值或訊息時，系統會自動觸發委託的非同步過程，從而完成一個完整的流程。
同步在一定程度上可以看做是單線程，這個線程請求一個方法後就待這個方法給他回复，否則他不往下執行(死心眼)。
非同步在某種程度上可以看做是多執行緒的(廢話，一個執行緒怎麼叫異步)，請求一個方法後，就不管了，繼續執行其他的方法。
同步就是一件事，一件事情一件事的做。
非同步就是，做一件事情，不引響做其他事情。
例如：
吃飯和說話，只能一件事一件事的來，因為只有一張嘴。但吃飯和聽音樂是異步的，因為，聽音樂並不會引響我們吃飯。
對於Java程式設計師而言，我們會經常聽到同步關鍵字synchronized，假如這個同步的監視對像是類的話，那麼如果當一個對象訪問類裡面的同步方法的話，那麼其它的對象如果想要繼續存取類別裡面的這個同步方法的話，就會進入阻塞，只有等前一個物件執行完該同步方法後目前物件才能夠繼續執行該方法。這就是同步。相反，如果方法前沒有同步關鍵字修飾的話，那麼不同的物件可以在同一時間存取同一個方法，這就是非同步。
在補充(髒數據和不可重複讀的相關概念):
髒數據
髒讀就是指當一個事務正在訪問數據，並且對數據進行了修改，而這種修改還沒有提交到資料庫中，這時，另外一個事務也存取這個數據，然後使用了這個數據。因為這個數據是還沒提交的數據，那麼另外一個事務讀到的這個數據是髒數據(Dirty Data)，依據髒數據所做的操作可能是不正確的。
無法重複讀取
無法重複讀取是指在一個交易內，多次讀取相同資料。在這個事務還沒結束時，另外一個事務也存取該相同資料。那麼，在第一個事務中的兩次讀取資料之間，由於第二個事務的修改，那麼第一個事務兩次讀到的資料可能是不一樣的。這樣就發生了在一個事務內兩次讀到的資料是不一樣的，因此稱為是不可重複讀
2、如何處理並發和同步
今天講的如何處理並發和同同步問題主要是透過鎖定機制。
我們要明白，鎖定機制有兩個層次。
一種是程式碼層次上的，如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
注意，只有在查询开始之前（也就是 Hiberate 生成 SQL 之前）设定加锁，才会 真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含 for update子句的 Select SQL 加载进来，所谓数据库加锁也就无从谈起。
为了更好的理解select... for update的锁表的过程，本人将要以mysql为例，进行相应的讲解
1、要测试锁定的状况，可以利用MySQL的Command Mode ，开二个视窗来做测试。
表的基本结构如下:
表中内容如下:
开启两个测试窗口，在其中一个窗口执行select * from ta for update0
然后在另外一个窗口执行update操作如下图:
等到一个窗口commit后的图片如下:
到这里，悲观锁机制你应该了解一些了吧~
需要注意的是for update要放到mysql的事务中，即begin和commit中，否者不起作用。
至于是锁住整个表还是锁住选中的行。
至于hibernate中的悲观锁使用起来比较简单，这里就不写demo了~感兴趣的自己查一下就ok了~
乐观锁(Optimistic Locking):
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依 靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。 如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进 行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过 程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作 员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几 百上千个并发，这样的情况将导致怎样的后果。 乐观锁机制在一定程度上解决了这个问题。
乐观锁，大多是基于数据版本 Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来 实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提 交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。 2 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并 从其帐户余额中扣除 $20 （ $100-$20 ）。 3 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣 除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大 于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。 4 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数 据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的 数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记 录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。 这样，就避免了操作员 B 用基于version=1 的旧数据修改的结果覆盖操作 员 A 的操作结果的可能。 从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系 统整体性能表现。 需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局 限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户 余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在 系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如 将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途 径，而不是将数据库表直接对外公开）。 Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数 据库的更新操作，利用 Hibernate 提供的透明化乐观锁实现，将大大提升我们的 生产力。
User.hbm.xml
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="com.xiaohao.test">
<class name="User" table="user" optimistic-lock="version" >
<id name="id">
<generator class="native" />
</id>
<!--version标签必须跟在id标签后面-->
<version column="version" name="version" />
<property name="userName"/>
<property name="password"/>
</class>
</hibernate-mapping>注意 version 节点必须出现在 ID 节点之后。
这里我们声明了一个 version 属性，用于存放用户的版本信息，保存在 User 表的version中
optimistic-lock 属性有如下可选取值：
? none无乐观锁
? version通过版本机制实现乐观锁
? dirty通过检查发生变动过的属性实现乐观锁
? all通过检查所有属性实现乐观锁
其中通过 version 实现的乐观锁机制是 Hibernate 官方推荐的乐观锁实现，同时也 是 Hibernate 中，目前唯一在数据对象脱离 Session 发生修改的情况下依然有效的锁机 制。因此，一般情况下，我们都选择 version 方式作为 Hibernate 乐观锁实现机制。
2 、配置文件hibernate.cfg.xml和UserTest测试类
hibernate.cfg.xml
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<!-- 指定数据库方言 如果使用jbpm的话，数据库方言只能是InnoDB-->
<property name="dialect">org.hibernate.dialect.MySQL5InnoDBDialect</property>
<!-- 根据需要自动创建数据表 -->
<property name="hbm2ddl.auto">update</property>
<!-- 显示Hibernate持久化操作所生成的SQL -->
<property name="show_sql">true</property>
<!-- 将SQL脚本进行格式化后再输出 -->
<property name="format_sql">false</property>
<property name="current_session_context_class">thread</property>
<!-- 导入映射配置 -->
<property name="connection.url">jdbc:mysql:///user</property>
<property name="connection.username">root</property>
<property name="connection.password">123456</property>
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<mapping resource="com/xiaohao/test/User.hbm.xml" />
</session-factory>
</hibernate-configuration>UserTest.java
package com.xiaohao.test;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;
public class UserTest {
public static void main(String[] args) {
Configuration conf=new Configuration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.getCurrentSession();
Transaction tx=session.beginTransaction();
// User user=new User("小浩","英雄");
// session.save(user);
// session.createSQLQuery("insert into user(userName,password) value('张英雄16','123')")
// .executeUpdate();
User user=(User) session.get(User.class, 1);
user.setUserName("221");
// session.save(user);
System.out.println("恭喜您，用户的数据插入成功了哦~~");
tx.commit();
}
}每次对 TUser 进行更新的时候，我们可以发现，数据库中的 version 都在递增。
下面我们将要通过乐观锁来实现一下并发和同步的测试用例:
这里需要使用两个测试类，分别运行在不同的虚拟机上面，以此来模拟多个用户同时操作一张表,同时其中一个测试类需要模拟长事务
UserTest.java
package com.xiaohao.test;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;
public class UserTest {
public static void main(String[] args) {
Configuration conf=new Configuration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.openSession();
// Session session2=sf.openSession();
User user=(User) session.createQuery(" from User user where user=5").uniqueResult();
// User user2=(User) session.createQuery(" from User user where user=5").uniqueResult();
System.out.println(user.getVersion());
// System.out.println(user2.getVersion());
Transaction tx=session.beginTransaction();
user.setUserName("101");
tx.commit();
System.out.println(user.getVersion());
// System.out.println(user2.getVersion());
// System.out.println(user.getVersion()==user2.getVersion());
// Transaction tx2=session2.beginTransaction();
// user2.setUserName("4468");
// tx2.commit();
}
}UserTest2.java
package com.xiaohao.test;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;
public class UserTest2 {
public static void main(String[] args) throws InterruptedException {
Configuration conf=new Configuration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.openSession();
// Session session2=sf.openSession();
User user=(User) session.createQuery(" from User user where user=5").uniqueResult();
Thread.sleep(10000);
// User user2=(User) session.createQuery(" from User user where user=5").uniqueResult();
System.out.println(user.getVersion());
// System.out.println(user2.getVersion());
Transaction tx=session.beginTransaction();
user.setUserName("100");
tx.commit();
System.out.println(user.getVersion());
// System.out.println(user2.getVersion());
// System.out.println(user.getVersion()==user2.getVersion());
// Transaction tx2=session2.beginTransaction();
// user2.setUserName("4468");
// tx2.commit();
}
}操作流程及简单讲解: 首先启动UserTest2.java测试类，在执行到Thread.sleep(10000);这条语句的时候，当前线程会进入睡眠状态。在10秒钟之内启动UserTest这个类，在到达10秒的时候，我们将会在UserTest.java中抛出下面的异常:
Exception in thread "main" org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xiaohao.test.User#5]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1932)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2576)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2476)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2803)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:113)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:185)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133)
at com.xiaohao.test.UserTest2.main(UserTest2.java:21)UserTest2代码将在 tx.commit() 处抛出 StaleObjectStateException 异 常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我 们就可以在乐观锁校验失败时进行相应处理
3、常見並發同步案例分析
案例一:訂票系統案例，某航班只有一張機票，假定有1w個人打開你的網站來訂票，問你如何解決並發問題(可擴展到任何高並發網站要考慮的並發讀寫問題)
問題，1w個人來訪問，票沒出去前要保證大家都能看到有票，不可能一個人看到票的時候別人就不能看了。到底誰能搶到，那得看這個人的「運氣」（網路快慢等）其次考慮的問題，並發，1w個人同時點擊購買，到底誰能成交？總共只有一張票。
首先我們容易想到和並發相關的幾個方案：
鎖定同步同步更多指的是應用程式的層面，多個線程進來，只能一個一個的訪問，java中指的是syncrinized關鍵字。鎖也有2個層面，一個是java談到的物件鎖，用於線程同步；另一個層面是資料庫的鎖；如果是分散式的系統，顯然只能利用資料庫端的鎖來實現。
假定我們採用了同步機製或資料庫實體鎖定機制，如何保證1w個人還能同時看到有票，顯然會犧牲效能，在高並發網站中是不可取的。使用hibernate後我們提出了另一個概念：樂觀鎖、悲觀鎖（即傳統的實體鎖）；採用樂觀鎖即可解決此問題。樂觀鎖意思是不鎖定表的情況下，利用業務的控制來解決並發問題，這樣即保證數據的並發可讀性又保證保存數據的排他性，保證性能的同時解決了並發帶來的髒數據問題。
hibernate中如何實現樂觀鎖定：
前提：在現有表當中增加一個冗餘字段，version版本號, long類型
#原理：
1）只有目前版本號》=資料庫表版本號，才能提交
2）提交成功後，版本號version
實作很簡單：在ormapping增加一屬性optimistic-lock ="version"即可，以下是範例片段
案例二、股票交易系統、銀行系統，大數據量你是如何考慮的
首先，股票交易系統的行情表，每幾秒鐘就有一個行情記錄產生，一天下來就有（假定行情3秒一個） 股票數量×20×60*6 筆記錄，一月下來這個表記錄數量多大？ oracle中一張表的記錄數超過100w後 查詢效能就很差了，如何保證系統效能？
再比如，中國移動有上億的用戶量，表如何設計？把所有用於存在於一個表麼？所以，大數量的系統，必須考慮表拆分-（表名字不一樣，但是結構完全一樣），通用的幾種方式：（視情況而定）
#1）按業務分，例如手機號碼的表，我們可以考慮130開頭的作為一個表，131開頭的另外一張表以此類推
2）利用oracle的表拆分機製做分錶
3 ）如果是交易系統，我們可以考慮按時間軸拆分，當日資料一個表，歷史資料弄到其它表。這裡歷史資料的報表和查詢不會影響當日交易。
當然，表拆分後我們的應用得做對應的適配。單純的or-mapping也許就得改動了。例如部分業務得通過預存程序等
此外，我們還得考慮緩存
這裡的緩存，指的不只是hibernate，hibernate本身提供了一級二級緩存。這裡的快取獨立於應用，依然是記憶體的讀取，假如我們能減少資料庫頻繁的訪問，那對系統肯定大大有利的。例如一個電子商務系統的商品搜索，如果某個關鍵字的商品經常被搜，那就可以考慮這部分商品列表存放到緩存（內存中去），這樣不用每次訪問數據庫，性能大大增加。
簡單的快取大家可以理解為自己做一個hashmap，把常訪問的資料做一個key，value是第一次從資料庫搜尋出來的值，下次存取就可以從map裡讀取，而不讀資料庫；專業些的目前有獨立的快取框架例如memcached 等，可獨立部署成一個快取伺服器。
4、常見的提高高並發下訪問的效率的手段
首先要了解高並發的的瓶頸在哪裡？
1、可能是伺服器網路頻寬不夠
2.可能web執行緒連線數不夠
3.可能資料庫連線查詢上不去。
根據不同的情況，解決思路也不同。
像第一種情況可以增加網路頻寬，DNS網域解析分發多台伺服器。
負載平衡，前置代理伺服器nginx、apache等等
資料庫查詢最佳化，讀寫分離，分錶等等
最後複製一些在高並發下面需要常常需要處理的內容:
盡量使用緩存，包括用戶緩存，資訊緩存等，多花點內存來做緩存，可以大量減少與資料庫的交互，提高性能。
用jprofiler等工具找出效能瓶頸，減少額外的開銷。
優化資料庫查詢語句，減少直接使用hibernate等工具的直接產生語句（僅耗時較長的查詢做最佳化）。
優化資料庫結構，多做索引，提高查詢效率。
統計的功能盡量做緩存，或按每天一統計或定時統計相關報表，避免需要時進行統計的功能。
能使用靜態頁面的地方盡量使用，減少容器的解析（盡量將動態內容產生靜態html來顯示）。
解決以上問題後，使用伺服器叢集來解決單一的瓶頸問題。
java高並發，如何解決，什麼方式解決
之前我將高並發的解決方法誤認為是線程或者是隊列可以解決，因為高並發的時候是有很多用戶在訪問，導致出現系統資料不正確、遺失資料現象，所以想到 的是用隊列解決，其實隊列解決的方式也可以處理，比如我們在競拍商品、轉發評論微博或者是秒殺商品等，同一時間訪問量特別大，隊列在此起到特別的作用，將 所有請求放入佇列，以毫秒計時單位，有序的進行，從而不會出現資料遺失系統資料不正確的情況。
今天我經過查資料，高並發的解決方法有兩個種:
一種是使用快取、另一種是使用生成靜態頁面；還有就是從最基礎的地方優化我們寫程式碼減少不必要的資源浪費：(
1.不要頻繁的new物件,對於在整個應用程式中只需要存在一個實例的類別使用單例模式.對於String的連接操作,使用StringBuffer或StringBuilder.對於utility類型的類別透過靜態方法來存取。
2. 避免使用錯誤的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof做條件判斷,盡量使用比的條件判斷方式.使用JAVA中效率高的類別,比如ArrayList比Vector性能好。 )
首先快取技術我一直沒有使用過，我覺得應該是在用戶請求時將資料保存在快取中，下次請求時會檢測快取中是否有資料存在，防止多次請求伺服器，導致伺服器效能降低，嚴重導致伺服器崩潰，這只是我自己的理解，詳細的資料還是需要在網上收集；使用生成靜態頁面我想大家應該不模式，我們見過很多網站當在請求的時候頁面的後最已經變了，如「http://developer.51cto.com/art/201207/348766.htm」該頁面其實是一個伺服器請求位址，在轉換成htm後，存取速度將提升，因為靜態頁面不帶有伺服器元件；這裡我就多介紹一下：
一、什麼是頁面靜態化：
簡 單的說，我們如果訪問一個鏈接 ,伺服器對應的模組會處理這個請求，轉到對應的jsp介面，最後產生我們想要看到的資料。這其中的缺點是顯而易見的：因為每次請求伺服器都會進行處理，如 果實有太多的高並發請求，那麼就會加重應用伺服器的壓力，弄不好就把伺服器 搞down 掉了。那麼如何去避免呢？如果我們把對 test.do 請求後的結果保存成一個 html 文件，然後每次用戶都去訪問 ,這樣應用伺服器的壓力不就減少了？
那麼靜態頁面從哪裡來呢？總不能讓我們每個頁面都手動處理吧？這裡就牽涉到我們要講解的內容了，靜態頁面生成方案… 我們需要的是自動的生成靜態頁面，當用戶訪問 ,會自動生成 test.html ,然後顯示給用戶。
二、下面我們在簡單介紹一下要想掌握頁面靜態化方案應該掌握的知識點：
1、 基礎- URL Rewrite
什麼是URL Rewrite 呢? URL 重寫。用一個簡單的例子來說明問題：輸入網址 ,但是實際上訪問的卻是 abc.com/test.action,那我們就可以說 URL 被重寫了。這項技術應用廣泛，有許多開源的工具可以實現這個功能。
2、 基礎- Servlet web.xml
如果你還不知道 web.xml 中一個請求和一個 servlet 是如何匹配到一起的，那麼請搜尋一下 servlet 的文檔。這可不是亂說呀，有很多人就認為 /xyz/*.do 這樣的配對方式能有效。
如果你還不知道怎麼寫一個servlet ,那麼請搜尋一下如何寫servlet.這可不是說笑呀，在各種集成工具漫天飛舞的今天，很多人都不會去從零編寫一個servlet了。
三、基本的方案介紹
#其中，對於URL Rewriter的部分，可以使用收費或開源的工具來實現，如果url不是特別的複雜，可以考慮在servlet 中實現，那麼就是下面這個樣子：
总 结：其实我们在开发中都很少考虑这种问题，直接都是先将功能实现，当一个程序员在干到1到2年，就会感觉光实现功能不是最主要的，安全性能、质量等等才是 一个开发人员最该关心的。今天我所说的是高并发。
我的解决思路是：
1、采用分布式应用设计
2、分布式缓存数据库
3、代码优化
Java高并发的例子：
具体情况是这样： 通过java和数据库，自己实现序列自动增长。
实现代码大致如下：
id_table表结构, 主要字段：
id_name varchar2(16); id_val number(16,0); id_prefix varchar2(4);
//操作DB
public synchronized String nextStringValue(String id){
SqlSession sqlSess = SqlSessionUtil.getSqlSession();
sqlSess.update("update id_table set id_val = id_val + 1 where id_name="+id);
Map map = sqlSess.getOne("select id_name, id_prefix, id_val from id_table where id_name="+ id);
BigDecimal val = (BigDecimal) map.get("id_val");
//id_val是具体数字，rePack主要是统一返回固定长度的字符串；如：Y0000001, F0000001, T0000001等
String idValue = rePack(val, map);
return idValue;
}
//公共方法
public class IdHelpTool{
public static String getNextStringValue(String idName){
return getXX().nextStringValue(idName);
}
}具体使用者，都是通过类似这种方式：IdHelpTool.getNextStringValue("PAY_LOG");来调用。
问题：
（1） 当出现并发时， 有时会获取重复的ID；
（2） 由于服务器做了相关一些设置，有时调用这个方法，好像还会导致超时。
为了解决问题(1), 考虑过在方法getNextStringValue上，也加上synchronized ， 同步关键字过多，会不会更导致超时？
跪求大侠提供个解决问题的大概思路！！！
解决思路一：
1、推荐 https://github.com/adyliu/idcenter
2、可以通过第三方redis来实现。
解决思路一：
1、出现重复ID，是因为脏读了，并发的时候不加 synchronized 比如会出现问题
2、但是加了 synchronized ，性能急剧下降了，本身 java 就是多线程的，你把它单线程使用，不是明智的选择，同时，如果分布式部署的时候，加了 synchronized 也无法控制并发
3、调用这个方法，出现超时的情况，说明你的并发已经超过了数据库所能处理的极限，数据库无限等待导致超时
基于上面的分析，建议采用线程池的方案，支付宝的单号就是用的线程池的方案进行的。
数据库 update 不是一次加1，而是一次加几百甚至上千，然后取到的这 1000个序号，放在线程池里慢慢分配即可，能应付任意大的并发，同时保证数据库没任何压力。
以上是Java高並發怎麼解決？ Java高併發的解決方法的詳細內容。更多資訊請關注PHP中文網其他相關文章！
