coffee_babe-CSDN博客

原创【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 66

原创【JVM】亿级流量调优(一)

前面的klass模型，它是Java类的元信息在JVM中的存在形式。这个oop模型是Java对象在JVM中的存在形式。

2024-08-25 10:06:52 106

原创【JVM】剖析字符串与数组的底层实现(二)

jdk8:底层是一个char[]数组jdk9及之后:底层是一个byte[]数组一个中文占两个字节，一个char占两个字节，一个byte占一个字节Jdk9及之后的版本中，多了一个code属性，这个属性标记是告诉调用者按几个字节来取的问题，如果按byte存储的话，存不是什么问题，问题是如何取呢？

2024-08-23 11:53:35 708

原创【JVM】剖析字符串与数组的底层实现(一)

这里要明确一点的是，在Jdk6以及以前的版本中，字符串的常量池是放在堆的Perm区的，Perm区是一个类静态的区域，主要存储一些加载类的信息，常量池，方法片段等内容，默认大小只有4m，一旦常量池中大量使用intern是会直接产生java.lang.OutOfMemoryError:PermGen Space错误的。JDK1.6及之前:有永久代，运行时常量池在永久代，运行时常量池包含字符串常量池，Perm区域只有4m,一旦常量池大量使用intern很容易发生永久代的OOM。为什么输出会有这些变化呢？

2024-08-23 11:40:38 885

原创【JVM】JVM内存模型与操作系统内存模型(二)

