2025-05-29 23:44
@liugz templateByString 与 template文件取字符串的区别可能是回车符不一样，与编写有关。文件里面一般宽敞回车符就会产生回车，java里面写sql字符串拼接一般不会把回车符放入。 这个很好验证的，把他们的取值都打印出来看下就好了，或者debug进入看下取到的字符串就行，调试一下就找到问题
2025-05-29 11:53
没有处理，可能是Druid拦截了。可以用Db.find方法直接传入sql试试哪里被拦截了。
PS 阿里云数据库我记得默认是1G参数大小来着？还限制查询数量了啊，这个是第一次了解到。。。
2025-05-23 22:56
@sbw Db.deleteByIds("user_role", "user_id, role_id", 123, 456); 是这样用的，不校验传入参数与表主键数量;
对应的sql是：DELETE FROM user_role WHERE user_id=123 AND role_id=456
注意是 AND 条件 ，不是OR 条件。
Model 是数据库表的映射对象，拼接sql前 校验ids数量没毛病。两个入口功能不一样。
PS：我们项目有自己封装一个D.java类，里面扩展了Db类的用法，其中就有传入一个ids list参数批量删除的（list参数是因为json传入的对象）。自己的类工具可以随意扩展贴合业务。
2025-05-22 10:09
@星矢 我们也没有使用这个类了，使用BaseController 拦截了KV等取值位置，改用HuToolJson了。再后来发现我们只需要简单的json字符串解析，又手搓了一个简单json解析100行左右代码，map用KV类代替，搭配kV的getAs方法，还非常好用。。。无反射性能还嘎嘎高。。。
2025-05-14 19:04
@zzutligang 我使用的是 社区首页 右侧那个 JFinal demo for maven 5.0.0
2025-05-14 16:58
@zzutligang 搜索html模板的函数，使用全局搜索 #define layout()，其他函数名也一样 #define + 名称就可以找到 PS：src/main/webapp/common/_layout.html
2025-05-13 14:31
@本人纯属虚构 configConstant配置的是钩子 Function func ，是在Config.configJFinal(jfinalConfig); 之后执行的initActionMapping();，你读下源码就知道了。 并且自定义的ActionMapping里面可以区分哪些是需要正则表达式处理的Action，这样可以单独把他们提到一个list中，提前把路由字符串Pattern对象化，list 匹配时效率高。先map get 取Action，没有再去 list里面 Pattern对象for匹配就搞定了，代码少效率高，兼容JF标准写法（如果全是需要正则的路由，可以不要map取值了）
2025-05-13 13:29
@zzutligang 你这个信息也没有异常的表象。152是说明你们java应用服务器 CPU线程的性能也就这些了druid设置再大也没意义。目前不知道你这是啥原因，还是得压测进行定位问题，我们2H4G的小云服务器都能压住1500的并发冒烟，你这32H64G不应该
2025-05-12 19:32
PS：https://jfinal.com/doc/3-4 参数提取后 可使用 - 拼接起来，供Controller的getPara(0)，getPara(1) 调用
2025-05-12 19:22
JF默认不支持这样的路由，里面就是map的get高效key匹配。
扩展支持：
方案1：自定义ActionHandler，里面按需要的业务进行匹配url
https://jfinal.com/doc/2-7
configHandler 》 me.setActionHandler
（推荐）方案2：设置扩展 ActionMapping，按自己业务进行匹配url
https://jfinal.com/doc/2-2
configConstant 》me.setActionMapping 》继承ActionMapping 重写getAction 方法支持自己的业务。 具体的业务实现代码，可以问AI 上面字符串匹配与参数提取方式，会给出正则表达式实现
2025-05-08 13:42
@zzutligang 还是得压测一下，连接池数太大也够呛，CPU也忙不过来。。。看你服务器内存够大，多用下缓存工具，像下拉框等数据用缓存就比较好。Redis能上的也上下性能是真强
2025-05-08 09:06
32H62G服务器，用户大约5千人，这个也需要看情况，是否同时使用的场景，是否一个页面打开会请求多个需要数据库连接的业务。
如果是5千人同时使用，那100个数据库连接明显不够使用。比如5千个获取数据库连接的请求，同时只有100个在操作了，那还有4900个在等待了。 一个请求比如用1秒，得一分钟左右才能处理完，等待都超时了或全卡主了。
实际情况可能比这个时间还要长，得用压测看下实际情况。Arthas CPU火焰图可以看见占用的时间。
上面sioui说的也是一个问题，数据库是自安装的还是云数据库服务，自安装的需要配置连接数，如果连接数比java这边少肯定是不行的，连接溢出了，druid设置的最大连接数也没意义。或数据库设置的超时数比druid设置要小，也不行。
排查的话，就晚上（客户不用的时候）用Arthas CPU火焰图监控开启，jmeter编写一个模拟的业务流，用系统里面的用户登录模拟业务进行访问压测。
2025-04-28 22:11
#@_paginate()是自定义的吗？ 找到定义的模板函数位置，看下有参数可配置没有。
官网有#pageList() pageSize参数
http://doc.jpress.cn/development/template/template_command.html#page-%E7%9A%84%E4%BD%BF%E7%94%A8
2025-04-28 13:06
@canca 不影响，我们线上也有 Tomcat 项目，日志应该是让运维关了。开发时会提示忽略就行
