java高并发解决方案.docx

1、java高并发解决方案java,高并发解决方案篇一：Java高并发程序设计 Java 高并发程序设计 第一课前沿 ? 在计算密集型的领域中非常适用并行程序 ? 多核CPU的产生促使了并行程序的设计，摩尔定律的失效，芯片的性能不能提高，4GHz已经是当下最高的频率，从而产生多核CPU的出现。 ? 活锁 ： 两个资源 A、B， 进程1和2 分别占用A和B时发现不能工作， 就同时释放掉，然后又同时分别占用B和A 如此反复！出现活锁 ? 阻塞： 第二课 Java并行程序基础 ? 线程是比进程更细粒度的执行单元， 可以说是属于进程的一个子集 ?7, Thread 类的run()方法实现于Runnable

2、 接口，如果直接调用run()方法，不会启动新的线程，而是在当前线程下运行， start() 方法会开启一个新的线程。 两种方式， 1 重载run方法 2，实现Ruanable接口 8, Thread.Interrupt() 是一种比较的让线程终止的方法 优雅的方法 ， 不会立刻停止掉该程序 ， 根据程序的设计，而是根据该程序的设计，当执行完该程序的一次循环之后， 在下次循环程序开始之前中断， 保证该程序的数据完整性。 9，try Thread.sleep(2000); catch (InterruptedException e) / /设置中断状态，抛出异常后会清除中断标记位 e.print