与虚拟机栈发挥的作用是相似的，他们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的Native方法服务。在虚拟机规范中对本地方法栈中使用、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机比如(SUn HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryErr异常。

2024-08-22 10:51:00 864

原创【JVM】JVM内存模型与操作系统内存模型(一)

可以这样理解:JVM内存模型其实就是JVM在启动的时候从操作系统内存中要了一块大内存，然后将这个大内存分成五个区域:方法区、堆区、虚拟机栈、本地方法栈、本地方法栈、程序计数器.其实叫JVM运行时区域更合适。但是要区分JVM内存模型与JMM(Java Memory Model)InstanceKlass:类的元信息(方法区)InstanceMirrorKlass:镜像类Class对象(堆区)四个名词:class文件:即硬盘上的.class文件。

2024-08-22 10:45:13 1293

原创【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 1027 1

原创【JVM】JVM解析字节码文件过程(一)

大端模式:高位存在低地址，低位存高地址小段模式：与大端模式相反。

2024-08-21 10:54:57 327

原创【JVM】类加载器、双亲委派、SPI(二)

元空间内部给各个类加载器划分了内存区域。另外还需要注意一点的是，方法区会有碎片化问题，方法区的垃圾回收通常被称为类的卸载。方法区回收之后是没有整理的。

2024-08-20 08:22:14 986

原创【JVM】类加载器、双亲委派、SPI(一)

实现方式，需要继承java.lang.ClassLoader类,通过源码查看我们也得知了ClassLoader在loadClass的时候不会立马触发解析阶段，因为源码里面就写死了是false.懒汉模式，你可能听过loadClass()和findClass()方法，两者的职责是不一样的loadClass方法与findClass方法分析:1.loadClass方法是ClassLoader类中最常用的方法之一，它负责加载指定的类。它的主要特点是:1.1 它是一个public方法，可以被外部类调用。

2024-08-20 08:17:42 850

原创【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 796

原创【JVM】深入理解类加载机制(一)

Java的每个类，在JVM中都有一个对应的Klass类实例与之对应，存储类的元信息如:常量池、属性信息、方法信息…从继承关系上也能看出来，类的元信息是存储在元空间的。总结:非数组:InstanceKlass -> 普通的类在JVM中对应的C++类方法区InstanceMirrorKlass -> 对应的是Class对象镜像类堆区数组:基本类型数组引用类型数组: ObjArrayKlass为什么还要有镜像类？是为了安全，由JVM控制可以将哪些参数返回给用户。

2024-08-19 08:54:57 913

原创【JVM】跟我一起来编译OpenJDK

作为一名Javer，应该不少人都想编译一下OpenJDK然后在项目中用上它，自己还可以在OpenJDK中加入自己的东西，而不用受限于Oracle官网上的JDK,市面上还有很多技术也是运行在JVM之上的，这更加说明了研究JVM的重要性，比如Kotlin、Groovy、JRuby、Jython、Scala等等，接下来让我们一起探索JVM吧~

2024-07-16 22:08:22 942

原创【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 927

原创 MySQL之MySQL用户工具(二)

以过往的经验来看，大多数MySQL商店需要提供两种类型的监测工具:健康监测工具——检测到异常时告警——和为趋势、诊断、问题排查、容量规划等记录指标的工具。大多数系统仅在这些任务中的一个方面做得很好，而不能两者兼顾。更不幸的是，有十几种工具可选，使得评估和选择一款适合的工具非常耗时。许多监控系统不是专门为MySQL服务器设计。它们是通用系统，用于周期性地检测许多类型的资源，从及其到路由再到软件(例如MySQL)。它们一般有某些类型的插件架构，经常会伴随有一些MySQL插件

2024-07-08 21:33:47 733

原创 MySQL之备份与恢复和MySQL用户工具(一)

MySQL服务器发行包中并没有包含针对许多常用任务的工具，例如监控服务器或比较不同服务器间数据的工具。幸运的是，Oracle的商业版提供了一些扩展工具，并且MySQL活跃的开源社区和第三方公司也提供了一系列的工具，降低了自己"重复发明轮子"的需要。

2024-07-08 08:54:14 1065

原创 MySQL之备份与恢复(十)

有各种各样的好的和不是那么好的备份工具。我们喜欢对LVM使用mylvmbackup做快照备份，使用Percona Xtrabackup(开源)或MySQL Enterprise Backup(收费)做InnoDB热备份。不建议对大数据量使用mysqldump,因为它对服务器有影响，并且漫长的还原时间不可预知。有一些备份工具已经出现多年了，不幸的是有些已经过时。最明显的例子是Maatkkit的mk-parallel-dump。它从没有正确运行，甚至被重新设计过好几次还是不行。

2024-07-07 12:29:28 1121

原创 MySQL之备份与恢复(九)

复制和基于时间点的恢复使用的是相同的技术:服务器的二进制日志。这意味着复制在恢复时会是个非常有帮助的工具，哪怕方式不是很明显。下面将演示一些可以用到的方法。这里列出来的不是一个完整的列表，但应该可以为你根据需求设计恢复方案带来一些想法。记得编写脚本，并且对恢复过程中需要用到的所有技术进行预演。shijian只有没有任何多表的UPDATE、DELETE或INSERT语句操作这个表时，上述流程才是可行的。

2024-07-07 10:31:03 1021

原创 MySQL之备份与恢复(八)

如果还原的是逻辑备份而不是物理备份，则与使用操作系统简单地复制文件到适当位置的方式不同，需要使用MySQL服务器本身来加载数据到表中。在加载导出文件之前，应该先花一点时间考虑文件有多大，需要多久加载完，以及在启动之前还需要做什么事情，例如通知用户或禁用掉部分应用。禁掉二进制日志也是个好主意，除非需要将还原操作复制到备库:服务器加载一个巨大的导出文件的代价很高，并且写二进制日志会增加更多的(可能没有必要的)开销。加载巨大的文件对于一些存储引擎也有影响。

2024-07-06 12:01:07 1045

原创 MySQL之备份与恢复(七)

LVM快照备份也是有开销的。服务器写到原始卷的越多，引发的额外开销也越多。当服务器随机修改许多不同块时，磁头需要需要自写时复制空间来来回回寻址，并且将数据的老版本写到写时复制空间。从快照中读取也有开销，因为LVM需要从原始卷中读取大部分数据。只有快照创建后修改过的数据从写时复制空间读取；因此，逻辑顺序读取快照数据实际上也可能导致磁头来回移动。所以应该为此规划好快照。快照实际上会导致原始卷和快照都比正常的读/写性能要差——如果使用过多的写时复制空间，性能可能会差很多。

2024-07-06 09:36:13 975

原创 MySQL之备份与恢复(六)

创建一个快照的消耗几乎微不足道，但还是需要确保系统配置可以让你获取在备份瞬间的所有需要的文件的一致性副本。首先，确保系统满足下面这些条件。LVM有卷组的概念，它包含一个或多个逻辑卷。输出显示了一个分布在一个物理卷上的卷组，它有四个逻辑卷，大概有250GB空间空闲。入股哦需要，可用vgdisplay命令产生更详细的输出。现在让我们看下系统上的逻辑卷。

2024-07-05 21:29:31 1006

原创 MySQL之备份与恢复(五)

可以使用SQL命令SELECT INTO OUTFILE以符号分隔文件格式创建数据的逻辑备份。(可以用mysqldump的 --tab选项导出到符号分隔文件中)。符号分隔文件包含以ASCII展示的原始数据，没有SQL、注释和列名。下面是一个导出为逗号分隔值(CVS)格式的例子。对于表个形式的数据来说这是一个很好的通用格式。导出时你可能会遇到报错，按照图中所示导入到mysql认为安全的目录下就行。比起SQL导出文件，符号分隔文件要更紧凑且更易于用命令行工具操作，这种方法最大的优点时备份和还原速度更快。

2024-07-05 09:17:23 728

原创 MySQL之备份与恢复(四)

从备库中备份最大的好处是可以不干扰主库，避免在主库上增加额外的负载。这是一个建立备库的好理由，即使不需要用它做负载均衡或高可用。如果钱是个问题，也可以把备份用的备库用于其他用户，例如报表服务——只要不对其做写操作，以确保备份不会修改数据。备库不必只用于备份的目的；只需要在下次备份时能及时跟上主库，即使有时因作为其他用途导致复制延时也没有关系。当从备库备份时，应该保存所有关于复制进程的信息，例如备库相对于主库的位置。

2024-07-04 23:02:04 913

原创 MySQL之备份与恢复(三)

物理备份通常更加简单高效(值得一提的是物理备份会更容易出错;很难相Mysqldump一样简单)尽管如此，对于需要长期保留的备份，或者是满足法律合规要求的备份，尽量不要完全依赖物理备份。至少每隔一段时间还是需要做一次逻辑备份。除非经过测试，不要假定备份(特别是物理备份)是正常的。对InnoDB来说，这意味着需要启动一个MySQL实例，执行InnoDB恢复操作，然后运行CHECK TABLES。也可以跳过这一操作，仅对文件运行innochecksum,但不建议这样做。

2024-07-04 21:44:33 1324

原创 MySQL之备份与恢复(二)

如果一切正常，那么永远也不需要考虑恢复。但是，一旦需要恢复，只有世界上最好的备份系统是没用的，还需要一个强大的恢复系统。不幸的是，让备份系统平滑工作比构造良好的恢复过程和工具更容易。这里有一个看到的真实例子:一个客户报告说当mysqldump加上-d选项后，备份变得像闪电一般快，他想知道为什么没有一个人提出该选项可以如此快地加速备份过程。如果这个客户已经尝试还原这些备份，就不难发现其原因:使用-d选项将不会备份数据!这个客户关注备份，却没有关注恢复，因此完全没有意识到这个问题。

2024-07-03 22:10:36 1311 4

原创 MySQL之应用层优化和备份与恢复(一)

如果没有提前做好备份规划，也许以后会发现已经错失了一些最佳得选择。例如，在服务器已经配置好了以后，才想起应该使用LVM,以便可以获取文件系统的快照——但这时已经太迟了。在为别分配置系统参数时，可能没有注意到某些系统配置对性能有着重要影响。如果没有计划做定期的恢复演练，当真的需要恢复时，就会发现并没有那么顺利。在此假设大部分用户主要使用InnoDB而不是MyISAM。也不会涵盖一个精心设计的备份和恢复解决方案的所有部分——而仅涉及与MySQL相关的部分。1.安全(访问备份，恢复数据的权限，文件是否需要加密)

2024-07-03 09:22:38 637

原创 MySQL之应用层优化(三)

可以缓存关于搜索的最小信息，而不必缓存整个列表，例如返回结果的数量以及列表中的产品ID。现在想象以下，一个产品地描述发生了变化，不再包含搜索中匹配地关键字，但是搜索结果地缓存还没有过期失效，此时用户就会看到错误地搜索结果，因为缓存的搜索结果将会引用这个变化了的产品，即使它不再包含匹配搜索的关键字。在前面的图书俱乐部的例子中，你可以通过下面的版本好标记评论，使缓存的评论依赖于用户的版本和书的版本:user_ver=1234和book_ver=5678.任一版本号变了，都应该刷新缓存的评论。

2024-07-02 22:11:36 944

原创 MySQL之应用层优化(二)

每个Web服务器都有一个最佳并发度——就是说，让进程处理请求尽可能快，并且不超过系统负载的最优的并发连接数。这就是前面说的最大系统容量。进行一个简单的测量和建模，或者只是反复试验，就可以找到这个"神奇的数"，为此花一些时间是值得的。对于大流量的网站，Web服务器同一时刻处理上千个连接是很常见的。然而，只有一小部分连接需要进程实时处理。其他的可能是读请求，处理文件上传，填鸭式服务内容，或者只是等待客户端的下一步请求。随者并发的增加，服务器会逐渐到达它的最大吞吐量。

2024-07-02 09:27:01 1115

原创 MySQL之高可用性和应用层优化(一)

如果在提高MySQL的性能上花费太多时间，容易使事业局限于MySQL本身，而忽略了用户体验。回过头来看，也许可以意识到，或许MySQL已经足够优化，对于用户看到的响应时间而言，其所占的比重已经非常之小，此时应该关注下其他部分了。这是个很不错的观点，尤其是对DBA而言，这是很值得去做的正确的事。但如果不是MySQL，那有时什么导致了问题？在前面的讨论中，可以通过测量可以快速而准确地给出答案。如果能顺着应用的逻辑过程从头到尾来剖析，那么找到问题的源头一般来说并不困难。

2024-07-01 22:36:28 1061 2

原创 MySQL之高可用性(四)

冗余是很好的技术，但实际上只有在遇到故障需要恢复时才会用到。(见鬼，这可以用备份来实现)。冗余一点儿也不会增加可用性或减少宕机。在故障转移的过程中，高可用性是建立在冗余的基础上。当有一个组件失效，但存在冗余时，可以停止使用发生故障的组件，而使用冗余备件。冗余和故障转移结合可以帮助更快地恢复，如你所知，MTTR(平均恢复时间)的减少将降低宕机时间并改善可用性。在继续这个话题之前，我们先来定义一些术语。我们统一使用"故障转移(failover)",有些人使用"回退(fallback)“来表达同一意思。

2024-07-01 09:30:36 715

空空如也

空空如也