标签归档：java

WeakReference 使用不当导致OOM？

发表于由
回复

9月5、6号两天，有个古老的应用连续出现频繁的 FullGC，最终OOM。
这个古老应用的框架是十多年前基于 Spring 魔改的，在部署上分为 web、app 两层，web通过 EJB 进行调用app里的服务访问数据库。

这两层访问 Spring 容器里的 Bean 一般都是通过类似下面的写法来获取：

SomeService service = CustAppContextHolder.getContext(contextName).getBean(beanName);
service.doSomething();

// CustAppContextHolder.getContext 的实现大致如下：
public class CustAppContextHolder {
private static Map<String, WeakReference> caches = new ConcurrentHashMap<String, WeakReference>();

public static ApplicationContext getContext(String contextName) {
    WeakReference<ApplicationContext> weakReference = caches.get(contextName);
    ApplicationContext context;
    if (weakReference != null && (context = weakReference.get()) != null) {
        return context;
    } else {
        synchronized (CustAppContextHolder.class) {
            context = initContext(contextName);
            caches.put(contextName, new WeakReference<>(context));
        }
    }
    return context;
}

private static ApplicationContext initContext(String contextName) {
    System.out.println("init context:" + contextName);
    return null;
}

}

继续阅读 →

小心 fastjson 的这种“智能”

发表于由
回复

最近碰到一个现象或者说问题，同一个 JSON 格式的字符串，Spring 默认的 Jackson 类库解析报错，fastjson 却没报错、正常解析了。

场景大概是这样的，有个类有个日期属性，格式指定为 “yyyy-MM-dd”。

@Data
static class Person {
    @JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT+8") // Jackson
    @JSONField(format = "yyyy-MM-dd") // fastjson
    Date birthDay;

    @JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT+8")
    @JSONField(format = "yyyy-MM-dd")
    Date today;

    String name;
}

测试代码如下

public void testFastJson() throws JsonProcessingException {
    String json = "{\"birthDay\":\"2022710\", \"name\": \"coderbee\", \"today\":\"2022-07-10\"}";
    Person person = JSONObject.parseObject(json, Person.class);
    System.out.println(person);     // 输出解析到对象
    System.out.println(JSONObject.toJSONString(person)); // 把对象转换为 JSON 字符串，再输出。

    ObjectMapper mapper = new ObjectMapper();
    Person jacksonPerson = mapper.readValue(json, Person.class);
    System.out.println(jacksonPerson);
}

继续阅读 →

ConcurrentHashMap

发表于由
回复

1. 为什么 key 和 value 不允许为 null

HashMap 中允许 key、value 为 null，key 为 null 时哈希值为 0 。

ConcurrentHashMap 中都不能为 null 是因为作者 Doug Lea 认为：在并发编程中，null 值容易引来歧义，当调用 get(key) 返回 null 时，无法确定是 key 对应的 value 就是 null ，还是说这个 key 不存在。
非并发编程中可以通过调用 containsKey 方法来判断，但并发编程中无法保证这两个方法之间没有其他线程来修改 key 值。

2. 并行度 concurrencyLevel

ConcurrentHashMap 构造函数里有个参数 concurrencyLevel 提供了建议支持的并行度。

在 JDK 1.7 的实现里，分段锁段数组的大小由 concurrencyLevel 决定，为大于 concurrencyLevel 的最小的 2 次幂值，但不能超过 2^16，初始化后不能修改。

在 JDK 1.8 里，concurrencyLevel 会影响 Node 数组的初始容量，由于并发粒度是数组的元素，从而影响并发度。

concurrencyLevel 并不是指定了精确的并发度。

继续阅读 →

HashMap

发表于由
1

本文源码基于 JDK 1.8.0_101 。

在 JDK 1.8 之前，HashMap 采用 槽数组 + 单链表 来实现；

在 JDK 1.8 开始采用 槽数组 + 单链表 + 红黑树 来实现。

1. 为什么引入红黑树？

解决哈希冲突时、链表过长导致访问效率低下的问题。

为什么是红黑树不是其他树：
二叉排序树在极端情况下会退化成线性结构。
平衡二叉树（AVL树）是严格平衡树，在增加或删除节点时，旋转次数比红黑树要多。红黑树的统计性能高于 AVL 树。

红黑树特性，RBT树上的每个节点，都要遵循下面的规则：
① 每个节点都是红色或者黑色；
② 根节点必须始终是黑色；
③ 没有两个相邻的红色节点；
④ 对每个结点，从该结点到其子孙节点的所有路径上包含相同数目的黑结点。

继续阅读 →

Javassist 字节码操作库

发表于由

研究 Javassist 的起因是维护的项目是从外部采购的一个系统，有几个核心的类在构造函数里从数据库加载一些配置信息，而这些配置信息基本是不会改变的，应当缓存起来。这些类没有源码，class 文件还是混淆过的。

想来想去，觉得用字节码操作工具来改写是比较合适的，把改写后生成的 class 文件替换原来的，这样使用这些类的地方也不用做任何修改。

1. Javassist 简介

Javassist 是一个字节码操作库，通过它，可以在运行时改写类：添加新的字段、方法和构造函数，改变类、父类和接口的方法。

Javassist 定义了 CtField, CtMethod, CtConstructor, CtClass 来表示 字段、方法、构造函数、类。

继续阅读 →

Java finalize 方法与垃圾回收

发表于由
回复

