在现在这个互联网的时候，所讲的并发，高并发通常是指并发访问，也就是说在某个时间点，有多少个访问都会同时到来。通常一个系统的日PV在千万以上，有可能是一个高并发的系统。在有的公司不会完全走技术的路线，而是全靠机器在堆。
“互联网订票”、“银行系统”、“股票交易”、“12306订票系统”、“电商系统”、“淘宝”、“天猫”等很多系统都是通过并发来实现的，不是所有的秒杀都是秒杀。
话不多说，直接上Xmind：
只有系统的整理知识点，才能找到不足。当然，在学习的过程中如果可以结合案例来学习的话，这样才可以更好的吸收这些知识并且运用到工作中，这个才是我们学习的目的。想提升技术，需要多看书！多看书！多看书！
并发案例（订票系统的案例）
很多小伙伴都会或多或少的有这样一种想法：高并发专题学了那么久，但是，在真正做项目时，仍然不知道如何下手处理高并发业务场景！甚至很多小伙伴仍然停留在只是简单的提供接口（CRUD）阶段，不知道学习的并发知识如何运用到实际项目中，就更别提如何构建高并发系统了！
订票系统案例：某航班只有一张机票，假定有1w个人打开你的网站来订票，问你如何解决并发问题(可扩展到任何高并发网站要考虑的并发读写问题)
问题，1w个人来访问，票没出去前要保证大家都能看到有票，不可能一个人在看到票的时候别人就不能看了。到底谁能抢到，那得看这个人的“运气”（网络快慢等）
其次考虑的问题，并发，1w个人同时点击购买，到底谁能成交？总共只有一张票。
首先我们容易想到和并发相关的几个方案 ：
锁同步同步更多指的是应用程序的层面，多个线程进来，只能一个一个的访问，java中指的是syncrinized关键字。锁也有2个层面，一个是java中谈到的对象锁，用于线程同步；另外一个层面是数据库的锁；如果是分布式的系统，显然只能利用数据库端的锁来实现。
假定我们采用了同步机制或者数据库物理锁机制，如何保证1w个人还能同时看到有票，显然会牺牲性能，在高并发网站中是不可取的。使用hibernate后我们提出了另外一个概念：乐观锁、悲观锁（即传统的物理锁）；
采用乐观锁即可解决此问题。乐观锁意思是不锁定表的情况下，利用业务的控制来解决并发问题，这样即保证数据的并发可读性又保证保存数据的排他性，保证性能的同时解决了并发带来的脏数据问题。
hibernate中如何实现乐观锁：
前提：在现有表当中增加一个冗余字段，version版本号, long类型
原理：
1）只有当前版本号》=数据库表版本号，才能提交
2）提交成功后，版本号version ++
实现很简单：在ormapping增加一属性optimistic-lock="version"即可，以下是样例片段
<hibernate-mapping>
<class name="com.insigma.stock.ABC" optimistic-lock="version" table="T_Stock" schema="STOCK">
上面就是小编介绍的一些并发情况和案例，下面是一篇干货，需要这份并发资料的朋友，帮忙转发+关注，后台私信【学习】二字即可免费获取领取方式。
干货：高并发设计pdf
这份文档分为：基础篇、数据库篇、缓存篇、消息队列篇、分布式服务篇、维护篇、实战篇七篇。
1--基础篇：总共分为六小节
- 主要内容
2--数据库篇：总共分为五小节
- 主要内容
3--缓存篇：总共分为五小节
- 主要内容
上面就是小编介绍的一些并发情况和案例和并发的干货pdf，需要这份并发资料的朋友，帮忙转发+关注，后台私信【学习】二字即可免费获取领取方式。
4--消息队列篇：总共分为四小节
- 主要内容
5--分布式服务篇：总共分为九小节
- 主要内容
6--维护篇：总共分为七小节
- 主要内容
7--实战篇：总共分为四小节
友情提示：上面就是小编介绍的一些并发情况和案例和并发的干货pdf，需要这份并发资料的朋友，帮忙点赞这篇文章，点击小编头像进入个人主页或者si xin即可。
- 主要内容