PSS

概述 Spring JDBC抽象框架core包提供了JDBC模板类，其中JdbcTemplate是core包的核心类，所以其他模板类都是基于它封装完成的，JDBC模板类是第一种工作模式。 JdbcTemplate类通过模板设计模式帮助我们消除了冗长的代码，只做需要做的事情（即可变部分），并且帮我们做哪些固定部分，如连接的创建及关闭。 JdbcTemplate类对可变部分采用回调接口方式实现，如ConnectionCallback通过回调接口返回给用户一个连接，从而可以使用该连接做任何事情、StatementCallback通过回调接口返回给用户一个Statement，从而可以使用该Statement做任何事情等等，还有其他一些回调接口 Spring除了提供JdbcTemplate核心类，还提供了基于JdbcTemplate实现的NamedParameterJdbcTemplate类用于支持命名参数绑定、 SimpleJdbcTemplate类用于支持Java5+的可变参数及自动装箱拆箱等特性。 JdbcTemplate类支持的回调类： 预编译语句及存储过程创建回调：用于根据JdbcTemplate提供的连接创建相应的语句； PreparedStatementCreator：通过回调获取JdbcTemplate提供的Connection

文件功能 编辑 ├— WINDOWS │ ├— system32 （存放Windows的系统文件和硬件 驱动程序 ） │ │ ├—config（用户配置信息和密码信息） │ │ │ └—systemprofile（ 系统配置信息 ，用于恢复系统） │ │ ├—drivers（用来存放硬件驱动文件，不建议删除） │ │ ├—spool（用来存放系统打印文件。包括打印的色彩、打印预存等） │ │ ├—wbem（存放WMI 测试程序 ，用于查看和更改公共信息模型类、实例和方法等。请勿删除） │ │ ├—IME（用来存放系统输入法文件，类似WINDOWS下的IME文件夹） │ │ ├—CatRoot（计算机启动测试信息目录，包括了计算机启动时检测的硬软件信息） │ │ ├—Com（用来存放 组件服务 文件） │ │ ├—ReinstallBackups（电脑中硬件的 驱动程序 备份） │ │ ├—DllCache（用来存放 系统缓存 文件。当系统文件被替换时，文件保护机制会复制这个文件夹下的文件去覆盖非系统文件） │ │ ├—GroupPolicy（ 组策略 文件夹） │ │ │ ├—system（ 系统文件夹 ，用来存放系统虚拟设备文件） │ ├—$NtUninstall$（每给系统打一个补丁，系统就会自动创建这样的一个目录，可删除） │ ├—security（系统安全文件夹

闩锁 翻译自： https://mssqlwiki.com/2012/09/07/latch-timeout-and-sql-server-latch/ 在一个多线程的进程里，当一个线程在内存里更新一个数据或索引页，而另一个线程正在读取相同的页，将会发生什么？ 当第一个线程在内存里读取一个数据或索引页，而第二个线程正在从内存里释放相同的页，将会发生什么？ 答案是：我们将获得数据或数据结构不一致的结果。为了避免不一致，SQL Server使用同步机制像锁（Locks）、闩锁（Latches）和自旋锁（Spinlocks）。 在这篇博文里，我们将讨论关于闩锁的一些关键点和如何排除闩锁超时dump故障。 什么是闩锁（Latch）？ 它们通过多线程控制对数据页和结构的并发访问。闩锁提供数据页的物理数据一致性，并提供数据结果的同步。闩锁不可以像锁一样被用户控制。 闩锁的类型： Buffer(BUF) Latch 用于同步访问BUF结构和它们相关的数据库页。 Buffer "IO" Latch Buffer Latch的一个子集，用于当BUF和相关的数据/索引页正在一个IO操作（从磁盘读取页或者写入页到磁盘）中间时。 Non-Buffer(Non-BUF) Latch 这些闩锁被用于同步一般的内存中数据结构，这些结构通常被并行线程、自动增长操作和收缩操作等查询/任务执行所使用。 闩锁模式：

