2020-06-15 20:31

@穿越123 这个锁,只会在 cacheData 为 null 时被使用,所以对性能不会有任何影响

它的作用是,在 cache 中的数据还未被填充时,如果大量并发请求涌来,会产生雪崩,也就是说,大量请求同时看到这个 cacheData 为 null, 进而同时去查数据库

如果是较耗时的查询,这个时候数据库一般会就崩掉

而这个锁就保障了,cacheData 为 null 时,只有一个线程允许许去查询数据库,其它的等待,而等待的线程被唤醒时,cache 中的数据已填充好,就不必去查询数据库了


要写好高并发多线程代码对基本功要求比较高。 jfinal 源码中有大量精心编写的代码,是提升技术的绝佳资源

但可惜的是,认真读源码的同学并不多

2020-06-15 20:15

@zzutligang 当前比较知名的基于 jfinal 的微服务框架 jboot :
https://gitee.com/fuhai/jboot

2020-06-14 20:01

异常提示:
public method not found: java.util.ArrayList.get(null)

get 方法中的参数值为 null,确保这个值不为 null,多试试

2020-06-14 19:59

@tctc4869 将代码拿走,直接用上即可

2020-06-14 19:52

此外,我并不看好现有的微服务技术体系,成本高、复杂度高。

因此,带头搞微服务公司已经在开始弃用微服务,在开始搞宏服务,也就是在回归成本更合理的老模式:
https://www.infoq.cn/article/o465WFwDXg3mw3I8T3Ae

如果真要搞微服务, kubernetes / k8s 容器技术才是未来的方向,成本低,效率高,可以越过现有 spring 整合的那套微服务技术栈

最后,IT 这个行业服从于 幕律分布 规律,简单来说就是同一赛道第一名到第三名将占据 95% 以上的份额,其它则只能勉强活着

这也就意味着,这个行业绝大多数企业都是中小型规模,也就意味着它们的业务根本没有多高的微服务需求,弄个简单的项目拆分 + 集群就性能过剩了

但很多开发者一味追逐微服务,最后只能吃力不讨好,失败收场。 花费精力学习的大量知识也将被快速淘汰

技术 "品位" 很重要,注意这里的 "品位" 中的 "位",不是 "味" 道的 "味"

2020-06-14 19:38

@大川 jfinal 是 web + orm + aop 框架,而微服务分布式的范畴,两者在本质上并无关系

所以,你相当于是在问 spring 是否适合微服务。实现微服务的是 spirng 整合的那一套第三方的东西,而并不是 spring 自身

所以,jfinal 是否适合微服务分布式开发这个问题本身是不存在的,因为 jfinal 根本就不涉及微服务的事情。

jfinal 是 web + aop + orm 框架,适合的领域自然是 web 项目,需要操作数据库的项目。

2020-06-14 18:10

@tctc4869

MultipartRequest mp = new MultipartRequest(request);
List files = mp.getFiles();

2020-06-14 14:42

@tctc4869 再加一行代码:
isHandled[0] = true;

2020-06-13 18:14

如果用的是 DruidPlugin, 重连是自动的,你在 finally 块中 stop() 了,这会连整个插件都不能用,肯定是不可行的

你要的是重连,而不是 stop() 关闭 ActiveRecordPlugin 让它不可用

2020-06-13 18:13

在 YourJFinalConfig 中的各个方法中添加断点,按 F6 执行断点,看是哪一步慢了

定位瓶颈是关键

目前你给的信息量是猜不出来的,我估计是你的 mac 与 windows 环境不同,就 jfinal 自身来说,这两个操作系统对性能的影响是没有的

2020-06-12 16:39

Aop.get(...) 一定是可以的

你没说出到底是什么问题,有什么异常被抛出吗?

2020-06-12 15:27

这个是第三方依赖项目 cos 的改进,该项目不属于 jfinal

只要升级 cos 到是高版本 2020.4 就可以了,即便不升级的话在 jfinal 下也是安全的,因为 jfinal 默认已经阻止了对于 .jsp 文件的直接访问

2020-06-12 11:43

补充一下这里的关键:
1:你修改的是 resources/static 下的 html 静态资源
2:web 服务读取的是 target/static 下的 html 静态资源
3:IDEA 没有打开自动编译,造成 web 服务读取到的并不是最新修改后的版本

这个是 IDEA 的特征

2020-06-12 11:41

@spring0563 html 等静态资源不存在热加载这一说,本身就是实时生效的

你放在 resources/static 这个目录下面未实时生效,应该是 IDEA 的自动编译未打开,从而修改以后在 target/classes/resources 下面的相应拷贝并未发生变化

这个问题肯定是与 jfinal 无关的,IDEA 默认不开启自动编译,从而造成误解