版本号

参考： https://blog.csdn.net/weixin_41922289/article/details/88882325 参考： https://blog.csdn.net/weixin_39651041/article/details/79985715 参考： https://blog.csdn.net/C_J33/article/details/79487941 最后也给大佬级的文章总结： https://blog.csdn.net/mysteryhaohao/article/details/51669741 ，整理的非常全 目录 乐观锁 悲观锁 乐观锁和悲观锁的区别 排它锁（写锁） 共享锁（读锁） 更新锁 活锁 死锁 意向锁： 观锁和悲观锁的用处 保证数据安全，处理高并发访问； 乐观锁 概念： 乐观锁就如同他的名字一样，当其他人（线程）去取数据的时候，总是认为别人不会修改数据，总不会发生并发问题，所以因此没有上锁，只有在线程提交数据时会通过检查版本号的形式检测数据有没有被修改过。一般会在数据表中添加版本号（Version）字段来表示被修改的次数，当数据被修改，version+1，只有在version字段和当前数据库的version值相同时，才提交成功 理解： 谁都可以修改，修改完了提交的时候，判断版本号（一般情况），相同则修改，不同则驳回； 实现：

来源： https://www.cnblogs.com/miaoweiye/p/12015637.html

悲观锁 介绍 这里是引悲观锁表示一种悲观的状态，就是总是假设最坏的状态。每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（ 共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程 ）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。 乐观锁 介绍 总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。 乐观锁适用于多读的应用类型，这样可以提高吞吐量 ，像数据库提供的类似于 write_condition机制 ，其实都是提供的乐观锁。在Java中 java.util.concurrent.atomic 包下面的原子变量类就是使用了乐观锁的一种实现方式 CAS 实现的。 两种锁使用的场景 从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像 乐观锁适用于写比较少的情况下（多读场景） ，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突

乐观锁（ Optimistic Locking ） 相对 悲观锁 而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长 事务 而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。 示例 如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用 悲观锁 机制，也就意味着整个操作过 程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作 员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。 乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本 （ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识

第一步：git checkout [分支] 切换到要恢复的分支上； 第二步：git reflog 查看历史版本号，找到要恢复的版本号； 第三步：git reset --hard [版本号] 将本地代码回退到指定版本； 第四步： git push -f 将本地代码强制提交，覆盖远程git服务器代码； 这样就可以达到目的，恢复merge之前版本的代码. 来源： CSDN 作者： aa19891204 链接： https://blog.csdn.net/aa19891204/article/details/103458807

Centos7.7.1908 安装Nginx最新版本 实战教程 1.首先确定一下自己系统的版本，可以使用命令cat /etc/redhat-release 查看系统版本 2.拿到一个系统第一步最好把系统更新一下更新时间可能会有点慢，耐心等待一下就好啦！ // 更新系统 sudo yum update - y 3.安装nginx之前需要安装nginx需要的相关组件，以及上nginx官网看一下nginx的最新版本号，然后把它的最新版本号的安装压缩包下载到本地。 我们先来安装一下nginx需要的相关组件 3.1需要gcc，系统自带了，如果没有的话，需要先安装（gcc是一款C语言编译器） // 安装命令 yum install gcc - c ++ 3.2需要pcre（nginx需要用到伪静态匹配规则用到正则需要安装这个） // 安装命令 yum install - y pcre pcre - devel 3.3需要zlib（kafka消息中间件的C/C++客户端实现）的编译依赖zlib-devel库，需要预先安装zlib-devel） // 安装命令 yum install - y zlib zlib - devel 3.4如果需要支持ssl的话，安装openssl（一个C语言函数库，是对SSL协议的实现，可以实现https访问） // 安装命令 yum install - y

