重装战姬各职业武器的能量获取效率解析

重装战姬 中各种武器的能量获取大家知道是怎么样的呢各个武器的效率是不是一样的呢下面我为大家带来各职业武器的能量获取效率解析,一起看看吧

首先，是单挑情况下的能量获取排行

No1 火炮武器(爆破) 且蓄力>连发。10分

No2 狙击武器 蓄力≈连发。8分

No3 重型近战 重型近战基本上攻击速度是1。5分

但这里有两个例外。一个是我一直强调攻速05的怪雨霰dq，7分。一个是高攻速的电锯，1分。

No3 重型盾牌 攻速全部为1。5分

No4 轻型盾牌 攻速基本为2 。3分

No4 投射武器 连发≈蓄力。3分

No5 轻型近战，轻型q械，重型q械。1-2分

但是，这里面每个武器打完一场花的时间，有的是十几秒，几十秒，有的是几分钟。而实战里，你的队友是会和你抢能量的，抢怪打。这就导致有些看起来能量获取效率很高的武器在实战中表现大打折扣。而且，这版本的近战会比远程厉害很多。

下面是实战里的排行

No1 怪雨霰dq，攒能量中的王者，建造可以获得，就算是绿色品质的也建议留着，可以让角色能量获取速度扩大一倍 10分

No2 爆破(火炮武器)蓄力75分，连发65分。常规大家都有的可以最大提升能量获取的武器。

No2 连狙，蓄力狙。狙击这版本是最强势的远程武器了。后排只要换上狙击，输出都能立马提升一截，现在唯一可以和近战抗衡的远程武器 。能量获取率只有5分，但考虑到相比同类远程可以打出更高伤害，6分

No3 重型近战，45分

No4 重机q，重型盾牌，4分

No5 冲锋q，3分

No6 轰炸(投射武器)不要用!实在想用轰炸装狙击或者装近战当重甲前排，2分

No6 片手剑(轻型盾牌)和轻型近战(轻甲格斗)，2分

这里可以看出，最优选择为怪雨霰dq，但可能很多人没有。那第二优先选择就是蓄力的爆破武器，这个实在没有累充88送狗姐蓄力炮。狙击的充能也不差，但和怪雨霰dq比确实是差了一倍，好在狙击的强势可以增加一点输出。

通过这些，我们可以组成一些体系，把这些武器给伤害不高的辅助，让她们频繁放技能来过得buff收益，这些收益是高于再上一名输出的。修女永动盾，双子常驻增伤，琥珀常驻攻速加成，如果后面出了更多的辅助角色，则会有更多的玩法，比如奶妈。现在我感觉最厉害的体系就是修女体系，高能量回复让修女频繁放群体盾，保证血量健康，用怪雨霰dq甚至可以做到永动盾。可以让我们轻松越级挑战很多关卡，或者无伤一支队伍通关，减少 *** 作。比如我之前发的帖子，rank30级武器的修女，两支36级队伍过50级的困难喵喵本。等后面奶妈回来了相信还会有更多玩法。

关于额外攻速加成是会增加能量获取率的，毕竟打的次数多了，能量获取率取决于装备基带的攻击次数。轻甲格斗，冲锋q，爆破三个职业专精有10%暴击补正，不建议为了技能效率替换武器。这游戏基础暴击率是吃边际效应的。而专精的10%暴击率属于额外暴击率，是另加上的，前期本来暴击就不够的情况下，这三个职业还是带上专精比较好。

问题背景

open***,服务端是windows系统，客户端是ARM64 + LINUX,服务端和客户端的证书都是在ubuntu上用easyRSA生成的。

问题现象

windows启动open***服务器后，从arm客户端去连接windows服务端，客户端提示Your certificate is no yet valid的警告，无法创建***连接。

原因&解决

