Browsed by
标签:JVM

甲骨文:有史以来最伟大的25个Java应用程序

甲骨文:有史以来最伟大的25个Java应用程序

閱讀本文約花費: 22 (分鐘)作者 | Alexa Morales译者 | 刘雅梦策划 | TinaJava 的故事始于 1991 年,当时 Sun Microsystems 试图将其在计算机工作站市场的领先地位扩展到新兴且发展迅速的个人电子产品市场。几乎没有人预料到 Sun 即将创建的编程语言会使计算大众化,激发了一个全球范围的社区,并成为了一个由语言、运行时平台、SDK、开源项目以及许多工具组成的持久软件开发生态系统的平台。经过 James Gosling 领导的数年秘密开发之后,Sun 于 1995 年发布了具有里程碑意义的“一次编写,随处运行” 的 Java 平台,并将重点从最初的交互式电视系统设计转到了新兴的万维网应用程序上。在本世纪初,Java 就已经开始为从智能卡到太空飞行器的一切制作动画了。 如今,数以百万计的开发人员在使用 Java 编程,Java 仍然在以越来越快的步伐向前发展。在 Java 诞生 25 周年之际,Java Magazine(Oracle 的双月刊)联合 Oracle Java 开发团队,共同撰文回顾 Java 是如何塑造我们这个星球的。 以下是迄今为止,最具创意和影响力的 25 个 Java 应用程序, 包含了从 Wikipedia Search 到美国国家安全局的 Ghidra 等。这些应用包罗万象,覆盖了包括:太空探索、视频游戏…

Read More Read More

微服务网关

微服务网关

閱讀本文約花費: 14 (分鐘) 本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 一、前言 随着微服务的兴起,基于其业务耦合性低、负载能力强、服务边界清晰等优点,大家纷纷使用微服务架构来实现新系统或进行老系统的改造。微服务在带来诸多好处的同时,也有一些问题需要解决,比如:如何做到有效拆分、减少服务间调用,如何统一管理所有服务的接口,如何进行自动化部署等。本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 二、API网关简介 API网关,顾名思义,是统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。下图为微服务架构的简单示意图,网关起到的作用一目了然。 三、API网关的作用 为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。 所以实现或者选择一个好的API网关,是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署,要尽可能的减少接触面…

Read More Read More

微服务与网关技术(SIA-GateWay)

微服务与网关技术(SIA-GateWay)

閱讀本文約花費: 18 (分鐘) 编辑推荐:文章主要介绍了微服务架构特性,微服务网关的分类以及作用,SIA-GateWay等,希望能对您有所帮助。 一. 背景 软件架构,总是在不断的演进中… 把时间退回到二十年之前,当时企业级领域研发主要推崇的还是 C/S 模式,PB、Delphi 这样的开发软件是企业应用开发的主流。随着时间不断的推移,基于浏览器的的 B/S 架构开始渐渐流行了起来。初期,Web 开发 ASP 还占据了不少优势,但 JSP 的预编译模式让性能有了很大的提升,随后基于 JAVA 语言的 J2EE 架构变的越来越流行。 早期软件架构基本都是单体架构,系统之间往往不需要进行交互,这也导致数据孤岛和 ETL 工具的发展。随着企业应用越来多,相互的关系也越来密切。应用之间也迫切需要进行实时交互访问,随后基于 XML 的异构系统集成和数据交互技术开始被很多公司采用,SOA 的概念被提了出来,web service 逐渐流行起来。 互联网时代,很多公司为了适应更加灵活的业务需求,基于 HTTP 协议和 Restful 的架构风格及简洁和结构清晰的 JSON 语言成为企业开发的最佳实践,在 SOA 架构中,企业服务总线技术 ESB 所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此,微服务架构逐渐流行起来。 在《微服务设计》中如…

Read More Read More

线程池运用不当的一次线上事故

线程池运用不当的一次线上事故

