Knowledge Summary - SuperProjectGit/super-repository GitHub Wiki

JVM

Tomcat 8

tomcat8 user 配置

<role rolename="manager"/> 　 <role rolename="manager-gui"/>　 <role rolename="admin"/>　 <role rolename="admin-gui"/>　 <role rolename="manager-script"/> <user username="tomcat" password="tomcat" roles="admin-gui,admin,manager-gui,manager,manager-script"/>

其中admin-gui是为了能访问manger的界面，manager-script是为了可以上传war文件 做完了以上的步骤，可以用localhost:8080/manager,或者127.0.0.1:8080/manager要远程访问manager的页面，但是换为IP:8080/manager被拒绝了

配置远程访问manager： tomat_home/conf/Catalina/localhost/下 添加manager.xml

<Context privileged="true" antiResourceLocking="false" docBase="${catalina.home}/webapps/manager"> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="^.*$" /> </Context>

Docker

docker 配置

  • docker从1.13.1 (2017-02-08)之后命名发生变化，更改为17.09.0-ce (2017-09-26)
  • docker 配置registry http访问 { "insecure-registries" : ["myregistrydomain.com:5000"] }， 文件名称：daemon.json Linux:/etc/docker/daemon.json； windows:C:\ProgramData\docker\config\daemon.json
  • docker registry 可删除镜像配置

config.yml

storage: filesystem: rootdirectory: /var/lib/registry delete: enabled: false // 默认可删除为false

死锁

产生死锁的原因主要是：

  • （1） 因为系统资源不足。
  • （2） 进程运行推进的顺序不合适。
  • （3） 资源分配不当等。

如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则 就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。

产生死锁的四个必要条件：

  • （1） 互斥条件：一个资源每次只能被一个进程使用。
  • （2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
  • （3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
  • （4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之 一不满足，就不会发生死锁。

死锁的解除与预防：

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和 解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确 定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态 的情况下占用资源。因此，对资源的分配要给予合理的规划。

MySQL存在text和blob:

（1）相同

在TEXT或BLOB列的存储或检索过程中，不存在大小写转换,当未运行在严格模式时，如果你为BLOB或TEXT列分配一个超过该列类型的最大长度的值值，值被截取以保证适合。如果截掉的字符不是空格，将会产生一条警告。使用严格SQL模式，会产生错误，并且值将被拒绝而不是截取并给出警告.

BLOB和TEXT列不能有 默认值.