本文详解的讲解了使用IDEA创建Maven项目，及Maven的基础入门。 1、打开IDEA，右上角选择File->New->Project 2、如图中所示选择Maven（可按自己所需添加，否则加载时速度很慢） 3、添加项目所需Groupld,ArtifactId,Version（后文会详细说明三者的配置要求）小编在这自己命名 4、设置Project name（项目名）Project location（工作区） 5、由于小编全部添加配置文件，所以等待时间较长。 6、耐心等待后右下角出现方框，如下：点击圆圈中的选项！！！（自动配置相关文件） 7、接下来我们看看它的文件结构，如下图： （1）在大多数情况下，把项目的主代码放到 src/main/java 目录下（遵循Maven约定），如果没有其他的配置，Maven在运行时将自动搜寻该目录下的主代码。 （2）为了使项目的结构保持清晰，所以IDEA自动创建了 test 文件，将主代码和测试代码分别放到了独立的目录中。 （3）pom.xml为Maven的核心配置文件，它的全称为（Project Object Model，项目对象模型），我们在使用Maven的时候也通常在这个pom .xml 中配置。 8、pom.xml ！！！核心配置 <?xml version="1.0" encoding="UTF-8"?> <project xmlns=

Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。 本文总结了一些Git的常用 命令，以供参考： 1、在Windows上安装Git 安装完成后，还需要最后一步设置，在命令行输入： g i t c o n f i g – g l o b a l u s e r . n a m e “ Y o u r N a m e ” git config –global user.email “email@example.com” 2、创建版本库 首先，选择一个合适的地方，创建一个空目录： $ cd /d/appData $ mkdir gitRepo $ cd gitRepo $ pwd /d/appData/gitRepo ##pwd命令用于显示当前目录 然后，通过git init命令把这个目录变成Git可以管理的仓库： $ git init Initialized empty Git repository in /d/appData/gitRepo/.git/ 3、把文件添加到版本库 $ git add index.txt

前言: 我们都知道事务的几种性质，数据库为了维护这些性质，尤其是一致性和隔离性，一般使用加锁这种方式。同时数据库又是个高并发的应用，同一时间会有大量的并发访问，如果加锁过度，会极大的降低并发处理能力。所以对于加锁的处理，可以说就是数据库对于事务处理的精髓所在。这里通过分析MySQL中InnoDB引擎的加锁机制，来抛砖引玉，让读者更好的理解，在事务处理中数据库到底做了什么。 #一次封锁or两段锁？ 因为有大量的并发访问，为了预防死锁，一般应用中推荐使用一次封锁法，就是在方法的开始阶段，已经预先知道会用到哪些数据，然后全部锁住，在方法运行之后，再全部解锁。这种方式可以有效的避免循环死锁，但在数据库中却不适用，因为在事务开始阶段，数据库并不知道会用到哪些数据。 数据库遵循的是两段锁协议，将事务分成两个阶段，加锁阶段和解锁阶段（所以叫两段锁） 加锁阶段：在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁（共享锁，其它事务可以继续加共享锁，但不能加排它锁），在进行写操作之前要申请并获得X锁（排它锁，其它事务不能再获得任何锁）。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。 解锁阶段：当事务释放了一个封锁以后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。 事务 加锁/解锁处理 begin； insert into test .....

在搭建svn服务器之前我们必须要明白 为什么要使用svn： 是为了版本控制 那什么是版本控制： 版本控制是一种软件工程技巧，借此能在软件开发中确保不同人所编辑的同一 代码文件都能得到同步。 版本控制的其他作用：版本控制可以让版本库中的任意一个文件恢复到任意一 个历史 版本，而且还可以追溯任意版本中任意一行在什么时候被什么人修改过 ， 版本控制还可以随时恢复以前某个版本. 1 并发修改： 多个开发人员同时对同一个文件进行修改 （重要） 2 并发提交： 版本控制中的版本记录，是需要开发人员的提交操作来触发的，也就是说只有 提交才会记录版本号，否则不会记录版本号；如果修改了多个文件后提交那么 CVS 会一个一个提交，每个文件被修改后都会记录一个不同版本号，而 SVN 和 GIT 可以同时提交多个文件的修改，而且这一次被修改的多个文件记录的是 同一个版本号；那么这两种方式各有优缺点，每个文件都会记录一个版本号， 就会占用很大的磁盘空间，但是定位 BUG 十分方便只需定位版本号中即可， 但 SVN 和 GIT 就需要从批量的文件中查找，十分困难。 3 历史轨迹： 如果说一个文件的文件名称被修改了那么 CVS 就无法追踪到修改文件名之前的 版本了但 SVN 和 GIT 依然可以追踪所有的历史版本。 4 分布式： 指的是是否需要一台专门的服务器来运行版本控制系统， CVS,SVN 是集中式