在 Linux 中， 命令 能做任何事，所以使用相关 命令 吧。在这篇教程中，我们将会给你展示 8 个有用的命令来即查看在 Linux 系统中内存的使用情况，包括 RAM 和交换分区。 Linux 并不像 Windows，你经常不会有图形界面可供使用，特别是在服务器环境中。 作为一名 Linux 管理员，知道如何获取当前可用的和已经使用的资源情况，比如内存、CPU、磁盘等，是相当重要的。如果某一应用在你的系统上占用了太多的资源，导致你的系统无法达到最优状态，那么你需要找到并修正它。 如果你想找到消耗内存前十名的进程，你需要去阅读这篇文章：如何在 Linux 中找出内存消耗最大的进程。 在 Linux 中，命令能做任何事，所以使用相关命令吧。在这篇教程中，我们将会给你展示 8 个有用的命令来即查看在 Linux 系统中内存的使用情况，包括 RAM 和交换分区。 创建交换分区在 Linux 系统中是非常重要的，如果你想了解如何创建，可以去阅读这篇文章：在 Linux 系统上创建交换分区。 下面的命令可以帮助你以不同的方式查看 Linux 内存使用情况。 free 命令 /proc/meminfo 文件 vmstat 命令 ps_mem 命令 smem 命令 top 命令 htop 命令 glances 命令 1）如何使用 free 命令查看 Linux 内存使用情况 free 命令

找到关键点 在看到12452个等待在CachedBnsClient.run的业务的一瞬间笔者就意识到，肯定是这边的线程导致对外内存泄露了。下面就是根据线程大小计算其泄露内存量是不是确实能够引起OOM了。 发现内存计算对不上 由于我们这边设置的Xss是512K，即一个线程栈大小是512K，而由于线程共享其它MM单元(线程本地内存是是现在线程栈上的)，所以实际线程堆外内存占用数量也是512K。进行如下计算: 12563 * 512K = 6331M = 6.3G 整个环境一共4G，加上JVM堆内存1.8G(1792M)，已经明显的超过了4G。 (6.3G + 1.8G)=8.1G > 4G 如果按照此计算，应用应用早就被OOM了。 怎么回事呢？ 为了解决这个问题，笔者又思考了好久。如下所示: Java线程底层实现 JVM的线程在linux上底层是调用NPTL(Native Posix Thread Library)来创建的，一个JVM线程就对应linux的lwp(轻量级进程，也是进程，只不过共享了mm_struct，用来实现线程)，一个thread.start就相当于do_fork了一把。 其中，我们在JVM启动时候设置了-Xss=512K(即线程栈大小)，这512K中然后有8K是必须使用的，这8K是由进程的内核栈和thread_info公用的，放在两块连续的物理页框上。如下图所示:

找到关键点 在看到12452个等待在CachedBnsClient.run的业务的一瞬间笔者就意识到，肯定是这边的线程导致对外内存泄露了。下面就是根据线程大小计算其泄露内存量是不是确实能够引起OOM了。 发现内存计算对不上 由于我们这边设置的Xss是512K，即一个线程栈大小是512K，而由于线程共享其它MM单元(线程本地内存是是现在线程栈上的)，所以实际线程堆外内存占用数量也是512K。进行如下计算: 12563 * 512K = 6331M = 6.3G 整个环境一共4G，加上JVM堆内存1.8G(1792M)，已经明显的超过了4G。 (6.3G + 1.8G)=8.1G > 4G 如果按照此计算，应用应用早就被OOM了。 怎么回事呢？ 为了解决这个问题，笔者又思考了好久。如下所示: Java线程底层实现 JVM的线程在linux上底层是调用NPTL(Native Posix Thread Library)来创建的，一个JVM线程就对应linux的lwp(轻量级进程，也是进程，只不过共享了mm_struct，用来实现线程)，一个thread.start就相当于do_fork了一把。 其中，我们在JVM启动时候设置了-Xss=512K(即线程栈大小)，这512K中然后有8K是必须使用的，这8K是由进程的内核栈和thread_info公用的，放在两块连续的物理页框上。如下图所示:

