其他

闰秒概念是 1972 年提出的，之所以有这个概念，主要是因为由于潮汐等自然现象的影响，地球的自转速度并不是恒定的。 所以，每隔一段时间世界标准时间「协调世界时（UTC）」会依据地球围绕太阳运动计算的「世界时（UT）」之间出现小的偏差。 所以就需要对协调世界时进行调快或者拨慢1秒来消除这个偏差。 闰秒分为正闰秒和负闰秒，正闰秒表示需要在UTC中插入1秒，负闰秒表示需要在UTC中减少1秒。 闰秒发生 当科学家们发现”哎呀、今年的地球转的有点快呀，赶紧加一个闰秒来校正一下吧“，这个时间就会发生”正闰秒”。 当闰秒发生时，就需要通过网络时间协议NTP (Network time protocol)来进行时间同步，NTP服务器会一级一级地下发闰秒事件通知直到最边缘的NTP服务器，然后NTP服务器就会把闰秒通知发给客户端的操作系统，由操作系统来处理闰秒通知。 如果你的计算机系统没有开启NTP服务，那么导致的问题就是你的计算机上的机器时间就会比世界时间慢1秒。 如果开了NTP服务的话，就需要操作系统来处理这个闰秒。 闰秒的处理 一般来说，闰秒的调整一般被安排在6月30日或者12月31日，一般会调整在最后一分钟，也就是说，某一年的6月30日的11:59分有61秒。那么计算机系统会如何处理这个闰秒呢？ 一般有以下几种方式，如： 1、直接显示23:59:60这样的时间。 2、显示两次23:59:59这个时间。 3、把这一秒平均分到最后一分钟的每一秒钟，也就是11:59还是有60秒，但是每一秒的时长是1+1/60 秒。 不同的操作系统，不同操作系统的不同版本，都会有不同的处理方式，所以我们的代码就需要有足够的鲁棒性来兼容这些闰秒的处理方式，如果没有做好兼容，那么就会发生各种各样的问题。 如需要兼容对23:59:60的处理；如操作会出现两次23：59：59，这对于一些对时间有精确的强依赖的程序来说，可能就会导致致命的问题，尤其是一些依赖时间戳的服务或者工具。 闰秒的危害 50年来，闰秒已经出现过27次，每一次出现都是一片”哀鸿遍野”，如： 2012 年 7 月 1 日零点， Reddit、Mozilla、领英、Yelp 和 Amadeus 等网站宕机数十分钟。 2015 年 7 月 1 日零点，全球约 2000 个计算机网络突然短暂中断；美国洲际交易所被迫中止交易 61 分钟。 2017 年 1 月 1 日零点，Cloudflare 等云服务厂商服务突然崩溃。 因为闰秒的发生是受自然现象影响的，所以他完全无法预测也没有任何规律。对于程序员来说，这种无规律的事情，每次发生都需要进行一次特殊处理，而每一次特殊处理都可能要付出惨痛的代价。 2022年，Google、微软、facebook 和亚马逊终于忍不了了，联合呼吁废除闰秒。。。

