Java异步编程指南
在我们平时开发中或多或少都会遇到需要调用接口来完成一个功能的需求，这个接口可以是内部系统也可以是外部的，然后等到接口返回数据了才能继续其他的业务流程，这就是传统的同步模式。 同步模式虽然简单但缺点也很明显，如果对方服务处理缓慢迟迟未能返回数据，或网络问题导致响应变长，就会阻塞我们调用方的线程，导致我们主流程的耗时latency延长，传统的解决方式是增加接口的超时timeout设置，防止无限期等待。
sofia
2020年02月08日注册2024年10月27日最后登录
没有个人说明
- 发表了 552 篇文章
线程池ForkJoinPool简介
ForkJoinPool线程池最大的特点就是分叉(fork)合并(join)，将一个大任务拆分成多个小任务，并行执行，再结合工作窃取模式(worksteal)提高整体的执行效率，充分利用CPU资源。 一. 应用场景 ForkJoinPool使用分治算法，用相对少的线程处理大量的任务，将一个大任务一拆为二，以此类推，每个子任务再拆分一半，直到达到最细颗粒度为止，即设置的阈值停止拆分，然后从最底层的任
JVM学习笔记之client server端区别
今天继续远程办公，好想出去打篮球，但是怂，外面场地也不开放，只能窝在家憋大招。 互联网公司流行敏捷开发，快速迭代，所以憋出的大招不一定适用(扯远了)。 言归正传这次和大家分享一些虚拟机方面的知识，主要是关于jvm的client和server端区别，支持的工作模式有哪几种以及他们之间的关系。 java -version 命令大家都用过，大部分就是看下jdk版本或检查下环境变量的设置，但最后一行的信息
JVM学习笔记之codeCache
上海这边的互联网公司大部分是2-7号在家远程办公，有些可能更晚，这期间工作上的事情不多，就把《深入理解java虚拟机》这本书又撸了一遍，顺便写下心得体会，和大家分享，温故知新。 一. codeCache简介 从字面意思理解就是代码缓存区，它缓存的是JIT(Just in Time)编译器编译的代码，简言之codeCache是存放JIT生成的机器码(native code)。当然JNI(Java本地
Java开发规范之性能篇
JAVA开发中，大部分的性能问题原因并不在于JAVA语言本身，而是我们用这些语言写的程序，所以养成良好的编码习惯非常重要。 下面给大家分享一些日常开发中比较常见的典型案例： 一. 类中的内部方法声明为private 很多同学觉得这个无所谓，写代码时喜欢一个类里的所有方法都是public的(原因大家都懂)，美其名曰：便于后期扩展。。 对于不需要外部访问的方法改为私有的，不仅仅是因为面向对象的思想，符
Java踩坑记系列之线程池
线程池大家都很熟悉，无论是平时的业务开发还是框架中间件都会用到，大部分都是基于JDK线程池ThreadPoolExecutor做的封装，比如tomcat的线程池，当然也有单独开发的，但都会牵涉到这几个核心参数的设置：核心线程数，等待队列，最大线程数，拒绝策略等。 先说下我们项目组在使用线程池时踩到的坑： 线程池的参数设置一定要结合具体的业务场景，区分I/O密集和CPU密集，如果是I/O密集型业务，
Windows环境下如何进行线程dump分析
现在大部分公司都有自己完整的一套监控系统，比如美团的CAT，我们公司的监控系统也是基于CAT做的二次开发。一般测试环境或生产环境有问题可以直接使用这些系统查看线程和内存运行情况，分析排查问题。 但对于我们开发人员来说还是有必要了解最原始的排查流程，也就是不借助这些系统，使用最基本的命令解决，毕竟了解了这些底层实现对自身发展也是有帮助的。 网上搜下这样的文章其实很多，比如排查cpu过高，死锁问题的文
JVM Metaspace内存溢出排查与总结
一. 现象 前段时间公司线上环境的一个Java应用因为OOM的异常报警，导致整个服务不可用被拉出集群，本地模拟重现的现象如下: 当时的解决方案是增加metaspace的容量：-XX:MaxMetaspaceSize=500m，从原来默认的256m改为500m，虽然没有再出现oom，但这个只是临时解决方案，通过公司的监控系统观察metaspace的使用情况还是在上升，而且后面随着业务访问量越来越大还
Java在线诊断利器之Arthas
一. 简介 Arthas是阿里在2019年9月份开源的一款java在线诊断工具，能够分析、诊断、定位java应用问题，例如：jvm信息、线程信息、搜索类中的方法、 跟踪代码执行、观测方法的入参和返回参数等等。 Arthas最大的特点是能在不修改代码和不需要重新发布的情况下，对业务问题进行诊断，包括查看方法调用的出参入参、异常、监测方法执行耗时、类加载信息等，大大提升线上问题排查效率。 二. 适用场
Java开发利器之重试器
在平时开发中经常会遇到需要调用接口和外部服务的场景，但是有些接口服务方不能立即返回数据，而是需要处理一段时间才能返回真实的业务数据，如果没有处理完则直接返回一个中间状态的结果。 业务场景： 代码中存在依赖不稳定的场景，需要使用重试获取预期结果或者尝试重新执行逻辑不立即结束，比如远程接口访问，数据加载访问，数据上传校验等 对于异常需要重试的场景，同时希望把正常逻辑和重试逻辑解耦 对方接口不支持异步回
Java踩坑记系列之Arrays.asList
java.util.Arrays的asList方法可以方便的将数组转化为集合，我们平时开发在初始化ArrayList时使用的比较多，可以简化代码，但这个静态方法asList()有几个坑需要注意: 一. 如果对集合使用增加或删除元素的操作将会报错 如下代码： List list = Arrays.asList(“a”,”b”,”c”); list.add(“d”); 输出结果: Exception
Java踩坑记系列之BigDecimal
在java.math包中提供了对大数字的操作类，用于进行高精确计算，如BigInteger，BigDecimal类。而平常我们开发中使用最多的float和double只能适用于一般的科学和工程计算，如果要在比较精确的计算方面如货币，那么使用float和double会相应的丢失精度，因此用于精密计算大数字的类BigDecimal就必不可少了。所以BigDecimal适合商业计算场景，用来对超过16位
