V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Aresxue  ›  全部回复第 1 页 / 共 22 页
回复总数  436
1  2  3  4  5  6  7  8  9  10 ... 22  
9 天前
回复了 wtotal 创建的主题 Java 如何提高 maven 打包速度?
分本地还是线上,本地环境 3 楼的策略你能搞完绝对够用了,线上环境就要复杂的多了,maven 本身就有一些调优参数。
21 天前
回复了 fkdog 创建的主题 Java 看到了一个极其中二逆天的国内开源框架
不用就行了,说实话对开源来说这个算是屁大点事,Linus 以前还天天 fuck NVIDIA 呢。
不过这框架我还真用过,语法思路问题不大(抄的 mybatis-plus ),但是明显作者技术功力不到家,对底层序列化还有很多地方的处理都有 bug ,另外和 spring-data-elasticsearch 的互兼容性做的比较差,导致最后还是弃用了,我想要的其实更多的还是一个基于 spring-data-elasticsearch 的语法糖框架,毕竟 spring-data-elasticsearch 的扩展和细节处理已经有很多年的积累了。
51 天前
回复了 vyuai 创建的主题 Java 大佬们, 三层架构先写哪个层比较好呢
Controller -> Mapper -> Service ,外部定义越早越好,对接的前端和其它三方可以直接查看 Controller 申成的接口文档,Mapper 其实主要指的是底层模型,这块是需要和老板/产品达成一致的,Service 指的是内部服务一般来说调整更自由,不管是改名字还是职责还是拆分都好说一些。
71 天前
回复了 LazYFire 创建的主题 程序员 能不能推荐一下自己在用的 AI 编程插件
Copilot 体感最好,但我日常办公是天然和外网联通的,而且网速非常流畅,而且使用的公司购买的 Copilot 付费版本。
1.一般是对外的接口层( http 、rpc 、mq )是需要一定避免 Map 的,内部方法合理即可不需要一定避免;
2.针对你这个 case 非要搞可以搞个 List<xxxCount>对象,意义聊胜于无,从性能来说 Map 还更好些。
115 天前
回复了 cookii 创建的主题 Java 记录一次修复 Spring Framework Bug 的经历
属于滥用拦截器了,这个场景写个 Adapter 就解决了,addToken 方法里面肯定还有 json 序列化和反序列化的开销,Adapter 设计合理点还能把这部分开销优化掉。
你这个就适合 go ,确实不适合 java ,但和 java 也确实没啥关系了
这还告诉我们写代码的不要无脑 copy ,应该要按需引入相应的功能。“若无必要,勿增实体”,做到这一点会少踩很多坑。
171 天前
回复了 liubsyy 创建的主题 Java 一键修改 JAR 包内文件: JarEditor 插件详细指南
@liubsyy 我的意思是你的发布物是什么样的,原先不依赖的新三方库我理解就是导出一个新的 jar 包就叫它 newbiz.jar 好了,把这个 jar 包在容器里面替换掉原有的 biz.jar 然后重启 java 进程就生效了,新依赖三方包的话新的三方包你是会直接打到 newbiz.jar 中还是说是分开的,除了替换原有的 biz.jar 以外还需要再上传一个 third.jar ,值得注意的是这个 third.jar 可能以前已经有低版本的了这里再引入一个会面临业务里面会遇到的钻石依赖问题。
171 天前
回复了 liubsyy 创建的主题 Java 一键修改 JAR 包内文件: JarEditor 插件详细指南
蛮不错的插件,就是编译可以再扩充一些,一个是可以指定电脑本地的其它 jdk ,甚至一些三方的反编译和编译库像 cfr 、Procyon;另一个是我没看到对三方库的处理,指原不在我当前应用中的三方包但我本次修改需要使用的三方库,这块处理也确实会比较麻烦但在这个魔改 jar 的场景里面出现的概率却并不低。
183 天前
回复了 ODESZA 创建的主题 上海 朋友收到病危通知书,撑不过本月,人各有命
好好坏坏总归是自己的选择,但妈妈要更可怜一些,如果就这一个孩子以后只能一个人孤零零地走向生命的终点。
190 天前
回复了 diagnostics 创建的主题 Java 有多少人还在用 Maven 构建项目?
1.xml 可读性主要是不够简洁,版本管理和子模块管理这俩本来就没有分开的必要,gav 一共就三个维度;
2.使用姿势有问题,把 revision 和 relativePath 玩明白就好了;
3.还是姿势问题;
4.了解下阿里的 amaven 还有开源的 maven daemon ;
207 天前
回复了 Dongxiaohao 创建的主题 Java 关于读写分离的问题
@Dongxiaohao 代码不多的话加个注解也是个蛮简单的方式,要是想作为一个可以面向几十个应用的功能就可以像我说的做个二方包在里面写一些路由逻辑,这个东西的好处就是对 sql 语法没有任何要求,需要注意的是潜在的事务问题(跨数据源),你使用时注意点。
209 天前
回复了 Dongxiaohao 创建的主题 Java 关于读写分离的问题
@JackCh3ng ShardingSphere-JDBC 不兼容原有的配置格式,而且会把整个 Datasource 和 Connection 都换成自己,不需要分表的 sql 也会走它的拦截分析,很多语法都不支持,同时还需要手动指定不需要走分表的单表有哪些,动态数据源那里不用它的 starter 而是复用它的 DynamicDatasource ,自己写个配置解析 sql 然后做路由不需要业务代码变更一行而且没有任何 sql 兼容性问题
210 天前
回复了 Dongxiaohao 创建的主题 Java 关于读写分离的问题
多数据源简单一点,目前来看 https://github.com/baomidou/dynamic-datasource 这个写的还不错的,不建议 ShardingSphere-JDBC 它目前的实现入侵性太强,需要比较重的分库分表的场景才更合适。
第一确实存在这样的业务诉求,这是很合理的,别被其它人绕晕了;
第二实现方式最好不是自定义一套注解,理解成本很高,具体很好的实现方式一下子没想好,最好是可以和原来搭配使用,比如 SpelNotNull 就可以改成 @NotNull + @When("enableVoice == true"),上面只是举个例子;
第三注意这里存在潜在的性能问题对于高并发接口来说这些校验最好是直接写在业务代码中的,但是绝大多数接口并不是什么高并发接口,这个东西的用处应当是用来快速实现校验功能,当这个接口的 QPS 要求发生变化时再重新设计实现,当然更多接口可能永远都都不到这一步。
因为线程是非常宝贵的资源,这个设计主要就是保证线程资源的最大化利用。

在更早的时候操作系统的可支撑线程数是非常有限的,单机的性能也很弱,但随着时代的发展其实这个思路已经并没有那么适用了,在实际中很多都是把核心数和最大线程数设为一致。更有甚者 tomcat 直接修改了这一策略,在没有可用线程时它会优先开启一个新的线程直至最大线程数,然后才会堆积请求。如今 tomcat 的这种思路更为流行比如 Druid 的连接池中的最小连接数和最大连接数也是这个逻辑。

当然随着虚拟线程的流行,线程的限制将会荡然无存,线程池也会逐步退出历史舞台,最终只服务于很少的一些场景。
技术架构、业务架构、应用架构、数据架构
你问他你要哪一种
好绩效取决且仅取决于你的直属实线 leader 。
1  2  3  4  5  6  7  8  9  10 ... 22  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1836 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 16:20 · PVG 00:20 · LAX 08:20 · JFK 11:20
Developed with CodeLauncher
♥ Do have faith in what you're doing.