因为我的ARM客户机不能从网络获取当前时间，也就导致系统时间是一个出厂时间，这就导致证书生效期（2021/04/22）超前 客户机系统时间（2020/01/01），所以客户机判定证书不可用。

解决办法是手动更新客户机的系统时间，使用如下Linux命令：

                    date -s "20210422 10:30:00"

这样系统的当前时间就被设置在了证书的有效时间内，问题解决。

以Android open failed: ENOENT (No such file or directory)为列，分析android 60 以上的动态权限

在Android60以下所有的权限需要使用时在清单配置中就可以了，但自从Android60以后，Android就为权限分为了

normal：这个权限类型并不直接威胁到用户的隐私，可以直接在manifest清单里注册，系统会帮我们默认授权的。

dangerous：这个可以直接给app访问用户一些敏感的数据，不仅需要在manifest清单里注册，同时在使用的时候，需要向系统请求授权。

所以说我们新建文件时光在Manifest清单是配置是不够的，会闪退包上述错误！

解决方案：就是在需要时新建文件时获取文件读取的动态权限

intpermission = ActivityCompatcheckSelfPermission(activity, ManifestpermissionWRITE_EXTERNAL_STORAGE);

if(permission != PackageManagerPERMISSION_GRANTED) {

// We don't have permission so prompt the user

ActivityCompatrequestPermissions(

activity,

PERMISSIONS_STORAGE,

REQUEST_EXTERNAL_STORAGE

);

}

ORA-00054: 资源正忙, 但指定以 NOWAIT 方式获取资源, 或者超时失效

解决方法如下：

=========================================================

SQL> select session_id from v$locked_object;

SESSION_ID

----------

56

SQL> SELECT sid, serial#, username, osuser FROM v$session where sid = 142;

SID SERIAL# USERNAME OSUSER

---------- ---------- ------------------------------ ------------------------------

56 2088 ghb fy

SQL> ALTER SYSTEM KILL SESSION '56,2088';

System altered

执行完上述命令后，提示会话断开。重新连接数据库，然后执行truncate *** 作，成功！

以下是原理部分

==============

Oracle数据库的锁类型

根据保护的对象不同，Oracle数据库锁可以分为以下几大类：DML锁（data locks，数据锁），用于保护数据的完整性；DDL锁（dictionary locks，字典锁），用于保护数据库对象的结构，如表、索引等的结构定义；内部锁和闩（internal locks and latches），保护数据库的内部结构。

DML锁的目的在于保证并发情况下的数据完整性，。在Oracle数据库中，DML锁主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。

当Oracle 执行DML语句时，系统自动在所要 *** 作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X 等多种模式，在数据库中用0－6来表示。不同的SQL *** 作产生不同类型的TM锁。

在数据行上只有X锁（排他锁）。在 Oracle数据库中，当一个事务首次发起一个DML语句时就获得一个TX锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行 DML语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后，TX锁被释放，其他会话才可以加锁。

当Oracle数据库发生TX锁等待时，如果不及时处理常常会引起Oracle数据库挂起，或导致死锁的发生，产生ORA-60的错误。这些现象都会对实际应用产生极大的危害，如长时间未响应，大量事务失败等。

悲观封锁和乐观封锁

一、悲观封锁

锁在用户修改之前就发挥作用：

Select for update（nowait)

Select from tab1 for update

用户发出这条命令之后，oracle将会对返回集中的数据建立行级封锁，以防止其他用户的修改。

如果此时其他用户对上面返回结果集的数据进行dml或ddl *** 作都会返回一个错误信息或发生阻塞。

1：对返回结果集进行update或delete *** 作会发生阻塞。

2：对该表进行ddl *** 作将会报：Ora-00054:resource busy and acquire with nowait specified

原因分析

此时Oracle已经对返回的结果集上加了排它的行级锁，所有其他对这些数据进行的修改或删除 *** 作都必须等待这个锁的释放，产生的外在现象就是其他的 *** 作将发生阻塞，这个这个 *** 作commit或rollback