3、StackTrace(); 10，查看当前被挂起的进程命令 jps 查看进程中具体线程的信息 jstack 5880 11， ? 等待线程结束 join(),其本质是判断线程是否还存活，如果一直存活那么通 知调用该线程的其他线程等待，如果结束有JVM 调用notifyAll()唤醒所有等待该线程的线程。 f (millis = 0) while (isAlive() wait(0); ? 12，守护线程在后台默默的完成一些系统性的服务，比如垃圾回收与JIT线程等。 但非守护线程结束时， JVM不会因为守护线程而继续执行，随之而推出。 13，线程优先级的运行时候只是在概率上发生的可能下要大！ 1

4、4，synchronized 加锁的三种方式。 ? 对象实例加锁 ? 实例方法加锁 ? 类级别实例方法加锁 谦让 yield() 第三课 Java内存模型和线程安全 ? 同一个操作在两条不同的指令之间是不能够一起做的，因为他们会使用同一个硬 件设备. ? 可见性问题是各个层面优化产生的 ? ? Java并 原子性 发编程的的三个重要的概念。可见性 有序性，并发程序会发生指令重排，导致语句执行顺序发生变化的情况，虽然处理器会对指令进行重排序，但是它会保证程序最终结果会和代码顺序执行结果相同；指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。 ? 要想并发程序正确地执行，必须要保

5、证原子性、可见性以及有序性。只要有一个没 有被保证，就有可能会导致程序运行不正确。 第四课无锁 ? 无锁的性能要远好于阻塞的执行方式 ? 前导零 是指 转换成二进制的时候 前面为零的个数（LeadingZeros） ? 无锁实现Stack堆栈，见作业 第五课 JDK并发包1 1. Reentrantlock是属于Synchronized的增强版，多增加了一些特有的功能 2. ConcurrentHashMap 属于高并发的解决方案 3. HashMap 发生大量冲突的时候，会退化成一个链表，引起性能降低 4. BlockingQueue 阻塞队列，会引起线程的阻塞，不是一个高性能的并发实现，内

6、部实现 机制采用了加锁，同时只有一个线程进入 第六课 JDK并发包2 1， 线程池实现了对线程的复用，避免了线程的多次创建和销毁， 节省了CPU处理时间。 2， Java内置线程池，Callable 与Runnable 的区别是有无返回值 3， ForkJoinPool 说明该线程池是如何工作的 第七课设计模式 1, 采用静态内部类来实现单例模式，可以保证在StaticSingleton 类中只调用 getInstance()方法时才会初始化类，从而保证了在操作该类其他字段的时候，不会被初始化。 篇二：ActiveMQ高并发处理方案 高并发发送消息异常解决方法： 现象：使用10个线程每100m

7、s发送一条消息，大约3000多条后，出现异常，所有线程停 止： javax.jms.JMSException: Could not connect to broker URL: tcp:/localhost:61616. Reason:.BindException: Address already in use: connect; nested exception is .BindException: Address already in use: connect 原因：创建了太多jms连接没有来得及回收 解决方法：使用jms连接池 原来的配置： <bean <property n

8、ame=environment<props <prop key=java.naming.factory.initial org.apache.activemq.jndi.ActiveMQInitialContextFactory </prop <prop key=java.naming.provider.urltcp:/huzq-linux:61616</prop </props </property </bean <bean <property name=jndiName <valueConnectionFactory<

9、/value</property <property name=jndiTemplate <ref local=jndiTemplate</ref </property </bean 修改为：解决activemq多消费者并发处理 遇到一个现象，如果activemq队列积压了数据的话，如果在spring中启动listner，只有一个consumer执行，查阅了很多资料，无果，后来偶尔通过activemq的监控网页看到消费者列表中，只有一个消费者有等待处理的数据，其他都没有，如下图： 由此得知，activemq有一定机制将队列中的数据交给consumer处理，这

10、个机制就是数据的数量分配，查资料得知，默认是1000，因此，把这个值调小就可以了。 在客户端的连接url中，修改为tcp:/ipaddr:61616?jms.prefetchPolicy.all=2 这样基本消费者就分配公平了，不会出现一个消费者忙死，另外的消费者闲死了。 为高并发程序部署ActiveMQ 使用ActiveMQ来扩展你的应用程序需要一些时间并要花一些精力.本节中我们将介绍三种技术用于扩展应用程序.我们将从垂直扩展开始,这种扩展方式中,单个代理需要处理成千上万的连接和消息队列. 接下来我们将介绍水平扩展,这种扩展方式需要处理比前一种方式更多的网络连接.最后,我们介绍的传输负载分流

11、,可以在扩展和性能间得到平衡,但是会增加ActiveMQ程序的复杂性. 1. 垂直扩展: 垂直扩展是一种用于增加单个ActiveMQ代理连接数(因而也增加了负载能力)的技术.默认情况下,ActiveMQ的被设计成尽可高效的传输消息以确保低延迟和良好的性能.但是,你也可以进行一些配置使的ActiveMQ代理可以同时处理大量并发的连接以及大量的消息队列.默认情况下,ActiveMQ使用阻塞IO来处理传输连接,这种方式为每一个连接分配一个线程.你可以为ActiveMQ代理使用非阻塞IO(同时客户端可以使用默认的传输)以减少线程的使用.可以在ActiveMQ的配置文件中通过传输连接器配置非阻塞IO.下

12、面的是配置非阻塞IO的示例 代码：配置NIO传输连接器除了为每个连接使用一个线程的阻塞IO,ActiveMQ还可以为每一个客户端连接使用一个消息分发线程.你可以通过将系统参数org.apache.activemq.UseDedicatedTaskRunner设置为false来设置ActiveMQ使用一个搞线程池.下面是一个示例: 确保ActiveMQ代理用于足够的内存来处理大量的并发连接,需要分两步进行: 首先,你需要确保运行ActiveMQ的JVM在启动之前已经配置了足够的内存.可以使用 JVM的-Xmx选项来配置,如下所示: 其次,需要确保JVM配置了适量的专门供ActiveMQ代理使用的

13、内存.这个配置可用通过<system-Usage 元素的limit属性来配置.一个不错的根据经验得到的规则时,在连接数为几百个时配置512MB为最小内存. 如果测试发现内存不够用,可以增加内存配置.你可以按照下面代码示例来配置ActiveMQ使用的内存限制: 代码:为ActiveMQ代理设置内存使用限制 同样,简易减少每个连接的CPU负载.如果你正使用Open-Wire格式的消息,关闭tight encoding选项,开启该选项会导致CPU占有过多.Tight encoding选项可以通过客户端连接的URI中的参数设置以便关闭该选项.下面是示例代码: 了解了一些扩展ActiveMQ代理处

14、理大量连接的调优选项之后,我们在了解一些让ActiveMQ处理大量消息队列的调优选项.默认的消息队列配置中使用一个独立的线程负责将消息存储中的消息提取到消息队列中而后再被分发到对其感兴趣的消息消费者.如果有大量的消息队列,建议通过启用optimizeDispatch这个属性 改善这个特性,示例代码如下所示:注意,代码清单中使用通配符表示该配置会递归的应用到所有的消息队列中. 为确保扩展配置既可以处理大量连接也可以处理海量消息队列,请使用JDBC或更新更快的KahaDB消息存储.默认情况下ActiveMQ使用KahaDB消息存储. 到目前位置,我们关注了连接数扩展,减少线程使用以及选择正确的消息

15、存储.下面的示例配置代码展示了ActiveMQ配置中为扩展进行了调优: 代码：为扩展进行调优的配置示例代码 <broker xmlns=http:/activemq.apache.org/schema/core brokerName=amq-broker dataDirectory=$activemq.base/data <persistenceAdapter <kahaDB directory=$activemq.base/data journalMaxFileLength=32mb/ </persistenceAdapter <destinationPolic

16、y <policyMap <policyEntries <policyEntry queue= optimizedDispatch=true/ </policyEntries </policyMap </destinationPolicy <systemUsage <systemUsage <memoryUsage <memoryUsage limit=512 mb/ </memoryUsage <storeUsage <storeUsage limit=10 gb name=foo/ </storeUsage

17、 <tempUsage <tempUsage limit=1 gb/ </tempUsage </systemUsage </systemUsage篇三：大型互联网站解决高并发的常见策略 大型互联网站解决高并发的常见策略 作者: H.E. | 您可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明 网址: /article/high-concurrent-common-coping-strategies.html 豆瓣读书向你推荐有关Hadoop、J2ee企业顾问、Linux/Unix、MapReduce、NoSQL、web、云计算、分布式、存储、性

18、能、架构设计、类别的图书。 一个运营的系统在正式上线后将会遇到各种层级的高并发请求，因此我们必须对此做出相应的策略和技术解决方案，首先我们需要认清系统的高并发由3个层面导致： 1. 传输层 大量用户对系统请求后，将会造成网络带宽和Web服务器的I/O瓶颈。 2. 计算层 接收大量用户请求进行计算，将会造成业务服务器和业务支撑服务器的瓶颈。 3. 存储层 传输层和计算层将会产生大量的数据，数据量暴增，将会导致数据库和储存上的瓶颈。 针对以上将会造成的系统高并发瓶颈，我们需要采用不同的技术手段解决。 从总体上来看 1.首先需要解决网络带宽和Web请求的高并发，需要合理的加大服务器和带宽的投入，并且

19、需要充分的利用系统中软件、硬件的缓存机制，将能缓存的内容都进行缓存存储，减少计算层和存储层的压力。 2.其次需要对业务服务器和业务支撑服务器进行合理的分层，并且采用并行计算和分布式算法对大量计算进行处理，并且在开发的过程中需要采用Java SDK中并发包(Concurrency)进行编码实现。 3.存储层需要采用分布式文件服务器和列式的存储服务器进行构建，支撑海量数据的存放和读取，并且还要对关系型数据进行深层次的配置参数优化。 4.我们还需要清楚的认识到，将来根据系统运行的状态以及平台中不同的业务场景循序渐进的进行调整和优化。 对于大型系统来说，采用的技术是涉及面非常广，从硬件到软件、编程语言

20、、数据库、WebServer、防火墙等各个领域都有了很高的要求。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：将会使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。 但是除了这几个方面，还没法根本解决面临的高负载和高并发问题，所以需要将计算和负载的压力分载到每个计算机上，使用不同的服务器集群机组进行分布式和并行计算，面对所产生的压力，下面这张图清晰的描述了，我们对系统中不同的计算瓶颈采用的不同解决手段，如图所示： 查看大图请点击这里 以下描述是针对不同层面产生的计算压力所采用的计算策略，清单如下： 传输层 1. CDN 网络链路出口进行压力分

21、载，通过CDN让用户访问最近的数据缓存。 2. 智能双路 针对电信、网通不同的访问用户访问请求，对应用户访问请求进行服务器带宽的智能切换。 3. LVS 对用户的请求进行压力分载，并且实现多种负载均衡的策略，也可以选择使用HA-Proxy实现。 4. HA-Proxy 针对Web服务器进行方向代理，通过HA-Proxy将用户的请求分发到不同的Web服务器上。 5. Long-Polling 在Web服务器上采用的一种策略，专门针对某个用户需要不断频繁的轮询访问。 6. Session2Cache 将用户的会话进行集中处理，存放在中央式的缓存服务器当中，减少服务器之间的会话通信 计算层 1. M

22、apReduce 采用最经典的分布式算法对海量数据进行处理，将计算进行分载。 2. BSP BSP(Bulk Synchronous Parallel-大型同步模型)算法是基于MPI算法的基础进行演化，运用在系统中并行计算的部分。3. Result Cache将计算的一部分结果进行缓存，缓解对存储层读取的请求。 4. Scatter/Gather 中间通过一个服务器进行中转，将大量的请求分发给内部的服务器进行计算，类似前端的web反向代理。 存储层 1. 读写分离 由于系统的读大于写的频率，数据库架构采用了1主/多从，双主多从的策略，所以我们将会将读和写进行分离，并且将大量的读请求分散给多台不同的(Slave)服务器。 2. 分区策略 系统采用不同的时间段作为分区的主要策略，提高对数据的读写性能。 3. Sharding(转 载 于:wWW.xlTkWJ.Com 小 龙文 档 网:java,高并发解决方案) 一台数据库将很快无法满足大量并发，需要使用库表散列，将数据库中的数据进行分散存储。 4. Column-Based 使用在海量数据中的查询功能，采用列模式的存储方式将可以有效的提高系统查询效率。 end相关热词搜索：并发 解决方案 java java如何解决高并发 网站高并发解决方案