版本号

1.题目描述 比较两个版本号 version1 和 version2。 如果 version1 > version2 返回 1，如果 version1 < version2 返回 -1， 除此之外返回 0。 你可以假设版本字符串非空，并且只包含数字和 . 字符。 . 字符不代表小数点，而是用于分隔数字序列。 例如，2.5 不是“两个半”，也不是“差一半到三”，而是第二版中的第五个小版本。 你可以假设版本号的每一级的默认修订版号为 0。例如，版本号 3.4 的第一级（大版本）和第二级（小版本）修订号分别为 3 和 4。其第三级和第四级修订号均为 0。 示例 1: 输入: version1 = "0.1", version2 = "1.1" 输出: -1 示例 2: 输入: version1 = "1.0.1", version2 = "1" 输出: 1 示例 3: 输入: version1 = "7.5.2.4", version2 = "7.5.3" 输出: -1 示例 4： 输入：version1 = "1.01", version2 = "1.001" 输出：0 解释：忽略前导零，“01” 和 “001” 表示相同的数字 “1”。 示例 5： 输入：version1 = "1.0", version2 = "1.0.0" 输出：0 解释：version1 没有第三级修订号

类文件结构 文章目录 1）平台无关性、语言无关性 2）Class类文件结构 3）字节码指令 概述 平台无关性、语言无关性 ； 实现一次编写，到处运行 各种不同平台的虚拟机与所有平台都使用统一的程序存储格式—— 字节码 ，这是构成平台无关性的基石，而实现语言无关性的基础仍然是虚拟机和字节码存储格式 Java 源代码首先需要使用 Javac 编译器编译成 .class 文件，然后由 JVM 执行 .class 文件，从而程序开始运行。 Java虚拟机只和存储字节码的Class文件这种特定的二进制文件格式关联，且并不关心Class的来源是何种语言 Class类文件结构 Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑的排列在Class文件之中，中间没有添加任何分隔符。 Class文件格式采用一种类似C语言结构体的伪结构来存储数据，这种伪结构中只有两种数据类型： 无符号数和表 magic number:每个Class文件的头4个字节 判断该文件是否为一个能被虚拟机接受的Class文件 版本号 包含主版本号（Major Version）和一系列次版本号（Minor Version） 次版本号 第5和第6个字节 主版本号 第7和第8个字节 判断该文件是否在虚拟机处理的有效范围内 常量池 使用一个前置的容量计数器加上若干个连续的常量项 存放着两大类常量：