当保存或检索BLOB和TEXT列的值时不删除尾部空格。(这与VARBINARY和VARCHAR列相同）.

对于BLOB和TEXT列的索引，必须指定索引前缀的长度。对于CHAR和VARCHAR，前缀长度是可选的.

（2）相异

text :

  • TEXT值是大小写不敏感的
  • Text被视为非二进制字符串
  • TEXT列有一个字符集，并且根据字符集的 校对规则对值进行排序和比较
  • 可以将TEXT列视为VARCHAR列
  • MySQL连接程序/ODBC将TEXT值定义为LONGVARCHAR
  • BLOB 可以储存图片,TEXT不行，TEXT只能储存纯文本文件。4个TEXT类型TINYTEXT、TEXT、MEDIUMTEXT和LONGTEXT对应于4个BLOB类型，并且有同样的最大长度和存储需求。

blob:

  • BLOB值的排序和比较以大小写敏感方式执行;
  • BLOB被视为二进制字符串;
  • BLOB列没有字符集，并且排序和比较基于列值字节的数值值。
  • 在大多数方面，可以将BLOB列视为能够足够大的VARBINARY列
  • MySQL连接程序/ODBC将BLOB值定义为LONGVARBINARY
  • 一个BLOB是一个能保存可变数量的数据的二进制的大对象。4个BLOB类型TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB仅仅在他们能保存值的最大长度方面有所不同。

（3）其他：

VARCHAR，BLOB 和TEXT类型是变长类型，对于其存储需求取决于列值的实际长度(在前面的表格中用L表示)，而不是取决于类型的最大可能尺寸。例如，一个 VARCHAR(10)列能保存最大长度为10个字符的一个字符串，实际的存储需要是字符串的长度 ，加上1个字节以记录字符串的长度。对于字符串'abcd'，L是4而存储要求是5个字节。

BLOB和TEXT类型需要1，2，3或4个字节来记录列值的长度，这取决于类型的最大可能长度。VARCHAR需要定义大小，有255的最大限制；TEXT则不需要。如果你把一个超过列类型最大长度的值赋给一个BLOB或TEXT列，值被截断以适合它。

CHAR(n) 固定长度，最多 255 个字符

VARCHAR(n) 可变长度，MySQL 4.1 及以前最大 255 字符，MySQL 5 之后最大 65535 字节

TINYTEXT 可变长度，最多 255 个字符

TEXT 可变长度，最多 65535 个字符

MEDIUMTEXT 可变长度，最多 16777215（2^24 - 1）个字符

LONGTEXT 可变长度，最多 4294967295（2^32 - 1）（4G）个字符

Java byte[] toString not always possible

java中byte[] toString()并不是所有情况都适用，在使用的inputStream中的二进制流byte[]使用了toString()后，数据会不准确，会变得不可逆！

java普通类的加载顺序

静态代码按照顺序初始化 -> 父类构造函数 -> 变量初始化 -> 实例代码块 -> 自身构造函数

基于JVM（内存）的优化

2.1 32位操作系统与64位操作系统中JVM的对比

我们一般的开发人员，基本用的是都是32位的Windows系统，这就导致了一个严重的问题即：32位windows系统对内存限制，下面先来看一个比较的表格：

操作系统 操作系统位数 内存限制 解决办法

Winxp 32 4GB 超级兔子

Win7 32 4GB 可以通过设置/PAE

Win2003 32 可以突破4GB达16GB 必需要装win2003 advanced server且要打上sp2补丁

Win7 64 无限制 机器能插多少内存，系统内存就能支持到多大

Win2003 64 无限制 机器能插多少内存，系统内存就能支持到多大

Linux 64 无限制 机器能插多少内存，系统内存就能支持到多大

Unix 64 无限制 机器能插多少内存，系统内存就能支持到多大

上述问题解决后，我们又碰到一个新的问题，32位系统下JVM对内存的限制：不能突破2GB内存，即使你在Win2003 Advanced Server下你的机器装有8GB-16GB的内存，而你的JAVA，只能用到2GB的内存。

其实我一直很想推荐大家使用Linux或者是Mac操作系统的，而且要装64位，因为必竟我们是开发用的不是打游戏用的，而Java源自Unix归于Unix（Linux只是运行在PC上的Unix而己）。

所以很多开发人员运行在win32位系统上更有甚者在生产环境下都会布署win32位的系统，那么这时你的Tomcat要优化，就要讲究点技巧了。而在64位操作系统上无论是系统内存还是JVM都没有受到2GB这样的限制。

Tomcat的优化分成两块：

Tomcat启动命令行中的优化参数即JVM优化

Tomcat容器自身参数的优化（这块很像ApacheHttp Server）

这一节先要讲的是Tomcat启动命令行中的优化参数。

Tomcat首先跑在JVM之上的，因为它的启动其实也只是一个java命令行，首先我们需要对这个JAVA的启动命令行进行调优。

需要注意的是：

这边讨论的JVM优化是基于Oracle Sun的jdk1.6版有以上，其它JDK或者低版本JDK不适用。

2.2 Tomcat启动行参数的优化

Tomcat 的启动参数位于tomcat的安装目录in目录下，如果你是Linux操作系统就是catalina.sh文件，如果你是Windows操作系统那么你需要改动的就是catalina.bat文件。打开该文件，一般该文件头部是一堆的由##包裹着的注释文字，找到注释文字的最后一段如：

# $Id: catalina.sh 522797 2007-03-27 07:10:29Z fhanik $

# -----------------------------------------------------------------------------

# OS specific support. $var _must_ be set to either true or false.

敲入一个回车，加入如下的参数

Linux系统中tomcat的启动参数

1

export JAVA_OPTS="-server -Xms1400M -Xmx1400M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true "

Windows系统中tomcat的启动参数

1

set JAVA_OPTS=-server -Xms1400M -Xmx1400M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true

上面参数好多啊，可能有人写到现在都没见一个tomcat的启动命令里加了这么多参数，当然，这些参数只是我机器上的，不一定适合你，尤其是参数后的value（值）是需要根据你自己的实际情况来设置的。

参数解释：

  • -server

我不管你什么理由，只要你的tomcat是运行在生产环境中的，这个参数必须给我加上

因为tomcat默认是以一种叫java –client的模式来运行的，server即意味着你的tomcat是以真实的production的模式在运行的，这也就意味着你的tomcat以server模式运行时将拥有：更大、更高的并发处理能力，更快更强捷的JVM垃圾回收机制，可以获得更多的负载与吞吐量。。。更。。。还有更。。。

Y给我记住啊，要不然这个-server都不加，那是要打屁股了。

  • -Xms–Xmx

即JVM内存设置了，把Xms与Xmx两个值设成一样是最优的做法，有人说Xms为最小值，Xmx为最大值不是挺好的，这样设置还比较人性化，科学化。人性？科学？你个头啊。

大家想一下这样的场景：

一个系统随着并发数越来越高，它的内存使用情况逐步上升，上升到最高点不能上升了，开始回落，你们不要认为这个回落就是好事情，由其是大起大落，在内存回落时它付出的代价是CPU高速开始运转进行垃圾回收，此时严重的甚至会造成你的系统出现“卡壳”就是你在好好的操作，突然网页像死在那边一样几秒甚至十几秒时间，因为JVM正在进行垃圾回收。

因此一开始我们就把这两个设成一样，使得Tomcat在启动时就为最大化参数充分利用系统的效率，这个道理和jdbcconnection pool里的minpool size与maxpool size的需要设成一个数量是一样的原理。

如何知道我的JVM能够使用最大值啊？拍脑袋？不行！

在设这个最大内存即Xmx值时请先打开一个命令行，键入如下的命令：

看，能够正常显示JDK的版本信息，说明，这个值你能够用。不是说32位系统下最高能够使用2GB内存吗？即：2048m，我们不防来试试

可以吗？不可以！不要说2048m呢，我们小一点，试试1700m如何

嘿嘿，连1700m都不可以，更不要说2048m了呢，2048m只是一个理论数值，这样说吧我这边有几台机器，有的机器-Xmx1800都没问题，有的机器最高只能到-Xmx1500m。

因此在设这个-Xms与-Xmx值时一定一定记得先这样测试一下，要不然直接加在tomcat启动命令行中你的tomcat就再也起不来了，要飞是飞不了，直接成了一只瘟猫了。

  • –Xmn

设置年轻代大小为512m。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。

  • -Xss

是指设定每个线程的堆栈大小。这个就要依据你的程序，看一个线程 大约需要占用多少内存，可能会有多少线程同时运行等。一般不易设置超过1M，要不然容易出现out ofmemory。

  • -XX:+AggressiveOpts

作用如其名（aggressive），启用这个参数，则每当JDK版本升级时，你的JVM都会使用最新加入的优化技术（如果有的话）

  • -XX:+UseBiasedLocking

启用一个优化了的线程锁，我们知道在我们的appserver，每个http请求就是一个线程，有的请求短有的请求长，就会有请求排队的现象，甚至还会出现线程阻塞，这个优化了的线程锁使得你的appserver内对线程处理自动进行最优调配。

  • -XX:PermSize=128M-XX:MaxPermSize=256M

JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；

在数据量的很大的文件导出时，一定要把这两个值设置上，否则会出现内存溢出的错误。

由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。

那么，如果是物理内存4GB，那么64分之一就是64MB，这就是PermSize默认值，也就是永生代内存初始大小；

四分之一是1024MB，这就是MaxPermSize默认大小。

  • -XX:+DisableExplicitGC

在程序代码中不允许有显示的调用”System.gc()”。看到过有两个极品工程中每次在DAO操作结束时手动调用System.gc()一下，觉得这样做好像能够解决它们的out ofmemory问题一样，付出的代价就是系统响应时间严重降低，就和我在关于Xms,Xmx里的解释的原理一样，这样去调用GC导致系统的JVM大起大落，性能不到什么地方去哟！

  • -XX:+UseParNewGC

对年轻代采用多线程并行回收，这样收得快。

  • -XX:+UseConcMarkSweepGC

即CMS gc，这一特性只有jdk1.5即后续版本才具有的功能，它使用的是gc估算触发和heap占用触发。

我们知道频频繁的GC会造面JVM的大起大落从而影响到系统的效率，因此使用了CMS GC后可以在GC次数增多的情况下，每次GC的响应时间却很短，比如说使用了CMS GC后经过jprofiler的观察，GC被触发次数非常多，而每次GC耗时仅为几毫秒。

  • -XX:MaxTenuringThreshold

设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。

这个值的设置是根据本地的jprofiler监控后得到的一个理想的值，不能一概而论原搬照抄。

  • -XX:+CMSParallelRemarkEnabled

在使用UseParNewGC 的情况下, 尽量减少 mark 的时间

  • -XX:+UseCMSCompactAtFullCollection

在使用concurrent gc 的情况下, 防止 memoryfragmention, 对live object 进行整理, 使 memory 碎片减少。

  • -XX:LargePageSizeInBytes

指定 Java heap的分页页面大小

  • -XX:+UseFastAccessorMethods

get,set 方法转成本地代码

  • -XX:+UseCMSInitiatingOccupancyOnly

指示只有在 oldgeneration 在使用了初始化的比例后concurrent collector 启动收集

  • -XX:CMSInitiatingOccupancyFraction=70

CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)(100- CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotion failed。在我的应用中Xmx是6000，Xmn是512，那么Xmx-Xmn是5488兆，也就是年老代有5488 兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还 剩10%的空间是548810%=548兆，所以即使Xmn（也就是年轻代共512兆）里所有对象都搬到年老代里，548兆的空间也足够了，所以只要满 足上面的公式，就不会出现垃圾回收时的promotion failed；

因此这个参数的设置必须与Xmn关联在一起。

  • -Djava.awt.headless=true

这个参数一般我们都是放在最后使用的，这全参数的作用是这样的，有时我们会在我们的J2EE工程中使用一些图表工具如：jfreechart，用于在web网页输出GIF/JPG等流，在winodws环境下，一般我们的app server在输出图形时不会碰到什么问题，但是在linux/unix环境下经常会碰到一个exception导致你在winodws开发环境下图片显示的好好可是在linux/unix下却显示不出来，因此加上这个参数以免避这样的情况出现。

上述这样的配置，基本上可以达到：

系统响应时间增快

JVM回收速度增快同时又不影响系统的响应率

JVM内存最大化利用

线程阻塞情况最小化

2.3 Tomcat容器内的优化

前面我们对Tomcat启动时的命令进行了优化，增加了系统的JVM可使用数、垃圾回收效率与线程阻塞情况、增加了系统响应效率等还有一个很重要的指标，我们没有去做优化，就是吞吐量。

还记得我们在第三天的学习中说的，这个系统本身可以处理1000，你没有优化和配置导致它默认只能处理25。因此下面我们来看Tomcat容器内的优化。

打开tomcat安装目录confserver.xml文件，定位到这一行：

<Connector port=”8080″ protocol=”HTTP/1.1″

这一行就是我们的tomcat容器性能参数设置的地方，它一般都会有一个默认值，这些默认值是远远不够我们的使用的，我们来看经过更改后的这一段的配置：

<Connector port="8080" protocol="HTTP/1.1"

URIEncoding="UTF-8" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"

acceptCount="300" maxThreads="300" maxProcessors="1000" minProcessors="5"

useURIValidationHack="false"

compression="on" compressionMinSize="2048"

compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

redirectPort="8443"

/>

好大一陀唉。

没关系，一个个来解释

  • URIEncoding=”UTF-8”

使得tomcat可以解析含有中文名的文件的url，真方便，不像apache里还有搞个mod_encoding，还要手工编译

  • maxSpareThreads

maxSpareThreads 的意思就是如果空闲状态的线程数多于设置的数目，则将这些线程中止，减少这个池中的线程总数。

  • minSpareThreads

最小备用线程数，tomcat启动时的初始化的线程数。

  • enableLookups

这个功效和Apache中的HostnameLookups一样，设为关闭。

  • connectionTimeout

connectionTimeout为网络连接超时时间毫秒数。

  • maxThreads

maxThreads Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数，即最大并发数。

  • acceptCount

acceptCount是当线程数达到maxThreads后，后续请求会被放入一个等待队列，这个acceptCount是这个队列的大小，如果这个队列也满了，就直接refuse connection

  • maxProcessors与minProcessors

在 Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最 大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。

通常Windows是1000个左右，Linux是2000个左右。

useURIValidationHack

我们来看一下tomcat中的一段源码：

security

if (connector.getUseURIValidationHack()) {

String uri = validate(request.getRequestURI());

if (uri == null) {

res.setStatus(400);

res.setMessage("Invalid URI");

throw new IOException("Invalid URI");

} else {

req.requestURI().setString(uri);

// Redoing the URI decoding

req.decodedURI().duplicate(req.requestURI());

req.getURLDecoder().convert(req.decodedURI(), true);

}

}

可以看到如果把useURIValidationHack设成”false”，可以减少它对一些url的不必要的检查从而减省开销。

  • enableLookups=”false”

为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml文件中的enableLookups参数值。

  • disableUploadTimeout

类似于Apache中的keeyalive一样

  • 给Tomcat配置gzip压缩(HTTP压缩)功能

compression="on" compressionMinSize="2048"

compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

HTTP 压缩可以大大提高浏览网站的速度，它的原理是，在客户端请求网页后，从服务器端将网页文件压缩，再下载到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程HTML,CSS,Javascript , Text ，它可以节省40%左右的流量。更为重要的是，它可以对动态生成的，包括CGI、PHP , JSP , ASP , Servlet,SHTML等输出的网页也能进行压缩，压缩效率惊人。

1)compression=”on” 打开压缩功能