JVM 对于覆写了 Object.finalize() 方法的类是实例，在垃圾回收时，先放进一个队列里，
然后用一个线程执行这些实例的 finalize 方法，最后才做内存回收。

这个机制的问题是：它会影响垃圾回收，如果实现了 finalize 的实例很多，那么回收队列就会很长，而只有一个线程
在执行这些方法，这些对象就会回收得很慢。

最近碰到的一个问题跟 finalize 方法有关。
厂商提供的代码把 javax.sql.Connection 做了层封装，覆写了 finalize 方法，在里面把 Connection 关闭了。

一个同事调用的方法定义是用封装类作为入参，他调用的时候是直接 new 了一个封装类，把 connection 传进去，后续数据库操作就不定位置出现连接关闭的异常。原因就是这个临时 new 出来的封装类被垃圾回收，把 connection 关闭了。由于垃圾回收的时间是不确定的，所以报异常的时间点也不确定。

欢迎关注我的微信公众号: coderbee笔记，可以更及时回复你的讨论。

计算 一个点 附近的地方

发表于由
回复

问题

随着地理位置的应用普及，越来越多类似计算 一个点 附近的酒店的需求。比如，显示当前位置2000米范围内的 7 天酒店。

一般来说，在系统里都有一张表，存储了每个 7 天酒店的位置信息，表结构可以简化为三个字段 tb_location（ID, lng, lat），其中 lng：表示经度；lat：表示纬度，这两个字段都是数值类型的，且建了索引。

现在要把 2 公里范围内的 7 天酒店找出来，有的人写的 SQL 语句大概是这样的：
select id from tb_location where calc_distance(lng, lat, curLng, curLat) < 2000

这个语句的问题是没法利用索引，需要全表扫描，计算每一条记录与当前位置的距离，效率很低。

优化

用一张图来说明优化策略：
附近地点计算优化

继续阅读 →

Java 对象内存布局

发表于由
1

本文来自：http://www.ibm.com/developerworks/cn/java/j-codetoheap/

寻址能力与用户空间

进程能够处理的位数取决于处理器能寻址的内存范围，处理器的寻址能力取决于处理器的位数，比如 32 位能寻址 2^32，也就是 4G。

处理器提供的部分可寻址范围由 OS 本身用，供操作系统内核以及 C 运行时。OS 和 C 运行时占用的内存数量取决于所用的 OS，比如 Windows 默认占用 2GB。剩余的可寻址空间是供运行的实际进程使用的内存（用户空间）。

对于 Java 应用程序，用户空间是 Java 进程占用的内存，实际上包含两个池：Java 堆和本机（非 Java）堆。Java 堆的大小由 JVM 的 Java 堆设置控制：-Xms 和 -Xmx 分别设置最小和最大 Java 堆。在按照最大的大小设置分配了 Java 堆之后，剩下的用户空间就是本机堆。
32bit JVM

可寻址范围总共有 4GB，OS 和 C 运行时大约占用了其中的 1GB，Java 堆占用了将近 2GB，本机堆占用了其他部分。请注意，JVM 本身也要占用内存，就像 OS 内核和 C 运行时一样，而 JVM 占用的内存是本机堆的子集。

继续阅读 →

Java SE 6 故障排除指南 – 4、系统崩溃故障排除

发表于由
回复

崩溃或致命错误导致进程异常终止。有各种可能的理由导致崩溃。例如，崩溃可能是由于HotSpot VM、系统库、Java SE 库或API、程序本地代码、甚至操作系统里的 bug。极端因素如操作系统资源耗尽也可以导致崩溃。

因 HotSpot VM 或 Java SE库代码导致的崩溃是罕见的。本章提供如何检查崩溃的建议。有时候可以变通崩溃直到导致崩溃的源被诊断和修复（也就是可以避开崩溃）。

通常，崩溃的第一步是定位致命错误日志。这是HotSpot VM生成的文本文件。附录C-致命错误日志 解释了如何定位文件和文件的详细描述。

4.1 崩溃样本

本节展示一些样本来说明错误日志是如何用于启发崩溃原因的。

4.1 测定哪里发生崩溃

错误日志头显示了有问题的帧。见 C.3 格式头。

如果顶层帧是本地帧且不是操作系统本地帧，这表明问题可能发生在本地库，而不是在JVM里。解决崩溃的第一步是研究本地库发生崩溃的源。有三个选择，取决于本地库的源。

如果本地库是由你的程序提供，研究你的本地库的源代码。选项 -Xcheck:jni 可以帮助查找本地 bug。见 B.2.1 -Xcheck:jni 选项。

如果你的程序使用的本地库是由其他供应商提供，报告bug，提供致命错误日志信息。

继续阅读 →

Java SE 6 故障排除指南 – 5、挂起或循环进程故障排除

发表于由
回复

本章为挂起或循环进程的故障排除在特定程序上提供了信息和指导。

问题在涉及挂起或循环进程时发生。挂起可能因为多种原因发生，但经常是源于程序代码、API代码或库代码里的死锁。挂起甚至是因为 HotSpot VM的bug。

有时候，一个表面上是挂起的可能是个循环。例如，VM进程里的bug导致一个或多个线程进入死循环，会消耗掉所有可得CPU周期。

诊断挂起的最初步骤是找出VM进程是空闲还是消耗了所有可得CPU周期，为做这个要求使用操作系统工具。如果进程表现为繁忙且消耗了所有可得CPU周期，那么问题很可能是循环线程而不是死锁。

继续阅读 →