本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
人的一生离不开死亡和税收；码农的一生离不开bug和代码；代码离不开维护和重构！你写代码的时间越久越离不开高并发！本文根据我的个人经验和网上的一些资料，给大家介绍一些解决高并发的思路和手段。
在 java 中，给我们提供了一个关于高并发的包：java.util.concurrent，简称并发包或J.U.C。java.util.concurrent包是JDK提供的并发为核心包。搞定它，你就可以说是搞定了薪水（需要J.U.C的视频教程的可以到我的上篇文章《尚硅谷Java视频_JUC(java.util.concurrent)视频教程免费下载》中获取）。
java.util.concurrent 包虽好，但是它并不能解决所有的问题。尤其是单机性能达到极限，需要分布式来解决的场景。像12306的抢票，淘宝的双11等。
但是 java.util.concurrent 包给我们提供了很好的并发解决思路。
J.U.C核心由5大块组成：atomic包、locks包、collections包、tools包（AQS）、executor包（线程池）。分别代表原子操作、锁操作、集合队列操作、线程调度操作、线程池操作。也就是说高并发，最终还是要保证原子性。包括锁的竞争，多线程的处理，排队等情况。
那么在架构方面如何处理高并发呢？这就是我今天将要讲的，高并发的处理思路和手段。具体看下图：
处理高并发，估计每个人首先想到的是硬件扩容。在硬件达到极限的情况下，我们应该考虑软件方面的扩容。扩容包括应用和数据库进行水平和垂直扩容。关于扩容，可以参考我的这些文章《大型网站应用中MySQL的架构演变史》、《B/S架构网站的web设计变迁史》、《Google技术架构演变之路》。
其次是应用拆分，将应用服务化。目前最流行的就是微服务解决方案就是 dubbo 和 Spring Cloud 了。关于微服务可以参考我的这些文章《什么是微服务？》、《微服务架构入门》、《微服务架构基础框架Spring Boot和Spring Cloud》、《详解SOA和微服务架构的区别》。另外我的公众号里还有很多关于微服务 dubbo 和 SpringCloud 的视频教程，回复对应的关键字即可免费下载！
再接着是缓存技术，包括 Redis、Memcache 等。这方便可以参考我的这些文章《大型网站离不开的缓存技术》、《Redis 和 Memcached 的区别》、《Redis 是单线程结构，但为何单线程还能支持高并发？》等。公众号里也有对应的视频可以下载！
再接着可能就是分库，分表等操作了。对应的可以参考我的这些文章《MySQL数据库发展周期中所面临的问题及优化方案》、《MySQL 的性能优化最佳实践》、《详解MySQL 的并行数据库》等。
再剩下来想到的可能就是队列了。这方便的技术包括 kafka、RocketMQ、RabbitMQ等。可以参考我的这些文章《Kafka文件的存储机制》、《OpenMessaging访问RocketMQ教程（开发实战）》等。同样的公众号里有对应的视频教程，回复对应关键字即可。
最后剩下的就是一些限流、服务降级、服务熔断、服务监控等方面的内容了。这方面可以防止我们系统发生 OOM，雪崩效应等。
并发呢？就是多个线程在同时访问同一资源。高并发呢？就是发生并发的概率很高并且有可能是有N多个线程在访问同一资源。
最后我说一下，本文主要是帮助大家建立起高并发的知识体系。并不是说我的就是最优的思路和解决手段。
好了，高并发也是一说就明白，一讲就糊涂，一讨论就打架的话题，我就不打脸了！
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » 详解高并发的解决思路与手段