请教高手们一个如何提高java线程并发性的问题

建议你使用asyncExec方法 Socket使用Non-block Socket（NIO）非阻塞试的连接。
SWT组件Diaplay提供syncExec与asyncExec方法，其原型为：syncExec (Runnable runnable)，asyncExec (Runnable runnable)，Runnable的run方法中可以封装要执行的代码，一般而言是UI相关的代码，如更新组件显示、刷新状态等。Diaplay是和线程关联的，其所在的线程一般称谓UI线程，可以有多个UI线程，每个UI线程一个Diaplay。所有的SWT组件相关代码，必须在UI线程之中执行。
  
   syncExec与asyncExec相同点，都是为了让Runnable封装的代码在指定的Diaplay(比如某个产成Image的diaplay) 相关的UI线程中执行。如：imgCreateDiaplayasyncExec(runnable)。需要说明的是，当前线程一般是非UI线程，也可以是UI线程(如其它UI相关线程如awt UI线程，和为提高执行效率，多个SWT UI线程之间协作并发执行，甚至调用线程和执行runnable的UI线程是同一个线程)
  
   syncExec与asyncExec不相同点体现在对方法调用线程本身的影响，syncExec阻塞当前线程直到UI线程完成runnable中的代码执行；而asyncExec则直接返回，不等待runnable中代码被执行，但并不是说asyncExec执行的代码一定不在同一个线程中，有些时候是同一个线程，只不过将代码的执行根据需要分成两个部分或多个部分处理。
  
   两者的异同决定了其分别适应不同的场合，一般syncExec适合在需要同步UI更新之后继续执行的代码，asyncExec适合在不便、不能syuncExec的情况下使用。
  
   syncExec适用情况比较简单，以下总结asyncExec的适用情况。
  
   1、非UI线程需要调用在UI线程中调用的组件方法。非UI线程是相对与UI线程来讲的，UI线程准确的讲是diaplay变量所在的线程，因此非UI线程其实是非display所在的线程，其可以是任何其它线程，如UI无关的后台作业处理线程、SWT-AWT共用应用中的awt所在线程、其它 display线程(这种情况比较少，一般应用于服务程序，如大量生成的多UI线程，相互之间协调时的调用，如几个UI线程负责地图的绘制，然后交给另外一个UI线程做装饰处理)；
  
   2、跳出当前UI事件处理，安排后续事件。当前display所在的UI线程，在事件处理过程中，需要在执行完毕之后启动另外一个UI处理过程，可以使用 asyncExec，发起另外一个UI线程处理，结束当前的UI处理。有几种情况下需要这么做：A、当前事件处理必须执行完毕，使应用到达一定的状态之后，做另外的UI处理，但是由于SWT、JFace或其它应用框架的存在，当前事件处理完成之后需要应用框架执行一些其它代码之后才可以执行另外的UI处理，否则会导致状态不一致，界面出错。但是当前事件处理完毕之后，不会出现其它事件来触发需要另外执行的代码，此时可以使用asyncExec，在框架的事件处理序列中插入另外一个事件，在当前事件处理完毕之后的某个时刻(一般很快)来执行；B、定时刷新或其它不是很重要的UI *** 作，通过 asyncExec执行，不影响重要的UI事件处理。asyncExec所在的事件队列优先级较低。
  
   3、事件比较密集，而且不均衡，有时非常密集，有时不太密集，为了将事件处理均衡处理，使UI线程始终能够应付自如，而不是延迟重要事件的处理、使用户感到界面迟钝现象，将不重要的事件放到低优先级序列中，从而保证用户响应性，界面整体的有效性。
  
   asyncExec使用时需要注意的问题主要在于两个方面。
   1、响应及时性。可以认为SWT存在两个事件队列，正常UI事件队列，需异步处理的队列，该队列优先级较低，asyncExec对应于SWT低优先级队列，因此有可能在正常队列事件较多、事件处理较慢的时候，asyncExec相关代码不能及时执行的问题，从而导致响应不够及时；
   2、多线程同步问题。假如某段事件处理代码发出多个asyncExec请求，每个asyncExec代码访问同一个变量，假设该变量是整数，第一次发出请求是值为1、第二次为2、第三次为3，所有请求发出，该事件处理完毕时，整数值为5，随后第一次发出的asyncExec请求执行，访问整数变量，此时为 5，而本应该是1，其它几个有类似问题。