同样这个查询的事务将会对该表加表级锁，不允许对该表的任何ddl *** 作，否则将会报出ora-00054错误：:resource busy and acquire with nowait specified

二、乐观封锁

乐观的认为数据在select出来到update进取并提交的这段时间数据不会被更改。这里面有一种潜在的危险就是由于被选出的结果集并没有被锁定，是存在一种可能被其他用户更改的可能。因此Oracle仍然建议是用悲观封锁，因为这样会更安全。

阻塞

定义：

当一个会话保持另一个会话正在请求的资源上的锁定时，就会发生阻塞。被阻塞的会话将一直挂起，直到持有锁的会话放弃锁定的资源为止。4个常见的dml语句会产生阻塞

INSERT

UPDATE

DELETE

SELECT…FOR UPDATE

INSERT

Insert发生阻塞的唯一情况就是用户拥有一个建有主键约束的表。当2个的会话同时试图向表中插入相同的数据时，其中的一个会话将被阻塞，直到另外一个会话提交或会滚。一个会话提交时，另一个会话将收到主键重复的错误。回滚时，被阻塞的会话将继续执行。

UPDATE 和DELETE当执行Update和delete *** 作的数据行已经被另外的会话锁定时，将会发生阻塞，直到另一个会话提交或会滚。

Select …for update

当一个用户发出selectfor update的错作准备对返回的结果集进行修改时，如果结果集已经被另一个会话锁定，就是发生阻塞。需要等另一个会话结束之后才可继续执行。可以通过发出 select… for update nowait的语句来避免发生阻塞，如果资源已经被另一个会话锁定，则会返回以下错误：Ora-00054:resource busy and acquire with nowait specified

死锁-deadlock

定义:当两个用户希望持有对方的资源时就会发生死锁

即两个用户互相等待对方释放资源时,oracle认定为产生了死锁,在这种情况下,将以牺牲一个用户作为代价,另一个用户继续执行,牺牲的用户的事务将回滚

例子：

1：用户1对A表进行Update，没有提交。

2：用户2对B表进行Update，没有提交。

此时双反不存在资源共享的问题。

3：如果用户2此时对A表作update,则会发生阻塞，需要等到用户一的事物结束。

4：如果此时用户1又对B表作update，则产生死锁。此时Oracle会选择其中一个用户进行会滚，使另一个用户继续执行 *** 作。

起因:

Oracle的死锁问题实际上很少见，如果发生，基本上都是不正确的程序设计造成的，经过调整后，基本上都会避免死锁的发生。

DML锁分类表

表1 Oracle的TM锁类型

锁模式 锁描述 解释 SQL *** 作

0 none

1 NULL 空 Select

2 SS(Row-S) 行级共享锁，其他对象只能查询这些数据行 Select for update、Lock for update、Lock row share

3 SX(Row-X) 行级排它锁，在提交前不允许做DML *** 作 Insert、Update、Delete、Lock row share

4 S(Share) 共享锁 Create index、Lock share

5 SSX(S/Row-X) 共享行级排它锁 Lock share row exclusive

6 X(Exclusive) 排它锁 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive

1关于V$lock表和相关视图的说明

Column Datatype Description

ADDR RAW(4 | 8) Address of lock state object

KADDR RAW(4 | 8) Address of lock

SID NUMBER Identifier for session holding or acquiring the lock

TYPE VARCHAR2(2) Type of user or system lock

The locks on the user types are obtained by user applications Any process that is blocking others is likely to be holding one of these locks The user type locks are:

TM - DML enqueue

TX - Transaction enqueue

UL - User supplied

--我们主要关注TX和TM两种类型的锁

--UL锁用户自己定义的，一般很少会定义，基本不用关注

--其它均为系统锁，会很快自动释放，不用关注

ID1 NUMBER Lock identifier #1 (depends on type)

