GitHub 近两万 Star,无需编码,可一键生成前后端代码,开源项目

大哥大姐们哪位知道,GitHub 近两万 Star,无需编码,可一键生成前后端代码,开源项目
最新回答
寄信给风

2024-04-24 01:24:27

JeecgBoot 是一款基于代码生成器的 低代码 开发平台!前后端分离架构 SpringBoot2.x,SpringCloud,Ant Design&Vue,Mybatis-plus,Shiro,JWT,支持微服务。强大的代码生成器让前后端代码一键生成,实现低代码开发!

JeecgBoot 提供了一系列 低代码模块 ,实现在线开发 真正的零代码 :Online表单开发、Online报表、报表配置能力、在线图表设计、大屏设计、移动配置能力、表单设计器、在线设计流程、流程自动化配置、插件能力(可插拔)等等!

JEECG宗旨是: 简单功能由OnlineCoding配置实现,做到 零代码开发 ;复杂功能由代码生成器生成进行手工Merge 实现 低代码开发 ,既保证了 智能 又兼顾 灵活 ;实现了低代码开发的同时又支持灵活编码,解决了当前低代码产品普遍不灵活的弊端!

JEECG业务流程: 采用工作流来实现、扩展出任务接口,供开发编写业务逻辑,表单提供多种解决方案:表单设计器、online配置表单、编码表单。同时实现了流程与表单的分离设计(松耦合)、并支持任务节点灵活配置,既保证了公司流程的保密性,又减少了开发人员的工作量。

Jeecg-Boot低代码开发平台,可以应用在任何J2EE项目的开发中,尤其适合SAAS项目、企业信息管理系统(MIS)、内部办公系统(OA)、企业资源计划系统(ERP)、客户关系管理系统(CRM)等,其半智能手工Merge的开发方式,可以显著提高开发效率70%以上,极大降低开发成本。

1、服务注册和发现 Nacos

2、统一配置中心 Nacos

3、路由网关 gateway(三种加载方式)

4、分布式 http feign

5、熔断和降级 Sentinel

6、分布式文件 Minio、阿里OSS

7、统一权限控制 JWT + Shiro

8、服务监控 SpringBootAdmin

9、链路跟踪 Skywarking

10、消息中间件 RabbitMQ

11、分布式任务 xxl-job

12、分布式事务 Seata

13、分布式日志 elk + kafa

14、支持 docker-compose、k8s、jenkins

15、CAS 单点登录

16、路由限流

微服务架构图

输入图片说明

输出结果:

先看第一个打印语句,在Java中==这个符号是比较运算符,它可以基本数据类型和引用数据类型是否相等,如果是基本数据类型,==比较的是值是否相等,如果是引用数据类型,==比较的是两个对象的内存地址是否相等。字符串不属于8中基本数据类型,字符串对象属于引用数据类型,在上面把“abc”同时赋值给了st1和st2两个字符串对象,指向的都是同一个地址,所以第一个打印语句中的==比较输出结果是 true

然后我们看第二个打印语句中的equals的比较,我们知道,equals是Object这个父类的方法,在String类中重写了这个equals方法,在JDK API 1.6文档中找到String类下的equals方法,点击进去可以看大这么一句话 将此字符串与指定的对象比较。当且仅当该参数不为null,并且是与此对象表示相同字符序列的 String 对象时,结果才为 true。

注意这个相同字符序列,在后面介绍的比较两个数组,列表,字典是否相等,都是这个逻辑去写代码实现。由于st1和st2的值都是“abc”,两者指向同一个对象,当前字符序列相同,所以第二行打印结果也为true。

下面我们来画一个内存图来表示上面的代码,看起来更加有说服力。

内存过程大致如下:

答案是:在内存中创建两个对象,一个在堆内存,一个在常量池,堆内存对象是常量池对象的一个拷贝副本。

我们下面直接来一个内存图。

当我们看到了new这个关键字,就要想到,new出来的对象都是存储在堆内存。然后我们来解释堆中对象为什么是常量池的对象的拷贝副本。“abc”属于字符串,字符串属于常量,所以应该在常量池中创建,所以第一个创建的对象就是在常量池里的“abc”。

第二个对象在堆内存为啥是一个拷贝的副本呢,这个就需要在JDK API 1.6找到String(String original)这个构造方法的注释:初始化一个新创建的 String 对象,使其表示一个与参数相同的字符序列;换句话说,新创建的字符串是该参数字符串的副本。所以,答案就出来了,两个对象。

答案:false 和 true

由于有前面两道提内存分析的经验和理论,所以,我能快速得出上面的答案。==比较的st1和st2对象的内存地址,由于st1指向的是堆内存的地址,st2看到“abc”已经在常量池存在,就不会再新建,所以st2指向了常量池的内存地址,所以==判断结果输出false,两者不相等。第二个equals比较,比较是两个字符串序列是否相等,由于就一个“abc”,所以完全相等。内存图如下

答案是:true 和 true

分析:

答案:false 和 true

上面的答案第一个是false,第二个是true,第二个是true我们很好理解,因为比较一个是“abc”,另外一个是拼接得到的“abc”,所以equals比较,这个是输出true,我们很好理解。那么第一个判断为什么是false,我们很疑惑。同样,下面我们用API的注释说明和内存图来解释这个为什么不相等。

首先,打开JDK API 1.6中String的介绍,找到下面图片这句话。

关键点就在红圈这句话,我们知道任何数据和字符串进行加号(+)运算,最终得到是一个拼接的新的字符串。上面注释说明了这个拼接的原理是由StringBuilder或者StringBuffer类和里面的append方法实现拼接,然后调用toString()把拼接的对象转换成字符串对象,最后把得到字符串对象的地址赋值给变量。结合这个理解,我们下面画一个内存图来分析。

大致内存过程

所以,st3和st2进行==判断结果是不相等,因为两个对象内存地址不同。

这篇的面试题,完全就是要求掌握JDK API中一些注解和原理,以及内存图分析,才能得到正确的结果,我承认是画内存图让我理解了答案为什么是这样。画完内存图之后,得到答案,你确实会发现很有趣,最后才会有原来如此的感叹。