典型回答 jmap是JDK自带的工具软件，主要用于打印指定Java进程的内存细节。也就是说可以使用jmap生成Heap Dump。如果程序内存不足或者频繁GC，很有可能存在内存泄露情况，这时候就要借助Java堆Dump查看对象的情况。 堆Dump是反应Java堆使用情况的内存镜像，其中主要包括系统信息、虚拟机属性、完整的线程Dump、所有类和对象的状态等。 一般，在内存不足、GC异常等情况下，我们就会怀疑有内存泄露。这个时候我们就可以制作堆Dump来查看具体情况。分析原因。 需要注意：对线程/堆进行Dump时（执行jstack、jmap等命令时），是想要获取线程或者堆在特定时刻的状态和信息。为了确保这些信息的准确性和一致性，JVM在进行Dump时会暂停所有线程。也需要进入安全点才行。 扩展知识 使用 用法摘要 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Usage: jmap [option] <pid> (to connect to running process) jmap [option] <executable <core> (to connect to a core file) jmap [option] [server_id@]<remote server IP or hostname> (to connect to remote debug server) where <option> is one of: <none> to print same info as Solaris pmap -heap to print java heap summary -histo[:live] to print histogram of java object heap; if the "live" suboption is specified, only count live objects -permstat to print permanent generation statistics -finalizerinfo to print information on objects awaiting finalization -dump:<dump-options> to dump java heap in hprof binary format dump-options: live dump only live objects; if not specified, all objects in the heap are dumped. format=b binary format file=<file> dump heap to <file> Example: jmap -dump:live,format=b,file=heap.bin <pid> -F force. Use with -dump:<dump-options> <pid> or -histo to force a heap dump or histogram when <pid> does not respond. The "live" suboption is not supported in this mode. -h | -help to print this help message -J<flag> to pass <flag> directly to the runtime system 指定进程号(pid)的进程 jmap [ option ] 指定核心文件 jmap [ option ] 指定远程调试服务器 jmap [ option ] [server-id@] ...

典型回答 我们知道，很多Java命令都在jdk的JAVA_HOME/bin/目录下面，jps也不例外，他就在bin目录下，所以，他是java自带的一个命令。 jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一个显示当前所有java进程pid的命令，简单实用，非常适合在linux/unix平台上简单察看当前java进程的一些简单情况。 扩展知识 原理 jdk中的jps命令可以显示当前运行的java进程以及相关参数，它的实现机制如下： java程序在启动以后，会在java.io.tmpdir指定的目录下，就是临时文件夹里，生成一个类似于hsperfdata_User的文件夹，这个文件夹里（在Linux中为/tmp/hsperfdata_{userName}/），有几个文件，名字就是java进程的pid，因此列出当前运行的java进程，只是把这个目录里的文件名列一下而已。 至于系统的参数什么，就可以解析这几个文件获得。 1 2 3 4 5 6 7 8 hollis@hos:/tmp/hsperfdata_hollis$ pwd /tmp/hsperfdata_hollis hollis@hos:/tmp/hsperfdata_hollis$ ll total 48 drwxr-xr-x 2 hollis hollis 4096 4月 16 10:54 ./ drwxrwxrwt 7 root root 12288 4月 16 10:56 ../ -rw------- 1 hollis hollis 32768 4月 16 10:57 2679 hollis@hos:/tmp/hsperfdata_hollis$ 上面的内容就是我机器中/tmp/hsperfdata_hollis目录下的内容，其中2679就是我机器上当前运行中的java的进程的pid，我们执行jps验证一下： 1 2 3 hollis@hos:/tmp/hsperfdata_hollis$ jps 2679 org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar 4445 Jps 执行了jps命令之后，我们发现有两个java进程，一个是pid为2679的eclipse运行的进程，另外一个是pid为4445的jps使用的进程（他也是java命令，也要开一个进程） ...

典型回答 jstack用于生成java虚拟机当前时刻的线程快照。 线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合 生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。 需要注意：对线程/堆进行Dump时（执行jstack、jmap等命令时），是想要获取线程或者堆在特定时刻的状态和信息。为了确保这些信息的准确性和一致性，JVM在进行Dump时会暂停所有线程。也需要进入安全点才行。 扩展知识 使用 想要学习一个命令，先来看看帮助，使用jstack -help查看帮助： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 hollis@hos:~$ jstack -help Usage: jstack [-l] <pid> (to connect to running process) jstack -F [-m] [-l] <pid> (to connect to a hung process) jstack [-m] [-l] <executable> <core> (to connect to a core file) jstack [-m] [-l] [server_id@]<remote server IP or hostname> (to connect to a remote debug server) Options: -F to force a thread dump. Use when jstack <pid> does not respond (process is hung) -m to print both java and native frames (mixed mode) -l long listing. Prints additional information about locks -h or -help to print this help message -F当’jstack [-l] pid’没有响应的时候强制打印栈信息 -l长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表. -m打印java和native c/c++框架的所有栈信息. -h | -help打印帮助信息 pid 需要被打印配置信息的java进程id,可以用jps查询. ...