ID2 NUMBER Lock identifier #2 (depends on type)

---当lock type 为TM时，id1为DML-locked object的object_id

---当lock type 为TX时，id1为usn+slot，而id2为seq。

--当lock type为其它时，不用关注

LMODE NUMBER Lock mode in which the session holds the lock:

0 - none

1 - null (NULL)

2 - row-S (SS)

3 - row-X (SX)

4 - share (S)

5 - S/Row-X (SSX)

6 - exclusive (X)

--大于0时表示当前会话以某种模式占有该锁，等于0时表示当前会话正在等待该锁资源，即表示该会话被阻塞。

--往往在发生TX锁时，伴随着TM锁，比如一个sid=9会话拥有一个TM锁，一般会拥有一个或几个TX锁，但他们的id1和id2是不同的，请注意

REQUEST NUMBER Lock mode in which the process requests the lock:

0 - none

1 - null (NULL)

2 - row-S (SS)

3 - row-X (SX)

4 - share (S)

5 - S/Row-X (SSX)

6 - exclusive (X)

--大于0时，表示当前会话被阻塞，其它会话占有改锁的模式

CTIME NUMBER Time since current mode was granted

BLOCK NUMBER The lock is blocking another lock

0, 'Not Blocking',

1, 'Blocking',

2, 'Global',

--该锁是否阻塞了另外一个锁

2其它相关视图说明

视图名 描述 主要字段说明

v$session 查询会话的信息和锁的信息。 sid,serial#：表示会话信息。

program：表示会话的应用程序信息。

row_wait_obj#：表示等待的对象,和dba_objects中的object_id相对应。

lockwait :该会话等待的锁的地址,与v$lock的kaddr对应

v$session_wait 查询等待的会话信息。 sid：表示持有锁的会话信息。

Seconds_in_wait：表示等待持续的时间信息

Event：表示会话等待的事件，锁等于enqueue

dba_locks 对v$lock的格式化视图。 Session_id：和v$lock中的Sid对应。

Lock_type：和v$lock中的type对应。

Lock_ID1： 和v$lock中的ID1对应。

Mode_held,mode_requested：和v$lock中

的lmode,request相对应。

v$locked_object 只包含DML的锁信息，包括回滚段和会话信息。 Xidusn,xidslot,xidsqn：表示回滚段信息。和

v$transaction相关联。

Object_id：表示被锁对象标识。

Session_id：表示持有锁的会话信息。

Locked_mode：表示会话等待的锁模式的信

息，和v$lock中的lmode一致。

以下是命令行部分

================

1查询数据库中的锁

select from v$lock;

select from v$lock where block=1;

2查询被锁的对象

select from v$locked_object;

3查询阻塞

查被阻塞的会话

select from v$lock where lmode=0 and type in ('TM','TX');

查阻塞别的会话锁

select from v$lock where lmode>0 and type in ('TM','TX');

4查询数据库正在等待锁的进程

select from v$session where lockwait is not null;

5查询会话之间锁等待的关系

select asid holdsid,bsid waitsid,atype,aid1,aid2,actime from v$lock a,v$lock b

where aid1=bid1 and aid2=bid2 and ablock=1 and bblock=0;

6查询锁等待事件

select from v$session_wait where event='enqueue';

解决方案：

select session_id from v$locked_object; --首先得到被锁对象的session_id

SELECT sid, serial#, username, osuser FROM v$session where sid = session_id; --通过上面得到的session_id去取得v$session的sid和serial#，然后对该进程进行终止。

ALTER SYSTEM KILL SESSION 'sid,serial';

example:

ALTER SYSTEM KILL SESSION '13, 8';

以上就是关于重装战姬各职业武器的能量获取效率解析全部的内容，包括:重装战姬各职业武器的能量获取效率解析、openVPN客户端连接服务器，出现Your certificate is no yet valid的警告、Android open failed: ENOENT (No such file or directory)等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！