2)compressionMinSize=”2048″ 启用压缩的输出内容大小，这里面默认为2KB

3)noCompressionUserAgents=”gozilla, traviata” 对于以下的浏览器，不启用压缩

4)compressableMimeType=”text/html,text/xml”　压缩类型

最后不要忘了把8443端口的地方也加上同样的配置，因为如果我们走https协议的话，我们将会用到8443端口这个段的配置，对吧？

<Connector port="8443" protocol="HTTP/1.1"

URIEncoding="UTF-8" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"

acceptCount="300" maxThreads="300" maxProcessors="1000" minProcessors="5"

useURIValidationHack="false"

compression="on" compressionMinSize="2048"

compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

SSLEnabled="true"

scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="d:/tomcat2/conf/shnlap93.jks" keystorePass="aaaaaa"

/>

举个真实的例子：上一个项目，经过4轮performance testing，第一轮进行了问题的定位，第二轮就是进行了apache+tomcat/weblogic的优化，第三轮是做集群优化，第四轮是sql与codes的优化。好了，所有的Tomcat优化的地方都加上了。结合第三天中的Apache的性能优化，我们这个架构可以“飞奔”起来了，当然这边把有提及任何关于数据库优化的步骤，但仅凭这两步，我们的系统已经有了很大的提升。

