Java Web 人员经常要设计 RESTful API(如何设计好的RESTful API),通过 json 数据进行交互。那么前端传入的 json 数据如何被解析成 Java 对象作为 API入参,API 返回结果又如何将 Java 对象解析成 json 格式数据返回给前端,其实在整个数据流转过程中,HttpMessageConverter 起到了重要作用;另外在转换的过程我们可以加入哪些定制化内容? HttpMessageConverter 介绍 org.springframework.http.converter.HttpMessageConverter 是一个策略接口,接口说明如下
前言 在 Java 12 里面有个非常好用但在官方 JEP 没有公布的功能,因为它只是 Collector 中的一个小改动,它的作用是 merge 两个 collector 的结果,这句话显得很抽象,老规矩,我们先来看个图: 管道改造经常会用这个小东西,通常我们叫它「三通」,它的主要作用就是将 downstream1 和 downstream2 的流入合并,然后从 merger 流出 有了这个形象的说明我们就进入正题吧 Collectors.teeing 上面提到的小功能就是 Collectors.teeing API, 先来看一下 JDK 关于该 API 的说明,看着觉得难受的直接忽
写在前面 上一篇文章共享资源那么多,如何用一把锁保护多个资源? 文章我们谈到了银行转账经典案例,其中有两个问题: 1. 单纯的用 synchronized 方法起不到保护作用(不能保护 target) 2. 用 Account.class 锁方案,锁的粒度又过大,导致涉及到账户的所有操作(取款,转账,修改密码等)都会变成串行操作 如何解决这两个问题呢?咱们先换好衣服穿越回到过去寻找一下钱庄,一起透过现象看本质,dengdeng deng……. 来到钱庄,告诉柜员你要给铁蛋儿转 100 铜钱,这时柜员转身在墙上寻找你和铁蛋儿的账本,此时柜员可能面临三种情况: 1. 理想状态:
写在前面 我们每次构建一个 Spring 应用程序时,我们都不希望从头开始实现具有「横切关注点」的内容;相反,我们希望一次性实现这些功能,并根据需要将它们包含到任何我们要构建的应用程序中 横切关注点 横切关注点: 指的是一些具有横越多个模块的行为 (来自维基百科的介绍) 说白了就是多个项目或模块都可以用到的内容,比如一个 SDK 在Spring Boot中,用于表示提供这种横切关注点的模块的术语是 starter,通过依赖 starter 可以轻松使用其包含的一些功能特性,无论你的工作中是否会构建自己的 starter,你都要具有构建 「starter」的思想,本文将结合 Spring
写在前面 上一篇文章原子性问题的宏观理解 带领大家了解了锁和资源的模型,有了这篇文章的铺垫,相信理解这一篇文章就非常轻松了 当我们要保护单个资源并对其进行修改其实很简单,只需按照下图分三步走 1. 创建受保护资源 R 的锁 2. 加锁进入临界区 3. 解锁走出临界区 上图的关键是「R1 的锁保护 R1」的指向关系是否正确 如果都是保护单个资源这样简单,程序猿的世界该有多美好,可惜并不是,通常我们需要保护多个资源 保护多个资源 保护多个没有关系的资源 如果多个资源没有关系,那就是保护一个资源模型的复制,同样非常简单,且看下图: 比如现实中银行取款和修改密码操作。 银行取
写在前面 Java 后端程序员应该会遇到读取 Excel 信息到 DB 等相关需求,脑海中可能突然间想起 Apache POI 这个技术解决方案,但是当 Excel 的数据量非常大的时候,你也许发现,POI 是将整个 Excel 的内容全部读出来放入到内存中,所以内存消耗非常严重,如果同时进行包含大数据量的 Excel 读操作,很容易造成内存溢出问题 但 EasyExcel 的出现很好的解决了 POI 相关问题,原本一个 3M 的 Excel 用 POI 需要100M左右内存, 而 EasyExcel 可以将其降低到几 M,同时再大的 Excel 都不会出现内存溢出的情况,因为是逐行读取 E
写在前面 在 可见性有序性,Happens-before来搞定 文章中,happens-before 的原则之一: volatile变量规则 对一个 volatile 域的写, happens-before 于任意后续对这个 volatile 域的读 按理说了解了这个规则,对 volatile 的使用就已经足够了,但是面试官可是喜欢刨根问到底的,为了更透彻的了解 volatile 的内存语义与读写语义,为了面试多一些谈资进而获得一些加分项,同时尽早填补前序文章留下的坑,于是乎这篇文章就这样尴尬的诞生了 happens-before 之 volatile 变量规则 下面的表格你还记得吗?
上一篇文章 可见性有序性,Happens-before来搞定,解决了并发三大问题中的两个,今天我们就聊聊如何解决原子性问题 原子性问题的源头就是 线程切换,但在多核 CPU 的大背景下,不允许线程切换是不可能的,正所谓「魔高一尺,道高一丈」,新规矩来了: 互斥: 同一时刻只有一个线程执行 实际上,上面这句话的意思是: 对共享变量的修改是互斥的,也就是说线程 A 修改共享变量时其他线程不能修改,这就不存在操作被打断的问题了,那么如何实现互斥呢? 锁 对并发有所了解的小伙伴马上就能想到 锁 这个概念,并且你的第一反应很可能就是使用 synchronized,这里列出来你常见的 syn
写在前面 上一篇文章并发 Bug 之源有三,请睁大眼睛看清它们 谈到了可见性/原子性/有序性三个问题,这些问题通常违背我们的直觉和思考模式,也就导致了很多并发 Bug * 为了解决 CPU,内存,IO 的短板,增加了缓存,但这导致了可见性问题 * 编译器/处理器擅自优化 ( Java代码在编译后会变成 Java 字节码, 字节码被类加载器加载到 JVM 里, JVM 执行字节码, 最终需要转化为汇编指令在 CPU 上执行) ,导致有序性问题 初衷是好的,但引发了新问题,最有效的办法就禁止缓存和编译优化,问题虽然能解决,但「又回到最初的起点,呆呆地站在镜子前」是很尴尬的,我们程序的性能就



Copyright 2018-2019 Tanθ's Blog   |   辽ICP备19017651号-1   |     站点总字数: 134.5k 字   |   载入天数...载入时分秒...   |  站点地图   |  站长统计
  总访问量:  次  总访问人数:  人

博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议