codingmiao 最近的时间轴更新 codingmiao 最近的时间轴更新 |
codingmiaoV2EX 第 582929 号会员，加入于 2022-05-27 09:19:04 +08:00 |
| 今天整了个活，用纯 http post 做了一个反向代理/内网穿透的工具
3 Java • codingmiao • 158 天前 • 最后回复来自 codingmiao
|
41 |
codingmiao 最近回复了
8 天前 回复了 hxzhouh1 创建的主题 › 云计算 › [求助] 新开的 oracle arm 主机没法使用 22 端口 |
啊，这么天选之人的么，直接注册完就开出 arm 的机器了，选的哪个区
@mikasa1024 哈哈，我也不是地理测绘专业的，我的第一任领导是搞 GIS 的，丢了本 arcgis js 的教程给我啃的，然后发现 arcgis 服务端一些不能满足需求的地方找开源方案去实现。所以按我的经验来看，你可以找一本专业的 gis 方面的前端框架的书来看，具体什么框架根据你们公司的技术栈来确定，现在主流的有 arcgis-js 、mapbox-gl-js 、openlayer 、leaflet 等等，通过学习框架了解下 gis 大概能做什么事情，然后去看看做这些事涉及到的技术栈去深入学习吧。
@gotheway GIS 项目而且是 java 体系的话，我推荐 postgis 做为数据库、jts 做为后端空间计算框架，其它就是传统的 web 框架了，springboot 全家桶什么的，以及基于 springboot 体系做的 ruoyi 等。
另外数据量大的话，极度不推荐去用 geoserver ，虽然是 java 体系而且功能很全，但一板一眼的去按 OGC 标准来做实现，性能极差。基于 jt 或者 geotools 等去开发需要的功能，轻量化、定制化的去做比用 geoserver 舒服很多。我搞了一些基于 jts 的小工具出来，但比较懒没去好好写文档 https://github.com/codingmiao/giscat
另外数据量大的话，极度不推荐去用 geoserver ，虽然是 java 体系而且功能很全，但一板一眼的去按 OGC 标准来做实现，性能极差。基于 jt 或者 geotools 等去开发需要的功能，轻量化、定制化的去做比用 geoserver 舒服很多。我搞了一些基于 jts 的小工具出来，但比较懒没去好好写文档 https://github.com/codingmiao/giscat
78 天前 回复了 beiwarm5 创建的主题 › 商业模式 › 为什么所有的网站都喜欢搞月付订阅制呢 |
商人不就这样么，gpt 面向用户的时候，月付制更赚所以 GPT4 包月，给第三方 API 调用的时候他敢给月付么，又变成按量计费了。
说起这个，想起来国服魔兽世界的点卡了，年轻时有时间整天整夜的玩盼着出月卡，年纪大了没时间玩了，嘿嘿月卡来了点卡取消，当时网易也不当人，大大方方承认点卡运维成本高，再卖一波情怀，大家也能谅解，偏偏要搞什么张栋出来嘲讽玩家，搞一堆水军洗地，是真的蠢。
说起这个，想起来国服魔兽世界的点卡了，年轻时有时间整天整夜的玩盼着出月卡，年纪大了没时间玩了，嘿嘿月卡来了点卡取消，当时网易也不当人，大大方方承认点卡运维成本高，再卖一波情怀，大家也能谅解，偏偏要搞什么张栋出来嘲讽玩家，搞一堆水军洗地，是真的蠢。
86 天前 回复了 grayfox 创建的主题 › 程序员 › 像 js(node)、 Python 作为服务端部署到生产环境，怎么保证源码的安全性的？ |
其实 java 或者其它编译后的语言也并不安全，现在所谓的 jar 包保密方案，也只是给文件加个密，然后 Java Agent 启动时解密，但是随便丢个 arthas 之类的工具上去，从内存中拿字节码反编译出来根本防不住。
所以哪有什么绝对安全的方案，只要你的软件价值小于别人攻破你的成本就行了
所以哪有什么绝对安全的方案，只要你的软件价值小于别人攻破你的成本就行了
105 天前 回复了 karottc 创建的主题 › Java › 分享一个 Springboot + GraalVM 对反射的处理方式 |
我是 java -agentlib:native-image-agent=config-output-dir=META-INF/native-image -jar xxx.jar 先跑起 jar 包来，然后跑测试用例，测完后 reflect-config.json 这些也自动生成出来了，优点是不用去动原来的代码，缺点是测试用例覆盖不全的话可能会出问题。
118 天前 回复了 pykerzhang 创建的主题 › Linux › 在这个容器化成为标准的时代，如何评价运维还在用二进制源代码方法安装软件？ |
所以现在把数据库丢容器里是否合适有定论了么，会损失百分之几的性能
118 天前 回复了 darkings90 创建的主题 › 程序员 › 你们平时看博客吗?你们觉得哪个平台的博客质量最高 |
博客园的博客质量很高，但是在博客园码博客真的难受啊，别的地方都可以直接屏幕截图然后 ctrl+v 贴进去，博客园还要先上传图片再引入图片，文本编辑器也感觉是十多年前的风格，有没有插件可以优化一些写博的体验啊？
118 天前 回复了 HOMO114514 创建的主题 › 程序员 › 分享一些 500 强信创数据库的有趣故事吧 |
@HOMO114514 这顿操作没看明白，为了遵守 GPL 开源，但是所谓自主可控后为什么就不需要遵守 GPL 了？那别人用的过程中发现他基于 GPL 的代码痕迹，那他不完蛋了。。
121 天前 回复了 javak 创建的主题 › Java › Java hello world 确实就要占用 30M |
实验 1 、直接原生 java -jar 跑
我 win10 占内存 36m ，同事的 mac(arm 架构)只有 19m ，win10 简单加几个参数能压到 20 多 m
java -Xmx5m -Xms1m -XX:MaxMetaspaceSize=1m -XX:+UseSerialGC -XX:CompressedClassSpaceSize=1m -Xss512k -Xint -jar nativedemo-1.0-SNAPSHOT.jar
然后拉一下内存使用情况：
Memory used total max usage GC
heap 22M 252M 3986M 0.57% gc.g1_young_generation.count 2
g1_eden_space 4M 62M -1 6.45% gc.g1_young_generation.time(ms) 14
g1_old_gen 12M 184M 3986M 0.32% gc.g1_concurrent_gc.count 0
g1_survivor_space 6M 6M -1 100.00% gc.g1_concurrent_gc.time(ms) 0
nonheap 28M 31M -1 90.20% gc.g1_old_generation.count 0
codeheap_'non-nmethods' 1M 2M 5M 26.09% gc.g1_old_generation.time(ms) 0
metaspace 19M 20M -1 98.64%
codeheap_'profiled_nmethods' 3M 3M 117M 3.27%
compressed_class_space 2M 2M 1024M 0.22%
codeheap_'non-profiled_nmethods' 838K 2496K 120028K 0.70%
mapped 0K 0K - 0.00%
direct 4M 4M - 100.00%
mapped - 'non-volatile memory' 0K 0K - 0.00%
我拿 arthas 拉的，arthas 注入进来后内存有膨胀了一些，你看占用大头都在 metaspace 、codeheap 以及 old_gen 上，这 hello world 又没 new 啥对象，old_gen 肯定是一些 static 的对象了，这就说明了这些内存是基本消耗，不会随着你的应用增长。
实验 2 、native 打包
<build>
<plugins>
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<version>${native.maven.plugin.version}</version>
<executions>
<execution>
<goals>
<goal>native-image</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>${mainClass}</mainClass>
</configuration>
</plugin>
</plugins>
</build>
这个打完在 x64 的 kali 下运行只占 8m ，在 arm 架构下还会更低。
在复杂场景下，实验 1 以及诸多大厂的生产环境都证明了 java 的稳定可靠，实验 2 则说明如果确实需要在物联网终端等内存极其苛刻的场景下使用，native 也能胜任。所以 Java 内存没救了？你要救什么？
我 win10 占内存 36m ，同事的 mac(arm 架构)只有 19m ，win10 简单加几个参数能压到 20 多 m
java -Xmx5m -Xms1m -XX:MaxMetaspaceSize=1m -XX:+UseSerialGC -XX:CompressedClassSpaceSize=1m -Xss512k -Xint -jar nativedemo-1.0-SNAPSHOT.jar
然后拉一下内存使用情况：
Memory used total max usage GC
heap 22M 252M 3986M 0.57% gc.g1_young_generation.count 2
g1_eden_space 4M 62M -1 6.45% gc.g1_young_generation.time(ms) 14
g1_old_gen 12M 184M 3986M 0.32% gc.g1_concurrent_gc.count 0
g1_survivor_space 6M 6M -1 100.00% gc.g1_concurrent_gc.time(ms) 0
nonheap 28M 31M -1 90.20% gc.g1_old_generation.count 0
codeheap_'non-nmethods' 1M 2M 5M 26.09% gc.g1_old_generation.time(ms) 0
metaspace 19M 20M -1 98.64%
codeheap_'profiled_nmethods' 3M 3M 117M 3.27%
compressed_class_space 2M 2M 1024M 0.22%
codeheap_'non-profiled_nmethods' 838K 2496K 120028K 0.70%
mapped 0K 0K - 0.00%
direct 4M 4M - 100.00%
mapped - 'non-volatile memory' 0K 0K - 0.00%
我拿 arthas 拉的，arthas 注入进来后内存有膨胀了一些，你看占用大头都在 metaspace 、codeheap 以及 old_gen 上，这 hello world 又没 new 啥对象，old_gen 肯定是一些 static 的对象了，这就说明了这些内存是基本消耗，不会随着你的应用增长。
实验 2 、native 打包
<build>
<plugins>
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<version>${native.maven.plugin.version}</version>
<executions>
<execution>
<goals>
<goal>native-image</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>${mainClass}</mainClass>
</configuration>
</plugin>
</plugins>
</build>
这个打完在 x64 的 kali 下运行只占 8m ，在 arm 架构下还会更低。
在复杂场景下，实验 1 以及诸多大厂的生产环境都证明了 java 的稳定可靠，实验 2 则说明如果确实需要在物联网终端等内存极其苛刻的场景下使用，native 也能胜任。所以 Java 内存没救了？你要救什么？
Select Language