- 博客(335)
- 收藏
- 关注
RSS订阅原创 【JVM】执行引擎、JIT、逃逸分析(二)
针对的是热点代码(触发JIT的条件)Client模式:32bit才有Server模式:64bit触发条件后，谁来编译，编译线程C1:Client模式下C2: Server模式下JDK6之后，混合在一起，热点代码((统计的并不是被调用的绝对次数，而是一个相对的执行频率，一段时间内方法被调用的次数))其中包括但是热点代码会有一个热度衰减的概念，
2024-08-29 10:53:36
1235
原创 【JVM】执行引擎、JIT、逃逸分析(一)
分成两个角度来看1.触发JIT之前javac编译，java运行2.触发JIT之后，运行期即时编译(C1、C2)+解释执行(模板解释器比字节码解释器高效很多)
2024-08-29 10:49:46
1285
原创 【JVM】垃圾收集器与GC日志(二)
ZGC是一款JDK11中新加入的具有实验性质的低延迟垃圾收集器，ZGC可以说源自于Azul System公司开发的C4(Concurrent Continuously Compacting Collector)收集器参考文章：https://wiki.openjdk.java.net/display/zgc/Main。
2024-08-28 10:49:47
1348
原创 【JVM】垃圾收集器与GC日志(一)
串行:一个GC线程运行并行(Parallel):指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。并发(Concurrent):指用户线程与垃圾收集线程同时执行(但不一定是并行的，可能会交替执行)，用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。
2024-08-28 09:24:10
1787
原创 【JVM】垃圾回收算法(二)
所有的垃圾回收算法都要经历标记阶段。如果GC线程在标记的时候暂停所有用户线程(STW)，那就没三色标记什么事儿了，但是这样会有一个问题，用户线程需要等到GC线程标记完才能运行，给用户的感觉就是很卡，用户体验很差。现在主流的垃圾收集器都支持并发标记。什么是并发标记呢？就是标记的时候不暂停或少暂停用户线程，一起运行。这势必会带来三个问题:多标、少标、漏标。垃圾收集器是如何解决这个问题的呢？三色标记+读写屏障。
2024-08-27 11:02:33
1073
原创 【JVM】垃圾回收算法(一)
Java程序在运行过程中会产生大量的对象，但是内存大小是有限的，如果光用而不释放，那内存迟早被耗尽。如C/C++程序，需要程序员手动释放内存，Java则不需要，是由垃圾回收期去自动回收。垃圾回收器回收内存至少需要做两件事情:标记垃圾、回收垃圾。于是诞生了很多算法。
2024-08-27 10:48:54
1106
原创 【JVM】OOM与调优(二)
该命令是纯Java编写的-q:只显示Java进程的ID-m:输出Java进程的ID + main函数所在类的名字 + 传递给main函数的参数-l:输出Java进程的ID+main函数所在类的全限定名(包名+类名)-v:输出Java进程的ID+main函数所在类的名称+传递给JVM的参数应用：可以通过次方式快速查看JVM参数是否设置成功。
2024-08-26 17:12:29
1236
原创 【JVM】亿级流量调优(二)
要突破32G内存瓶颈的话，需要改写8字节对齐这条规则，8字节对齐的话，瓶颈是32G,16字节对齐，瓶颈也会扩大一倍，变成64G.但是这样需要考虑内存的使用率，因为在对齐填充的时候，补充的都是空白地址，也就是说在突破瓶颈的同时，也会带来内存空间的浪费。现在64位机器，并没有完全使用64位地址来表示，只使用了48位，剩下16位保留。也就是说，64位机器上最大使用的内存是2的48次方，原因在于CPU还没有强大到能处理这么大的内存，受制于CPU的算力例如:8字节对齐:17B+7B=24B。
2024-08-25 10:10:50
1177
原创 【JVM】亿级流量调优(一)
前面的klass模型，它是Java类的元信息在JVM中的存在形式。这个oop模型是Java对象在JVM中的存在形式。
2024-08-25 10:06:52
1002
原创 【JVM】剖析字符串与数组的底层实现(二)
jdk8:底层是一个char[]数组jdk9及之后:底层是一个byte[]数组一个中文占两个字节，一个char占两个字节，一个byte占一个字节Jdk9及之后的版本中，多了一个code属性，这个属性标记是告诉调用者按几个字节来取的问题，如果按byte存储的话，存不是什么问题，问题是如何取呢？
2024-08-23 11:53:35
1124
原创 【JVM】剖析字符串与数组的底层实现(一)
这里要明确一点的是，在Jdk6以及以前的版本中，字符串的常量池是放在堆的Perm区的，Perm区是一个类静态的区域，主要存储一些加载类的信息，常量池，方法片段等内容，默认大小只有4m，一旦常量池中大量使用intern是会直接产生java.lang.OutOfMemoryError:PermGen Space错误的。JDK1.6及之前:有永久代，运行时常量池在永久代，运行时常量池包含字符串常量池，Perm区域只有4m,一旦常量池大量使用intern很容易发生永久代的OOM。为什么输出会有这些变化呢？
2024-08-23 11:40:38
1138
原创 【JVM】JVM内存模型与操作系统内存模型(二)
与虚拟机栈发挥的作用是相似的，他们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的Native方法服务。在虚拟机规范中对本地方法栈中使用、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机 比如(SUn HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryErr异常。
2024-08-22 10:51:00
938
原创 【JVM】JVM内存模型与操作系统内存模型(一)
可以这样理解:JVM内存模型其实就是JVM在启动的时候从操作系统内存中要了一块大内存，然后将这个大内存分成五个区域:方法区、堆区、虚拟机栈、本地方法栈、本地方法栈、程序计数器.其实叫JVM运行时区域更合适。但是要区分JVM内存模型与JMM(Java Memory Model)InstanceKlass:类的元信息(方法区)InstanceMirrorKlass:镜像类Class对象(堆区)四个名词:class文件:即硬盘上的.class文件。
2024-08-22 10:45:13
1417
原创 【JVM】JVM解析字节码文件过程(二)
在Java字节码中，field_info结构是用来描述类或接口中的字段(成员变量的)。每个field_info结构对应类文件中的一个字段。其中它的组成部分包括如下：1.access_flags:访问标志,表示字段的访问级别(如public, private, protected, static等)和其他属性(如final volatile等)2.name_index:字段名的索引，它是一个指向常量池的索引，常量池中的对应条目包含字段的名称。
2024-08-21 11:01:17
1187
1
原创 【JVM】类加载器、双亲委派、SPI(二)
元空间内部给各个类加载器划分了内存区域。另外还需要注意一点的是，方法区会有碎片化问题，方法区的垃圾回收通常被称为类的卸载。方法区回收之后是没有整理的。
2024-08-20 08:22:14
1024
原创 【JVM】类加载器、双亲委派、SPI(一)
实现方式，需要继承java.lang.ClassLoader类,通过源码查看我们也得知了ClassLoader在loadClass的时候不会立马触发解析阶段，因为源码里面就写死了是false.懒汉模式，你可能听过loadClass()和findClass()方法，两者的职责是不一样的loadClass方法与findClass方法分析:1.loadClass方法是ClassLoader类中最常用的方法之一，它负责加载指定的类。它的主要特点是:1.1 它是一个public方法，可以被外部类调用。
2024-08-20 08:17:42
912
原创 【JVM】深入理解类加载机制(二)
Hotspot Debugger(HSDB):JDK原生自带以Windows系统为例，jdk8的环境，在jdk的lib目录下，启动之前，你需要确保你进入的lib目录和你当前的JAVA_HOME配置的JDK是相同的，否则可能会出现无法加载libarary的异常，进而无法使用HSDB,命令如下调节字体大小的方法，添加环境变量JAVA_TOOL_OPTIONS这里需要用attach到一个java进程，利用jps可以查看到相关指令将进程号输入进去，我这里换了一个程序，进程号不同。
2024-08-19 09:00:30
830
原创 【JVM】深入理解类加载机制(一)
Java的每个类，在JVM中都有一个对应的Klass类实例与之对应，存储类的元信息如:常量池、属性信息、方法信息…从继承关系上也能看出来，类的元信息是存储在元空间的。总结:非数组:InstanceKlass -> 普通的类在JVM中对应的C++类 方法区InstanceMirrorKlass -> 对应的是Class对象 镜像类 堆区数组:基本类型数组引用类型数组: ObjArrayKlass为什么还要有镜像类？是为了安全，由JVM控制可以将哪些参数返回给用户。
2024-08-19 08:54:57
979
原创 【JVM】跟我一起来编译OpenJDK
作为一名Javer，应该不少人都想编译一下OpenJDK然后在项目中用上它，自己还可以在OpenJDK中加入自己的东西，而不用受限于Oracle官网上的JDK,市面上还有很多技术也是运行在JVM之上的，这更加说明了研究JVM的重要性，比如Kotlin、Groovy、JRuby、Jython、Scala等等，接下来让我们一起探索JVM吧~
2024-07-16 22:08:22
983
原创 【MySQL】RedoLog日志和Binlog日志哪个先写的问题?
1.自动为每个事务分配一个唯一的ID(XID)。这个ID很重要，是两阶段提交的核心2.COMMIT会被自动的分成Prepare和Commit两个阶段3.Binlog会被当作事务协调者(Transaction Coordinator) Binlog Event会被当作协调者日志binlog在2PC中充当了事务的协调者(Transaction Coordinator)由binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。
2024-07-16 21:06:59
1011
原创 MySQL之MySQL用户工具(二)
以过往的经验来看，大多数MySQL商店需要提供两种类型的监测工具:健康监测工具——检测到异常时告警——和为趋势、诊断、问题排查、容量规划等记录指标的工具。大多数系统仅在这些任务中的一个方面做得很好，而不能两者兼顾。更不幸的是，有十几种工具可选，使得评估和选择一款适合的工具非常耗时。许多监控系统不是专门为MySQL服务器设计。它们是通用系统，用于周期性地检测许多类型的资源，从及其到路由再到软件(例如MySQL)。它们一般有某些类型的插件架构，经常会伴随有一些MySQL插件
2024-07-08 21:33:47
754
原创 MySQL之备份与恢复和MySQL用户工具(一)
MySQL服务器发行包中并没有包含针对许多常用任务的工具，例如监控服务器或比较不同服务器间数据的工具。幸运的是，Oracle的商业版提供了一些扩展工具，并且MySQL活跃的开源社区和第三方公司也提供了一系列的工具，降低了自己"重复发明轮子"的需要。
2024-07-08 08:54:14
1085
原创 MySQL之备份与恢复(十)
有各种各样的好的和不是那么好的备份工具。我们喜欢对LVM使用mylvmbackup做快照备份，使用Percona Xtrabackup(开源)或MySQL Enterprise Backup(收费)做InnoDB热备份。不建议对大数据量使用mysqldump,因为它对服务器有影响，并且漫长的还原时间不可预知。有一些备份工具已经出现多年了，不幸的是有些已经过时。最明显的例子是Maatkkit的mk-parallel-dump。它从没有正确运行，甚至被重新设计过好几次还是不行。
2024-07-07 12:29:28
1140
原创 MySQL之备份与恢复(九)
复制和基于时间点的恢复使用的是相同的技术:服务器的二进制日志。这意味着复制在恢复时会是个非常有帮助的工具，哪怕方式不是很明显。下面将演示一些可以用到的方法。这里列出来的不是一个完整的列表，但应该可以为你根据需求设计恢复方案带来一些想法。记得编写脚本，并且对恢复过程中需要用到的所有技术进行预演。shijian只有没有任何多表的UPDATE、DELETE或INSERT语句操作这个表时，上述流程才是可行的。
2024-07-07 10:31:03
1055
原创 MySQL之备份与恢复(八)
如果还原的是逻辑备份而不是物理备份，则与使用操作系统简单地复制文件到适当位置的方式不同，需要使用MySQL服务器本身来加载数据到表中。在加载导出文件之前，应该先花一点时间考虑文件有多大，需要多久加载完，以及在启动之前还需要做什么事情，例如通知用户或禁用掉部分应用。禁掉二进制日志也是个好主意，除非需要将还原操作复制到备库:服务器加载一个巨大的导出文件的代价很高，并且写二进制日志会增加更多的(可能没有必要的)开销。加载巨大的文件对于一些存储引擎也有影响。
2024-07-06 12:01:07
1074
原创 MySQL之备份与恢复(七)
LVM快照备份也是有开销的。服务器写到原始卷的越多，引发的额外开销也越多。当服务器随机修改许多不同块时，磁头需要需要自写时复制空间来来回回寻址，并且将数据的老版本写到写时复制空间。从快照中读取也有开销，因为LVM需要从原始卷中读取大部分数据。只有快照创建后修改过的数据从写时复制空间读取；因此，逻辑顺序读取快照数据实际上也可能导致磁头来回移动。所以应该为此规划好快照。快照实际上会导致原始卷和快照都比正常的读/写性能要差——如果使用过多的写时复制空间，性能可能会差很多。
2024-07-06 09:36:13
999
原创 MySQL之备份与恢复(六)
创建一个快照的消耗几乎微不足道，但还是需要确保系统配置可以让你获取在备份瞬间的所有需要的文件的一致性副本。首先，确保系统满足下面这些条件。LVM有卷组的概念，它包含一个或多个逻辑卷。输出显示了一个分布在一个物理卷上的卷组，它有四个逻辑卷，大概有250GB空间空闲。入股哦需要，可用vgdisplay命令产生更详细的输出。现在让我们看下系统上的逻辑卷。
2024-07-05 21:29:31
1027
原创 MySQL之备份与恢复(五)
可以使用SQL命令SELECT INTO OUTFILE以符号分隔文件格式创建数据的逻辑备份。(可以用mysqldump的 --tab选项导出到符号分隔文件中)。符号分隔文件包含以ASCII展示的原始数据，没有SQL、注释和列名。下面是一个导出为逗号分隔值(CVS)格式的例子。对于表个形式的数据来说这是一个很好的通用格式。导出时你可能会遇到报错，按照图中所示导入到mysql认为安全的目录下就行。比起SQL导出文件，符号分隔文件要更紧凑且更易于用命令行工具操作，这种方法最大的优点时备份和还原速度更快。
2024-07-05 09:17:23
746
原创 MySQL之备份与恢复(四)
从备库中备份最大的好处是可以不干扰主库，避免在主库上增加额外的负载。这是一个建立备库的好理由，即使不需要用它做负载均衡或高可用。如果钱是个问题，也可以把备份用的备库用于其他用户，例如报表服务——只要不对其做写操作，以确保备份不会修改数据。备库不必只用于备份的目的；只需要在下次备份时能及时跟上主库，即使有时因作为其他用途导致复制延时也没有关系。当从备库备份时，应该保存所有关于复制进程的信息，例如备库相对于主库的位置。
2024-07-04 23:02:04
938
原创 MySQL之备份与恢复(三)
物理备份通常更加简单高效(值得一提的是物理备份会更容易出错;很难相Mysqldump一样简单)尽管如此，对于需要长期保留的备份，或者是满足法律合规要求的备份，尽量不要完全依赖物理备份。至少每隔一段时间还是需要做一次逻辑备份。除非经过测试，不要假定备份(特别是物理备份)是正常的。对InnoDB来说，这意味着需要启动一个MySQL实例，执行InnoDB恢复操作，然后运行CHECK TABLES。也可以跳过这一操作，仅对文件运行innochecksum,但不建议这样做。
2024-07-04 21:44:33
1357
原创 MySQL之备份与恢复(二)
如果一切正常，那么永远也不需要考虑恢复。但是，一旦需要恢复，只有世界上最好的备份系统是没用的，还需要一个强大的恢复系统。不幸的是，让备份系统平滑工作比构造良好的恢复过程和工具更容易。这里有一个看到的真实例子:一个客户报告说当mysqldump加上-d选项后，备份变得像闪电一般快，他想知道为什么没有一个人提出该选项可以如此快地加速备份过程。如果这个客户已经尝试还原这些备份，就不难发现其原因:使用-d选项将不会备份数据!这个客户关注备份，却没有关注恢复，因此完全没有意识到这个问题。
2024-07-03 22:10:36
1385
4
原创 MySQL之应用层优化和备份与恢复(一)
如果没有提前做好备份规划，也许以后会发现已经错失了一些最佳得选择。例如，在服务器已经配置好了以后，才想起应该使用LVM,以便可以获取文件系统的快照——但这时已经太迟了。在为别分配置系统参数时，可能没有注意到某些系统配置对性能有着重要影响。如果没有计划做定期的恢复演练，当真的需要恢复时，就会发现并没有那么顺利。在此假设大部分用户主要使用InnoDB而不是MyISAM。也不会涵盖一个精心设计的备份和恢复解决方案的所有部分——而仅涉及与MySQL相关的部分。1.安全(访问备份，恢复数据的权限，文件是否需要加密)
2024-07-03 09:22:38
670
原创 MySQL之应用层优化(三)
可以缓存关于搜索的最小信息，而不必缓存整个列表，例如返回结果的数量以及列表中的产品ID。现在想象以下，一个产品地描述发生了变化，不再包含搜索中匹配地关键字，但是搜索结果地缓存还没有过期失效，此时用户就会看到错误地搜索结果，因为缓存的搜索结果将会引用这个变化了的产品，即使它不再包含匹配搜索的关键字。在前面的图书俱乐部的例子中，你可以通过下面的版本好标记评论，使缓存的评论依赖于用户的版本和书的版本:user_ver=1234和book_ver=5678.任一版本号变了，都应该刷新缓存的评论。
2024-07-02 22:11:36
961
原创 MySQL之应用层优化(二)
每个Web服务器都有一个最佳并发度——就是说，让进程处理请求尽可能快，并且不超过系统负载的最优的并发连接数。这就是前面说的最大系统容量。进行一个简单的测量和建模，或者只是反复试验，就可以找到这个"神奇的数"，为此花一些时间是值得的。对于大流量的网站，Web服务器同一时刻处理上千个连接是很常见的。然而，只有一小部分连接需要进程实时处理。其他的可能是读请求，处理文件上传，填鸭式服务内容，或者只是等待客户端的下一步请求。随者并发的增加，服务器会逐渐到达它的最大吞吐量。
2024-07-02 09:27:01
1137
原创 MySQL之高可用性和应用层优化(一)
如果在提高MySQL的性能上花费太多时间，容易使事业局限于MySQL本身，而忽略了用户体验。回过头来看，也许可以意识到，或许MySQL已经足够优化，对于用户看到的响应时间而言，其所占的比重已经非常之小，此时应该关注下其他部分了。这是个很不错的观点，尤其是对DBA而言，这是很值得去做的正确的事。但如果不是MySQL，那有时什么导致了问题？在前面的讨论中，可以通过测量可以快速而准确地给出答案。如果能顺着应用的逻辑过程从头到尾来剖析，那么找到问题的源头一般来说并不困难。
2024-07-01 22:36:28
1083
2
原创 MySQL之高可用性(四)
冗余是很好的技术，但实际上只有在遇到故障需要恢复时才会用到。(见鬼，这可以用备份来实现)。冗余一点儿也不会增加可用性或减少宕机。在故障转移的过程中，高可用性是建立在冗余的基础上。当有一个组件失效，但存在冗余时，可以停止使用发生故障的组件，而使用冗余备件。冗余和故障转移结合可以帮助更快地恢复，如你所知，MTTR(平均恢复时间)的减少将降低宕机时间并改善可用性。在继续这个话题之前，我们先来定义一些术语。我们统一使用"故障转移(failover)",有些人使用"回退(fallback)“来表达同一意思。
2024-07-01 09:30:36
729
原创 MySQL之高可用性(三)
当使用同步复制时，主库上的事务只有在至少一个备库上提交后才能认为其执行完成。这实现了两个目标:当服务器崩溃时没有提交的事务会丢失，并且至少有一个备库拥有实时的数据副本。大多数同步复制架构运行在主动——主动模式。这意味着每个服务器在任何时候都是故障转移的候选者，这使得通过冗余关于获得高可用性更加容易，早期版本的MySQL不支持同步复制(MySQL5.5支持半同步复制)，还有两个基于MySQL的集群解决方案支持同步复制。
2024-06-30 13:16:25
1161
原创 MySQL之高可用性(二)
找到并消除系统中的可能失效的单点，并结合切换到备用组件的机制，这是一种通过减少恢复时间(MTTR)来改善可用性的方法。如果你够聪明，有时候甚至能将实际的恢复时间降低至0，但总的来说这很困难。(即使一些非常引人注目的技术，例如昂贵的负载均衡器，在发现问题并进行反馈时也会导致一定的延迟)。思考并梳理整个应用，尝试去定位任何可能失效的单点。是一个硬盘驱动器，一台服务器，一台交换或路由器，还是某个机架的电源?所有数据都在一个数据中心，或者冗余数据中心是由同一个公司提供的吗？
2024-06-30 10:39:41
1042
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人