首先获取到当前版本号 ： wx.getSystemInfo({ success (res) { console.log(res.model) //获取设备名：iPhone,Meizu...... console.log(res.version) //获取版本号 } }) 版本号比较： function compareVersion(v1, v2) { v1 = v1.split('.') v2 = v2.split('.') var len = Math.max(v1.length, v2.length) while (v1.length < len) { v1.push('0') } while (v2.length < len) { v2.push('0') } for (var i = 0; i < len; i++) { var num1 = parseInt(v1[i]) var num2 = parseInt(v2[i]) if (num1 > num2) { return 1 } else if (num1 < num2) { return -1 } } return 0 } compareVersion('7.0.5', '6.0.6') // => 1 // 1表示 1比2要新 compareVersion('7.0.5', '1.11.0') // => 0 /

目录 配置用户名和邮箱 利用命令完成git基本操作 使用分支 远程仓库（Github） 标签 才发现博客园不支持markdown的标记语法，太恶心了，觉得看着不带劲的可以移步至 https://blog.csdn.net/tonyxiaowai/article/details/103531052 配置用户名和邮箱 ==git config --global user.name '自己的名字'== ==git config --global user.name '自己的邮箱'== 利用命令完成git基本操作 创建仓库 ==git init== 在要被当仓库的文件夹下执行该命令 添加文件 ==git add 文件名== 这一步的作用是将文件添加到暂存区（stage） 提交文件 ==git commit -m "提交描述"== 查看日志 ==git log== 功能为查看日志 ==git log --pretty=oneline== 查看日志，以单行显示 ==git reflog== 功能为查看历史操作记录，比如回退版本后想要重返“未来”可以查看最新的提交版本 查看git状态 ==git status== 查看修改内容 ==git diff 文件名== 版本回退 ==git reset --hard head^== ==git reset --hard 版本号== 当知道对应的版本号时

1.使用subline打开class文件。编码方式选择，以16进制方式显示 只看第一行数据，前面8个字节CA FE BA BE 是固定的，之后4个字节00 00 是次版本号，次版本号后面的4个字节00 33 是jdk的版本号 jdk版本号对应关系如下： 来源： CSDN 作者： 代代1016 链接： https://blog.csdn.net/qq_16909139/article/details/103524192

MySQL的MVCC机制 1、MVCC简介 1.1 MVCC是什么？ MVCC，Multi-Version Concurrency Control，多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问； 1.2 MVCC是为了解决什么？ 大多数的MYSQL事务型存储引擎,如,InnoDB，Falcon以及PBXT都不使用一种简单的行锁机制.事实上,他们都和MVCC–多版本并发控制来一起使用 大家都应该知道,锁机制可以控制并发操作,但是其系统开销较大,而MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销 　　 众所周知，在MYSQL中，MyISAM使用的是表锁，InnoDB使用的是行锁。而InnoDB的事务分为四个隔离级别，其中默认的隔离级别REPEATABLE READ需要两个不同的事务相互之间不能影响，而且还能支持并发，这点悲观锁是达不到的，所以REPEATABLE READ采用的就是乐观锁，而乐观锁的实现采用的就是MVCC。正是因为有了MVCC，才造就了InnoDB强大的事务处理能力。 MVCC解决的问题是读写互相不阻塞的问题，每次更新都产生一个新的版本，读的话可以读历史版本。试想，如果一个数据只有一个版本，那么多个事务对这个数据进行读写是不是需要读写锁来保护? 一个读写事务在运行的过程中在访问数据之前先加读

Linux的内核版本和发行版本 1．内核版本 内核是系统的心脏，是运行程序和管理像磁盘和打印机等硬件设备的核心程序，它提供了一个在裸设备与应用程序间的抽象层。例如，程序本身不需要了解用户的主板芯片集或磁盘控制器的细节就能在高层次上读写磁盘。 内核的开发和规范一直是由Linus领导的开发小组控制着，版本也是惟一的。开发小组每隔一段时间公布新的版本或其修订版，从1991年10月Linus向世界公开发布的内核0.0.2版本（0.0.1版本功能相当简陋所以没有公开发布）到目前最新的内核2.6.22版本，Linux的功能越来越强大。 Linux内核的版本号命名是有一定规则的，版本号的格式通常为“主版本号.次版本号.修正号”。主版本号和次版本号标志着重要的功能变动，修正号表示较小的功能变更。以2.6.22版本为例，2代表主版本号，6代表次版本号，22代表修正号。其中次版本还有特定的意义：如果是偶数数字，就表示该内核是一个可以放心使用的稳定版；如果是奇数数字，则表示该内核加入了某些测试的新功能，是一个内部可能存在着BUG测试版。如2.5.74表示是一个测试版的内核，2.6.22表示是一个稳定版的内核。读者可以到Linux内核官方网站 http://www.kernel.org/ 下载最新的内核代码，如图1-3所示。 图1-3 Linux内核的官方网站 2．发行版本

语义化版本 2.0.0 摘要 版本格式：主版本号.次版本号.修订号，版本号递增规则如下： 主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。 先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。 简介 在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的包越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。 在依赖高的系统中发布新版本包可能很快会成为噩梦。如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）。而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量）。当你专案的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。 作为这个问题的解决方案之一，我提议用一组简单的规则及条件来约束版本号的配置和增长。这些规则是根据（但不局限于）已经被各种封闭、开放源码软件所广泛使用的惯例所设计。为了让这套理论运作，你必须先有定义好的公共 API 。这可以透过文件定义或代码强制要求来实现。无论如何，这套 API 的清楚明了是十分重要的。一旦你定义了公共 API，你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式：X.Y.Z （主版本号.次版本号

一、AtomicReference简介 AtomicReference，顾名思义，就是 以原子方式更新对象引用 。 可以看到，AtomicReference持有一个对象的引用—— value ，并通过Unsafe类来操作该引用: 为什么需要AtomicReference？难道多个线程同时对一个引用变量赋值也会出现并发问题？ 引用变量的赋值本身没有并发问题 ，也就是说对于引用变量var ，类似下面的赋值操作本身就是原子操作: Foo var = ... ; AtomicReference的引入是为了可以用一种 类似乐观锁的方式操作共享资源 ，在某些情景下以提升性能。 我们知道，当多个线程同时访问共享资源时，一般需要以加锁的方式控制并发： volatile Foo sharedValue = value; Lock lock = new ReentrantLock(); lock.lock(); try{ // 操作共享资源sharedValue } finally{ lock.unlock(); } 上述访问方式其实是一种对共享资源加 悲观锁 的访问方式。 而AtomicReference提供了 以无锁方式访问共享资源 的能力，看看如何通过AtomicReference保证线程安全，来看个具体的例子： public class AtomicRefTest { public

1. MVCC简介 1.1 什么是MVCC MVCC是一种多版本并发控制机制。 1.2 MVCC是为了解决什么问题? 大多数的MYSQL事务型存储引擎,如,InnoDB，Falcon以及PBXT都不使用一种简单的行锁机制.事实上,他们都和MVCC–多版本并发控制来一起使用. 大家都应该知道,锁机制可以控制并发操作,但是其系统开销较大,而MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销. 1.3 MVCC实现 MVCC是通过保存数据在某个时间点的快照来实现的. 不同存储引擎的MVCC. 不同存储引擎的MVCC实现是不同的,典型的有乐观并发控制和悲观并发控制. 2.MVCC 具体实现分析 下面,我们通过InnoDB的MVCC实现来分析MVCC使怎样进行并发控制的. InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的,这两个列，分别保存了这个行的创建时间，一个保存的是行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID)，没开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID.下面看一下在REPEATABLE READ隔离级别下,MVCC具体是如何操作的. 2.1简单的小例子 create table yang( id int primary key auto_increment, name