当然了，Display也提供了timerExec，可以将其理解为Timer和asyncExec两者的结合，代码在指定时间之后异步执行。

这个很简单，高并发有多种解决方法：
1、从代码上分入手，必须得保证代码没有冗余，不要有废代码；
2、从服务器上入手，高并发一台服务器并发量有限，我们可以采用多台服务器来分担压力；
3、从存储方便入手，像我们一般高并发但是数据却可以不用存到数据库中的，我们就存在内存中，因为读内存的速度是数据库的N倍。

在进行服务器处理的过程中，需要保证数据的正确处理，那么最重要的就是使用不同的数据处理模式进行运算。在整个过程中，可能很多人对服务器的知识并不了解，那么应该如何进行Java开发服务器的线程处理呢，关于线程处理有哪些知识？下面北京北大青鸟为大家介绍关键服务器线程处理的简单知识。

1、BIO线程模型

在JDK14中引入JavaNIO之前，所有基于Java的Socket通信都使用了同步阻塞模式（BIO）。这种请求-响应通信模型简化了上层的应用程序开发上，但在具有性能和可靠性的情况下，存在一个巨大的瓶颈。在一段时间里面，大型应用程序服务器主要是用C或C++开发的，因为它们可以直接使用 *** 作系统提供的异步I/O或AIO功能。

当流量增加且响应时间延迟增加时，JavaBIO开发的服务器软件只能通过硬件的不断扩展来满足并发性和低延迟的情况，这极大地增加了企业的成本和群集大小。系统的不断扩展，系统的可维护性也面临着巨大的挑战，只能通过购买性能更高的硬件服务器来解决问题，这将导致恶性循环的产生。

2、异步非阻塞线程模型

从JDK10到JDK13，Java的I/O类库非常原始。UNIX网络编程中的许多概念或接口未反映在I/O类库中，例如Pipe、Channel、Buffer和Selector等。在发布JDK14的时候，NIO正式发布JDK作为JSR-51。并且它还添加了一个javanio包，为异步I/O开发提供了许多API和库。

3、RPC性能三原则

影响RPC的性能主要有三大元素，其中主要为I/O模型、协议及线程。

I/O模型：使用什么样的通道传递给另一方，BIO，NIO或AIO发送数据，IO模型在很大程度上能够决定框架的性能。

协议：应该使用什么样的通信协议，Rest+JSON或基于TCP的专用二进制协议。参加电脑培训的过程中发现，协议的选择不同，性能模型也不同。内部专用二进制协议的性能通常可以比公共协议更好地设计。

线程：如何读取数据报？在执行读取后的编解码器的哪个线程中，如何分发编码消息，通信线程模型是不同的，并且对性能的影响也非常大。

建议采用缓存处理，按照你说的这种数据量，基于redis的缓存完全可以满足，存取速度可以10W+的，另外，拟采用的hashMap 是ConcurrentHashMap还是其他，页面展示是增量查询还是直接所有的再查询一次，socket数据接收你是用的netty还是mina，这都需要经过仔细的斟酌考虑设计的。有这么大的并发的需求，完全可以考虑做分布式集群的，估计这只是领导想要的目标吧

问题 问范围太广泛 基本架构入手
1基本 服务器 tomcat Apache性能优化
2基本技术框架代码优化
3基本数据库优化 mysqlsqlserveroracle
4服务器数据库集群与布式
5使用高效率间件 redismq等
反说何面高并发要看项目需求驱技术需求解决案
没牛案适合案~

---