首页 文章 精选 留言 我的

精选列表

搜索[collection],共2248篇文章
优秀的个人博客,低调大师

细述 Java垃圾回收机制→Java Garbage Collection Introduction

计划写一个介绍Java垃圾回收基础的系列文章,共分四部分: Java垃圾回收简介 Java垃圾回收器是如何工作的? 各种类型的Java垃圾回收器 Java垃圾回收的监控和分析 本文是这个系列的第一篇文章,这篇文章将会介绍一些基本术语,如:JDK,JVM,JRE,HotSpot VM,以及理解JVM的架构和Java堆内存结构。在开始学习Java垃圾回收机制之前确实有必要了解一下这些基本东西。 关键的Java术语 Java API–一个帮助程序员创建Java应用的打包好的库集合 Java Development Kit(JDK)–一个使得程序员能够开发Java应用的工具集合 Java Virtual Machine(JVM)–JVM是一个抽象的计算机。Java程序是针对JVM规范写的。JVM是根据不同的操作系统平台实现的,它将Java指令翻译成对应平台上的指令,并执行。这样Java程序能够达到平台独立性。 Java Runtime Environment(JRE)–JRE由一个JVM的实现和Java API组成。 Java HotSpot虚拟机 每个JVM的实现在对垃圾回收的原理的实现方式上会有一些不同。在收购SUN之前Oracle有JRockit JVM,收购SUN之后有了HotSpot虚拟机。目前Oracle同时维护了这两个虚拟机,并宣称将来会将两个虚拟机合并。 HotSpot虚拟机是Oracle标准版平台的核心组成部分。在本垃圾回收系列文章中我们将通过HotSpot虚拟机来了解垃圾回收的基本准则。 JVM 架构 下面的这幅图概括了一个JVM中的主要组成。在JVM架构中,堆内存和垃圾回收器这两个部分和垃圾回收相关。堆内存是运行时用来存储实例对象的数据空间,垃圾回收器运行在堆内存上。现在我们大概知道它们是怎样的一个工作模式。 Java 堆内存 在Java的内存模型中,最重要的是要了解堆内存的概念。运行时的Java实例对象存储在堆内存空间中。当一个对象不再被引用了,它变成可被从堆内存中回收空间。在垃圾回收的过程中,这些对象将被从堆内存中清除,同时它们的空间也就被回收了。堆内存的空间主要分成了三部分, 年轻代 a, Eden区(所有实例在运行时最初都分配到eden区中) b, S0 Survivor Space(老一些的对象被从eden区移动到S0区,其实是eden区中的对象经过一次对eden区的Young GC还存活的对象被移动到S0) c, S1 Survivor Space(再老一些的对象被从S0区移动到S1区,其实是在Young GC过程中S0区已满,则会将eden区中还存活的对象和S0区中的存活对象移动到S1区中) 老年代(经过S0,S1中几轮迭代后还存活的对象被提升到老年代) 永久代(包含一些元数据像类、方法等等 永久代空间在Java SE8特性中已经被移除 作者:anonymoussf 来源:51CTO

优秀的个人博客,低调大师

CL_OBJECT_COLLECTION了解一下

文章标题的incident含义:在企业级软件领域里,当客户使用软件提供商的软件,遇到各种问题或故障,可以使用专门的工具,向软件供应商寻求帮助。我们通常称这种工具创建的帮助请求(Support Request)为incident. 今天这篇文章无关具体的技术。Jerry最近使用微软Azure云平台时遇到一个问题,通过Azure提供的Support工具向微软提交incident的过程中,感叹自己十多年来一直是修bug的命,这次终于翻身了,由我给另一家软件公司报bug,体验了一回当上帝的感觉。 我在SAP这些年,一共处理过317个客户incidents(当然并不是所有的都是Jerry修复的,包括我分析后转手到其他部分的也算). 我们Commerce Cloud团队使用Azure提供的Function create API在Azure上创建Lambda Function,过程中遇到一些问题,详见Jerry之前的文章:SAP ABAP应用服务器的HTTP响应状态码(Status Code). 在排除了问题不是我们消费端代码引起之后,我开始给Azure报incident. 虽然Azure的字面意思是天蓝色,但Jerry打开的Azure页面全是下图这种纯黑色背景,只是因为我换了一个黑色主题。 新建一个支持请求(Support Request),类型选择为Technical: 选中之后,Subscription就自动填充为我当前这个用户的订阅ID了。大家可以把Azure Subscription的作用类比成SAP Cloud Platform的Global Account. 然后指定遇到问题的Service类型,和具体的Resource名称。Subscription,Service,Resource这三个字段都是联动的下拉菜单。 Service,Problem type和Problem subtype这三个联动的下拉菜单,共同扮演的角色,类似给SAP产品报incident时需要维护的Application Component. 下图是SAP Application Component的树状关系图。 Jerry个人觉得Azure这种多层级联式下拉菜单的做法,为用户免去了记忆component ID的负担;但作为程序员,我个人还是更喜欢SAP这种通过树形结构维护component的方式。 回到Azure Portal,维护好了问题类型和描述信息后,Azure根据这些信息自动从其后台检索出相关的推荐解决方案。我浏览了一下,发现并不能解决我遇到的问题,于是点Next继续: 这里可以维护明细信息和上传附件。我当时将重现问题的步骤,Postman请求的payload,我的分析,包括我搭建的jMeter等信息全部写到一个PDF文件里了,总共8页,添加到附件里。 然后是选择故障的紧急程度,Azure有四档紧急程度可选:Critical,Urgent,Moderate和Minimal. 而对应的SAP里的术语叫Priority(优先级),SAP incident的优先级也分四档:Very High,High,Medium和Low. Jerry处理过的317个客户incidents中也不乏Very High的,当时处理时承担的压力,至今思之仍觉得后怕。 尽管明白“程序员何苦为难程序员”的道理,我还是选择了最高级别的Critical impact,享受一次7×24小时的服务。留下自己的手机以供联系。 最后点击Next就能成功创建Support Request. 因为我们享受的Support Plan级别是Premier,在这个级别之下,理论上15分钟之内就会收到响应。 果然,几分钟之后Jerry就收到了一个用Teams发起的会议请求: 我心想,微软真是动作神速啊,这么快就派出工程师准备和我一起在线调试了吗?本来我正在吃饭,只得放下碗筷回到电脑面前。 登入Microsoft Teams参加了会议我才知道,这个会的目的首先是,Azure Support工程师确认他们对我附件PDF里描述信息的理解是否正确,然后讨论这个incident的Severity是否应该从Critical降成Urgent. 工程师们详细询问了我们组对这个API的使用场景,以及当前Azure上是否存在已经上线的应用。最终我也同意了这个降级请求,毕竟微软这套衡量incident优先级的标准和SAP类似,都是按照Business Impact来界定的。 这个会刚结束,我手机又接到一个号码显示为美国的来电,一位自称是微软Critical Situation Manager的女士,询问我对刚才和Azure Support工程师开会的体验,以及对这个incident优先级的降低是否有异议。 整体来讲,我对这次向Azure提交incident的体验很满意,无论是响应速度还是同Azure Support工程师及Critical Situation Manager交谈下来感受到的专业程度,都给我留下了深刻的印象。 最后还是再来回顾一下SAP从业者们最熟悉的如何给SAP产品报incident的工具吧。 在SAP Cloud for Customer about菜单里集成了提交incident的功能: 提交界面比较简洁,维护标题和问题详细描述,上传附件。 当然也能使用最统一最通用的SAP One Support Launchpad: https://launchpad.support.sap.com 同Azure一样,SAP Support Launchpad也鼓励用户,在实际提交incident之前,首先去Knowledge Base里查询有无相关线索和解决方案。 不搜不知道,一搜吓一跳,原来HTTP 400 bad request确实是一个普遍问题,在SAP领域也一共存在1400多个相关note和讨论: 如果觉得这些搜索结果没有帮助,点击Submit an Incident. SAP incident也分4档不同的优先级: 关于上图的必填字段Component,如果是基于ABAP的SAP产品,很容易在开发包的Application Component字段找到这个值: 如果是SAP Cloud Platform的某个模块遇到了问题,对应的Application Component在SAP Help上能查到: https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/08d1103928fb42f3a73b3f425e00e13c.html?scp-env=Cloud%20Foundry 回到Jerry给Azure报的那个incident,目前还在处理过程中。对此我也非常能理解,这种不能100%重现的故障是最让程序员头疼的。 我想起之前处理过的一个SAP CRM IBASE问题,应用运行时有一定概率会出现运行时Dump,但不是总能重现。 当年Jerry还在SAP成都研究院CRM开发团队工作,负责SAP CRM IBASE的维护。 当时给我报bug的同事也坦言,这个Dump不能稳定重现。如果试一次是正常工作的话......那就多试几次,直到出现Dump为止...... 最让我抓狂的是,如果单步调试,这个故障100%无法重现。换句话说,我多年积累下来的在文章SAP错误消息调试之七种武器:让所有的错误消息都能被定位里介绍的ABAP单步调试经验,在这个问题的分析上完全派不上用场。 幸运的是我最终通过自己的分析,写了一个脚手架程序,通过该测试程序能够100%重现Dump. 既然能稳定重现,剩下的任务就轻松了,通过单步调试就能找到问题根源。 这个问题折腾了我整整两天,解决完问题之后,我也做了复盘,分析自己为什么会花掉这么多时间。我把我的经验教训,以及最终通过分析找到能够稳定重现问题的突破口,写成了一篇SAP社区博客: My Tips about how to handle complex and tricky issues https://blogs.sap.com/2014/05/01/my-tips-about-how-to-handle-complex-and-tricky-issues/ 我把自己采取的问题定位方式归纳命名为“最小系统法”。本世纪初,国内电脑界流行DIY,大家分别购买自己中意品牌的电脑零配件,自己动手组装,运行时经常出现无法开机(俗称“点不亮”)的情况。电脑发烧友们习惯通过“最小系统法”去逐一排查,最终找到出故障的配件。 我处理那个IBASE bug因为无法单步调试,仅能通过ST22 Dump里的静态信息进行分析,所以我也使用了“最小系统法”,分析出可能引起故障的子模块,再写测试程序运行这些模块,逐一验证我的猜想。 关于我提交的这个不能稳定重现的Azure incident,我也会持续关注。最后祝我的同行,处理这个incident的微软工程师好运。感谢阅读。 本文来自云栖社区合作伙伴“汪子熙”,了解相关信息可以关注微信公众号"汪子熙"。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册