閱讀本文約花費: 11 (分鐘)在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高单个线程的复用能力,进一步提升整体性能。 今天遇到了一个比较典型的线上问题,刚好和线程池有关,另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点,同时整个调查思路可以借鉴,特此记录和分享一下。 01 业务背景描述 该线上问题发生在广告系统的核心扣费服务,首先简单交代下大致的业务流程,方便理解问题。 绿框部分即扣费服务在广告召回扣费流程中所处的位置,简单理解:当用户点击一个广告后,会从C端发起一次实时扣费请求(CPC,按点击扣费模式),扣费服务则承接了该动作的核心业务逻辑:包括执行反作弊策略、创建扣费记录、click日志埋点等。 02 问题现象和业务影响 12月2号晚上11点左右,我们收到了一个线上告警通知:扣费服务的线程池任务队列大小远远超出了设定阈值,而且队列大小随着时间推移还在持续变大。详细告警内容如下: 相应的,我们的广告指标:点击数、收入等也出现了非常明显的下滑,几乎同时发出了业务告警通知。其中,点击数指标对应的曲线表现如下: 该线上故障发生在流量高峰期,持续了将近30分钟后才恢复正常。 03 问题调查和事故解决过程 下面…

Read More Read More

JVM各种垃圾收集算法

JVM各种垃圾收集算法