在到达第二轮时，我们的性能已经提升了多少倍呢？我们来看一个loaderrunner的截图吧：

左边第一列是第一轮没有经过任何调优的压力测试报告。

右边这一列是经过了apache优化，tomcat优化后得到的压力测试报告。

大家看看，这就提高了多少倍？这还只是在没有改动代码的情况下得到的改善，现在明白了好好的调优一

个apache和tomcat其实是多么的重要了？如果加上后面的代码、SQL的调优、数据库的调优。。。。。。所以我在上一个工程中有单笔交易性能（无论是吞吐量、响应时间）提高了80倍这样的极端例子的存在。

tomcat解析http协议

连接器负责接收请求,处理器负责解析请求,每个处理器拥有自己的Request和Response对象,这两个对象可以重复使用

处理器处理流程

  • 解析连接信息:设置Internet地址和代理信息
  • 解析请求行:请求方法,URI,协议版本，查询参数(如果有),keep-alive属性,session ID(如果禁用了cookie),标准化URI地址
  • 解析请求头:将请求头设置到对应的属性中,其中有几个重要的属性,cookie,content-length和content-type(在处理正文时会用到),conection(主要检查是否close值)
  • 解析参数:先解析URI中的查询参数,再解析正文中的参数
  • 调用容器的invoke方法

