Code Life

我们知道，使用VisualVM可以监控Java应用的各种运行时信息，包括资源占用、正在运行的线程等等。本文将简单介绍如何使用VisualVM的插件Visual GC来监控Java应用的垃圾回收情况。

在Java的垃圾回收算法一文中，我们知道JVM是根据一个对象有没有被引用来判断要不要对其进行垃圾回收的。但是，如果我们为了提升垃圾回收的效率，想要再把垃圾回收的条件更细化一些，比如只在内存非常紧张的时候才回收某些对象，那么光靠一个粗略的“引用”，就显得心有余而力不足了。所以，在JDK 1.2版本之后，Java扩充了引用的概念，将其扩充成了强引用，软引用，弱引用，虚引用四个更细化的概念。

本文将参考《深入理解Java虚拟机(第3版)》中再谈引用一节，简述一下这四种引用的概念，以及被引用的对象何时会被垃圾回收器回收。

在排查垃圾回收相关的问题时，一个必不可少的技能就是要能看懂Java的垃圾回收日志。本文将介绍打印GC日志相关的JVM参数，以及使用不同参数时JVM将会打印出的日志内容。

做技术，不能只知其然而不知其所以然。在知道了工具的原理之后，才能更高效的使用这个工具。在程序的世界里，源码里面没有秘密，看懂了源码，也就看懂了原理。

这次就来阅读一下HashMap的源码。

做技术，不能只知其然而不知其所以然。在知道了工具的原理之后，才能更高效的使用这个工具。在程序的世界里，源码里面没有秘密，看懂了源码，也就看懂了原理。

这次就来阅读一下Object类里面hashCode方法和equals方法的源码。

最近做了一个有点不一样的项目，它是将传入接口的业务参数以JSON的形式放在了一个统一的请求体里面，我要将它取出来，再反序列化到一个Bean里面。这样会带来一个问题，就是我不能直接使用@Valid注解来让框架自行校验参数的合法性，而需要手动调用Validator实现对bean的校验。

在使用nohup的时候，它总会打印一条nohup: appending output to 'nohup.out'这样的信息，并且必须敲一下回车。

因为nohup: appending output to 'nohup.out'这条信息是打印到STDERR的，所以解决的方法很简单，把STDERR重定向至STDOUT就可以了，比如这样：

1

nohup doSomething > nohup.out 2>&1 &

做技术，不能只知其然而不知其所以然。在知道了工具的原理之后，才能更高效的使用这个工具。在程序的世界里，源码里面没有秘密，看懂了源码，也就看懂了原理。

这次就来阅读一下LinkedList的源码。

在前后端分离的架构下，后端通常是一个RESTFul的接口，而因为HTTP的响应码数量有限，无法灵活的反映出接口执行的各种结果，在这种情况下，就需要通过自定义的结构来表达接口最终的状态和返回的信息。而我正好最近在一个项目中实现了一个基于ControllerAdvice的统一请求响应的功能，在这里记录一下实现的方式。

在application.yml中添加如下配置，即可在Spring Boot项目中开启HTTPS。

1
2
3
4
5
6
7
8
9
10
11
12
13

server:
  # 如果有需要的话，配置应用监听HTTPS的默认端口
  port: 443
  ssl:
    # 我把证书放在了 resources/cert/certificate.pfx下
    # 使用时需要按照实际情况修改下面的路径
    key-store: classpath:cert/certificate.pfx
    key-store-password: pA55w0Rd
    # 证书类型需要按照实际类型填写
    # 本例使用PKCS12格式，所以写PKCS12。如果是JKS格式，那么需要填写JKS
    # 因为PKCS12比JKS有更好的通用型，所以个人建议使用PKCS12格式
    key-store-type: PKCS12
    enabled: true