引言 在当前通信市场的带动下，通信技术飞速向前发展，手持无线通信终端成为其中的热门应用之一。因此，单片集成的射频收发系统正受到越来越广泛的关注。典型的射频收发系统包括低噪声放大器(LNA)、混频器(Mixer)、滤波器、可变增益放大器，以及提供本振所需的频率综合器等单元模块，如图1 所示。对于工作在射频环境的电路系统，如2.4G 或5G 的WLAN 应用，系统中要包含射频前端的小信号噪声敏感电路、对基带低频大信号有高线性度要求的模块、发射端大电流的PA 模块、锁相环频率综合器中的数字块，以及非线性特性的VCO等各具特点的电路。众多的电路单元及其丰富的特点必然要求在这种系统的设计过程中有一个功能丰富且强大的设计平台。在综合比较后，本文选定了Cadence Virtuoso 全定制IC 设计工具。 图1 典型的射频收发系统 Virtuoso 是Cadence 公司推出的用于模拟/数字混合电路仿真和射频电路仿真的专业软件。基于此平台，Cadence 公司还开发了面向射频设计的新技术，包括射频提取技术、针对无线芯片设计的两个新设计流程。不仅如此，目前的Virtuoso 已经整合了来自合作伙伴安捷伦、CoWare、Helic 和Mathworks 等公司的技术，射频设计能力大为增强。使用该项新技术，可以减少设计反复，并缩短产品上市时间。其AMS 工具可以实现自顶向下、数/模混合的电路设计

一般来说内存占用大小有如下规律：VSS>=RSS>=PSS>=USS 1、VSS - Virtual Set Size（用处不大） 虚拟耗用内存（包含共享库占用的全部内存，以及分配但未使用的内存）。其大小还包括了可能不在RAM中的内存（比如malloc分配了空间，但尚未写入）。VSS很少被用于判断一个进程的真实内存使用量。 2、RSS - Resident Set Size（用处不大） 实际使用物理内存（包含共享库占用的全部内存）。但是RSS还是可能会造成误导，因为它仅仅表示该进程所使用的所有共享库的大小，它不管有多少个进程使用该共享库，该共享库仅被加载到内存一次。所以RSS并不能准确反映单进程的内存占用情况。 3、PSS - Proportionnal Set Size（仅供参考） 实际使用的物理内存（比例分配共享库占用的内存，按照进程数等比例划分）。例如，如果有三个进程都使用了一个共享库，共占用三十页内存。那么PSS将认为每个进程分别占用改共享库十页的大小。PSS是非常有用的数据，因为系统中所有进程的PSS相加的话，就刚好反映了系统中的总共占用的内存。而当一个进程别销毁之后，其占用的共享库那部分比例的PSS，将会再次按比例分配给余下使用该库的进程。这样PSS可能会造成一些误导，因为当一个进程销毁的后，PSS不能准确的表示返回给全局系统的内存。 4、USS - Unique

db操作可以说是java后端的必备技能了，实际项目中，直接使用JdbcTemplate的机会并不多，大多是mybatis，hibernate，jpa或者是jooq，然后前几天写一个项目，因为db操作非常简单，就直接使用JdbcTemplate，然而悲催的发现，对他的操作并没有预期中的那么顺畅，所以有必要好好的学一下JdbcTemplate的CURD；本文为第一篇，插入数据 <!-- more --> I. 环境 1. 配置相关 使用SpringBoot进行db操作引入几个依赖，就可以愉快的玩耍了，这里的db使用mysql，对应的pom依赖如 <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> </dependencies> 接着就是db的配置信息,下面是连接我本机的数据库配置 ## DataSource spring.datasource.url=jdbc:mysql:/

解Bug之路-记一次JVM堆外内存泄露Bug的查找 前言 JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识，读者如果有兴趣了解请看ulk3(《深入理解linux内核第三版》) 内存泄露Bug现场 一个线上稳定运行了三年的系统，从物理机迁移到docker环境后，运行了一段时间，突然被监控系统发出了某些实例不可用的报警。所幸有负载均衡，可以自动下掉节点，如下图所示: 登录到对应机器上后，发现由于内存占用太大，触发OOM，然后被linux系统本身给kill了。 应急措施 紧急在出问题的实例上再次启动应用，启动后，内存占用正常，一切Okay。 奇怪现象 当前设置的最大堆内存是1792M，如下所示: -Xmx1792m -Xms1792m -Xmn900m -XX:PermSi ze=256m -XX:MaxPermSize=256m -server -Xss512k 查看操作系统层面的监控，发现内存占用情况如下图所示: 上图蓝色的线表示总的内存使用量，发现一直涨到了4G后，超出了系统限制。 很明显，有堆外内存泄露了。 查找线索 gc日志 一般出现内存泄露