典型回答 jstat(JVM Statistics Monitoring Tool)是用于监控虚拟机各种运行状态信息的命令行工具。他可以显示本地或远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据，在没有GUI图形的服务器上，它是运行期定位虚拟机性能问题的首选工具。 jstat位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。可见，Jstat是轻量级的、专门针对JVM的工具，非常适用。 jstat 命令格式： 1 jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]] option — 选项，我们一般使用 -gcutil 查看gc情况 vmid — VM的进程号，即当前运行的java进程号 interval– 间隔时间，单位为秒或者毫秒 count — 打印次数，如果缺省则打印无数次 扩展知识 使用 参数interval和count代表查询间隔和次数，如果省略这两个参数，说明只查询一次。假设需要每250毫秒查询一次进程5828垃圾收集状况，一共查询5次，那命令行如下： 1 jstat -gc 5828 250 5 常见用法 1、jstat –class : 显示加载class的数量，及所占空间等信息。 2、jstat -compiler 显示VM实时编译的数量等信息。 3、jstat -gc : 可以显示gc的信息，查看gc的次数，及时间。 4、jstat -gccapacity :可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小 5、jstat -gcutil :统计gc信息 6、jstat -gcnew :年轻代对象的信息。 7、jstat -gcnewcapacity: 年轻代对象的信息及其占用量。 8、jstat -gcold ：old代对象的信息。 9、stat -gcoldcapacity : old代对象的信息及其占用量。 10、jstat -gcpermcapacity: perm对象的信息及其占用量。 11、jstat -printcompilation ：当前VM执行的信息。

典型回答 在SaaS系统中，多租户是个基本功能了，就是你服务的每一个公司有一个自己的租户，系统要同时支持多个租户一起使用，并且他们之间要互相隔离。 SaaS多租户的实现方案主要涉及数据隔离和资源共享的平衡 最常见的方案就是共享数据库，然后通过租户id来做逻辑隔离。 即所有租户共享同一数据库和Schema，通过tenant_id字段区分不同租户的数据。每条记录均包含tenant_id，应用层在查询时自动附加WHERE tenant_id = ?条件。这个方案是最常见的，因为他足够简单，只需要加个字段就行了。但是缺点是他只是逻辑隔离，存在数据泄露的风险，并且多个租户共用一个数据库，可能会存在互相影响的情况。比如某个租户数据量大、请求量大可能占用一些公共的数据库资源。 那么，好一点的方案是共享数据库，独立分区（分表）。 每个租户在同一个数据库中拥有独立分区（分表）。应用层根据租户标识动态切换分区（分表）。这个方案就比在一个数据库同一个分区中要好一点，因为至少大家是不同的分区，数据在物理上是隔离开的。但是他还是有一个瓶颈，那就是大家用的还是同一个数据库，单数据库连接数还是可能成为瓶颈。 那么，进一步的方案就是独立数据库 每个租户拥有独立的数据库实例，应用层通过租户标识路由到对应数据库连接。这么做就是完完全全的物理隔离，大家数据也不在一起，底层用到的硬件资源也都不在一起，完全做到互相不影响。但是缺点就是贵。。。 但是实际很多公司，并不一定要采用一套固定的方案，有可能采用混合模式 比如根据租户规模或需求动态选择隔离级别，针对小型租户，大家共用一个公共数据库，对于一些大客户，VIP客户，给他独立的分区，对于一些数据安全性要求比较高，受监管，愿意给更多钱的用户，给他独立部署。 方案对比 方案 隔离性 扩展性 成本 适用场景 共享数据库，租户id逻辑隔离 低 低 低 小型应用，快速试错 共享数据库，独立分区（分表） 中 中 中 中等规模，需一定隔离性 独立数据库 高 高 高 高安全性需求（金融、医疗） 混合模式 灵活 高 中高 租户规模差异大