閱讀本文約花費: 7 (分鐘)前言 从如何判定对象消亡的角度出发,垃圾收集算法可以划分为“引用计数式垃圾收集”(Reference Counting GC)和“追踪式垃圾收集”(Tracing GC)两大类,这两类也常被称作“直接垃圾收集”和“间接垃圾收集”。由于束流Java虚拟机中使用 的都是“追踪式垃圾收集”,所以后续介绍的垃圾收集算法都是属于追踪式的垃圾收集。 分代式收集理论 当前商业虚拟机的垃圾收集器,大多数都遵循了“分代收集”的理论进行设计。主要简历在两个分代假说之上:1、弱分代假说:绝大多数对象都是“朝生夕灭”的。2、强分代假说:熬过越多此垃圾收集过程的对象就越难以消亡。这两个分代假说奠定了多款常用的垃圾收集器的一致设计原则:收集器应该将Java堆划分出不同的区域,然后将回收对象依据其年龄(对象熬过垃圾收集过程的次数)分配到不同的区域之中存储。把分代收集理论具体放到现在商用的Java虚拟机里,设计者一般至少会把Java堆划分为新生代(Young Generation) 和 老年代(Old Generation两个区域。在新生代中,每次垃圾收集时都有大批对象死去,而每次回收后存活的少量对象,将会逐步晋升到老年代中存放。 标记-清除算法 标记-清除算法,分为“标记”和“清除”两个阶段:首先标记所有需要回收的对象,标记完成后,统一回收掉所有被标记的对象,也…

Read More Read More

云原生应用 Kubernetes 监控与弹性实践

云原生应用 Kubernetes 监控与弹性实践

閱讀本文約花費: 8 (分鐘) 本文向大家介绍一个云原生应用该如何在Kubernetes中无缝集成监控和弹性能力。希望对您的学习有所帮助。 前言 云原生应用的设计理念已经被越来越多的开发者接受与认可,而Kubernetes做为云原生的标准接口实现,已经成为了整个stack的中心,云服务的能力可以通过Cloud Provider、CRD Controller、Operator等等的方式从Kubernetes的标准接口向业务层透出。开发者可以基于Kubernetes来构建自己的云原生应用与平台,Kubernetes成为了构建平台的平台。 阿里云容器服务Kubernetes的监控总览 云服务集成 阿里云容器服务Kubernetes目前已经和四款监控云服务进行了打通,分别是SLS(日志服务)、ARMS(应用性能监控)、AHAS(架构感知监控服务)、Cloud Monitor(云监控)。 SLS主要负责日志的采集、分析。在阿里云容器服务Kubernetes中,SLS可以采集三种不同类型的日志 APIServer等核心组件的日志 Service Mesh/Ingress等接入层的日志 应用的标准日志 除了采集日志的标准链路外,SLS还提供了上层的日志分析能力,默认提供了基于APIServer的审计分析能力、接入层的可观测性展现、应用层的日志分析。在阿里云容器服务Kubernetes中,日志组件…

Read More Read More

AtomicLongFieldUpdater、AtomicLong、Volatile

AtomicLongFieldUpdater、AtomicLong、Volatile

閱讀本文約花費: 3 (分鐘)初次认识AtomicLongFieldUpdater这个类是在druid源码中看到的,当时很陌生又很好奇,druid中源码是这样的: JavaCopy 定义的一个静态的且不可修改引用的类成员变量,从定义的名称“executeQueryCountUpdater”可以看出来,它是用于执行计数用的。但一时又不明白为什么这样用,它的优点在哪里,为什么不直接用AtomicLong呢,它也是可以原子更新的,线程安全的。于是我搜了一下executeQueryCount,发现类中有这个名称定义的另一个成员变更,源码中是这样定义的: JavaCopy 这个成员变量是long型,且使用了volatile关键字修饰,被volatile修饰的变量,如果值发生了变更,其他线程立马可见,避免出现脏读的现象。但是呢,如果对值要进行修改,因为volatile并不能保证值是原子操作的,就需要对修改值的方法使用同步了。至于为什么使用AtomicLongFieldUpdater,还是没有一个清醒的认识,于是看了一下这个类的源码,首先这个类是一个抽象类,类的注释是这样写的: A reflection-based utility that enables atomic updates to designated fields of designated classes.意思是这个类是基于反射的…

Read More Read More

面试官:你知道java类是怎么跑起来的吗?问的我一脸懵

面试官:你知道java类是怎么跑起来的吗?问的我一脸懵

閱讀本文約花費: 15 (分鐘)类从加载虚拟机内存中开始到卸载出内存为止,生命周期包括:加载、验证、准备、解析、初始化、使用、卸载。 加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的,类的加载过程必须按照这种顺序进行,而解析阶段则不一定,它在某些情况下可能在初始化阶段后在开始,因为java支持运行时绑定。 加载阶段 通过一个类的全限定名来获取定义此类的二进制字节流(没有指明二进制字节流要从一个Class文件中获取,可以从ZIP包中读取,从网络中获取,运行时计算生成等等) 然后,将这个字节流所代表的静态储存结构转化为方法区的运行时数据结构在内存中生成一个代表这个类的java.lang.Class对象,也就是说,当程序中使用任何类时,系统都会为之建立一个java.lang.Class对象。 该Class对象作为方法区这个类的各种数据的访问入口完成后,虚拟机外部的二进制字节流就按照虚拟机所需格式储存在方法区中。 这里稍微理解一下对象和类的概念,对象是实例化的类。类的信息是存储在方法区中的,对象是存储在Java堆中的。类是对象的模板,对象是类的实例。 类的加载由类加载器完成,类加载器通常由JVM提供,这些类加载器也是前面所有程序运行的基础,JVM提供的这些类加载器通常被称为系统类加载器。除此之外,开发者可以通过继承ClassLoader基类来创建自己的类加载器。 其实加载阶段用一句话…

Read More Read More

Coolshell:应该知道的Linux技巧

Coolshell:应该知道的Linux技巧

閱讀本文約花費: 14 (分鐘)这篇文章来源于Quroa的一个问答《What are some time-saving tips that every Linux user should know?》—— Linux用户有哪些应该知道的提高效率的技巧。我觉得挺好的,总结得比较好,把其转过来,并加了一些自己的理解。 首先,我想告诉大家,在Unix/Linux下,最有效率技巧的不是操作图形界面,而是命令行操作,因为命令行意味着自动化。如果你看过《你可能不知道的Shell》以及《28个Unix/Linux的命令行神器》你就会知道Linux有多强大,这个强大完全来自于命令行,于是,就算你不知道怎么去做一个环保主义的程序员,至少他们可以让你少熬点夜,从而有利于你的身体健康和性生活。下面是一个有点长的列表,正如作者所说,你并不需要知道所有的这些东西,但是如果你还在很沉重地在使用Linux的话,这些东西都值得你看一看。 (注:如果你想知道下面涉及到的命令的更多的用法,你一定要man一点。对于一些命令,你可以需要先yum或apt-get来安装一下,如果有什么问题,别忘了Google。如果你要Baidu的话,我仅代表这个地球上所有的生物包括微生物甚至细菌病毒和小强BS你到宇宙毁灭) 基础 学习 Bash 。你可以man bash来看看bash的东西,并不复杂也并不长。你用别的sh…

Read More Read More

一文带你搞懂API网关

一文带你搞懂API网关

閱讀本文約花費: 19 (分鐘)前言 假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。 那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题: 每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。 如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名,另一方面是连接数的瓶颈,想象一下你打开一个APP,通过抓包发现涉及到了数百个远程调用,这在移动端下会显得非常低效。 每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。 另外还有一个问题,后端每个微服务可能是由不同语言编写的、采用了不同的协议,比如HTTP、Dubbo、GRPC等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工…

Read More Read More