Mysql对插入问题的描述

INSERT sets an exclusive lock on the inserted row. This lock is an index-record lock, not a next-key lock (that is, there is no gap lock) and does not prevent other sessions from inserting into the gap before the inserted row.Prior to inserting the row, a type of gap lock called an insertion intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.If a duplicate-key error occurs, a shared lock on the duplicate index record is set. This use of a shared lock can result in deadlock should there be multiple sessions trying to insert the same row if another session already has an exclusive lock.  

大体的意思是：insert会对插入成功的行加上排它锁，这个排它锁是个记录锁，而非next-key锁（当然更不是gap锁了），不会阻止其他并发的事务往这条记录之前插入记录。在插入之前，会先在插入记录所在的间隙加上一个插入意向gap锁（简称I锁吧），并发的事务可以对同一个gap加I锁。如果insert 的事务出现了duplicate-key error ，事务会对duplicate index record加共享锁。这个共享锁在并发的情况下是会产生死锁的，比如有两个并发的insert都对要对同一条记录加共享锁，而此时这条记录又被其他事务加上了排它锁，排它锁的事务提交或者回滚后，两个并发的insert操作是会发生死锁的。

Linux 系统 CPU 100% 异常排查实践与总结

1、top oder by with P：1040 // 首先按进程负载排序找到 maxLoad(pid)

2、top -Hp 进程PID：1073 // 找到相关负载 线程PID

3、printf “0x%x ”线程PID： 0x431 // 将线程PID转换为 16进制，为后面查找 jstack 日志做准备

4、jstack 进程PID | vim +/十六进制线程PID - // 例如：jstack 1040|vim +/0x431 -

消息顺序性

1.要“有序”，先得有衡量“有序”的标尺，可以是客户端标尺，可以是服务端标尺；

2.大部分业务能够接受大范围趋势有序，小范围误差；绝对有序的业务，可以借助服务器绝对时序的能力；

3.单点序列化，是一种常见的保证多机时序统一的方法，典型场景有db主从一致，gfs多文件一致；

4.单对单聊天，只需保证发出的时序与接收的时序一致，可以利用客户端seq；

5.群聊，只需保证所有接收方消息时序一致，需要利用服务端seq，方法有两种，一种单点绝对时序，另一种id串行化；

Reference

left join on and 与 left join on where的区别

数据库在通过连接两张或多张表来返回记录时，都会生成一张中间的临时表，然后再将这张临时表返回给用户。

在使用left jion时，on和where条件的区别如下：

  1. on条件是在生成临时表时使用的条件，它不管on中的条件是否为真，都会返回左边表中的记录。

  2. where条件是在临时表生成好后，再对临时表进行过滤的条件。这时已经没有left join的含义（必须返回左边表的记录）了，条件不为真的就全部过滤掉。

spring boot MultipartResolver为空问题

  1. spring mvc使用的是CommonsMultipartResolver，spring boot默认使用的是StandardServletMultipartResolver

如果从spring mvc切换到spring boot，上传文件使用的是相对路径，StandardServletMultipartResolver会将文件生成一个文件夹，造成在数据转换的时候获取不到上传文件。以下为StandardServletMultipartResolver写文件时的判断。 `public void write(String fileName) throws IOException { File file = new File(fileName); if (!file.isAbsolute()) { file = new File(this.location, fileName); }

try {
  this.fileItem.write(file);
} catch (Exception var4) {
  throw new IOException(var4);
}

}`

如果需要继续使用默认的方式，则在配置文件中定义location，并且修改之前的上传方法，改动会比较大。建议继续使用CommonsMultipartResolver，添加CommonsMultipartResolver，同时将默认的multipart的enabled设置为false（如果两个同时开启，则默认的multipart会优先消费掉文件流，导致在CommonsMultipartResolver无法获取到文件）

@Bean public MultipartResolver getMultipartResolver() { CommonsMultipartResolver commonsMultipartResolver = new CommonsMultipartResolver(); commonsMultipartResolver.setResolveLazily(true); commonsMultipartResolver.setDefaultEncoding("UTF-8"); commonsMultipartResolver.setMaxInMemorySize(52428800); commonsMultipartResolver.setMaxUploadSize(52428800); return commonsMultipartResolver; }

分布式锁

1.首先保证在分布式的环境中，同一个方法只能被同一个服务器上的一个线程执行。

2.锁要可重入，严重一点的场景不能获取锁之后如果需要再次获取时发现不能获取了，造成死锁。

3.锁要可阻塞。这一般只要保证有个超时时间就行。

4.高可用的加锁和释放锁功能。

5.加锁和释放锁的性能要好。

三种实现方式

  • 基于数据库的实现方式 公共表
  • redis锁 setnx
  • zookeeper实现

REF

监控Monitor

tomcat架构

java内存模型

开发者工具

Intellij Idea插件

微信后台架构及基础设施设计与实践

沟通技巧

Apache Flink

linux入侵记录

JVM

深度学习

连接池

区块链

flink有赞

flink tencent

流系统一致性对比

神经网络与深度学习

业务与技术

分库分表

JVM优化

技术中台

正则表达式

程序编译与代码优化

kafka

G1 GC日志

open source

projectreactor

常见的hash算法及其原理

jdk-1.8-ForkJoinPool实现原理

volatile和Cache一致性协议之MESI

GraalVM

分布式事务

常用的 Chrome 扩展（部分需翻墙）

JavaScript 执行机制

马蜂窝大交通监控

JUC

ali middleware

BFS&DFS

动态规划

hash算法

算法pdf(英文)

玉伯：成长之路

工作方法论

flink入门到进阶

Elasticsearch 索引设计

linux文件删除后，空间未释放

分布式存储 Ceph

openstack ceph

支付业务

java即时编译

低代码

⚠️ **GitHub.com Fallback** ⚠️